Created attachment 180506 [details] Rough mockup for layout of Position controls Attached is a rough mockup of the Position section of the Position and Size dialog (for Shapes and/or images, frames, OLE Objects). Two main/key features of proposal. 1. "to" -> "of" Reason: The first control (Horizontal, Vertical) gives a choice of "where" in some region (or line) the object should be placed. The second control "of" identifies the region to be used. Using the controls in the attached example to illustrate: Horizontal is "From left" of "Paragraph area" by "0.70cm" This says: place object from left of paragraph area by .7cm Vertical (uses a reference line): Top of baseline This says: Place object on top of baseline. (Try yourself. Make a shape, anchor it in a word "as character", then use "Vertical" "Top of baseline" and "Bottom of baseline". See if you can predict where the object is positioned before clicking OK. Compare using "of" with the current: "Top to baseline" and "Bottom to baseline" (NB- mockup shows an "impossible" combination -- in order to demonstrate that both "to paragraph/character" anchor (Horizontal) (with region) and "as character" anchor (Vertical) (with reference line) can work with this change.) 2. "by" is moved to end. Reason: Used by only a few of the Vertical/Horizontal options, therefore often inactive, so move it away from attention, but still gives a meaningful "sentence" in the sequence of dropdown boxes. General reason: I have been using this structure with all of the different combinations of options for different options for a few weeks. This experience underpins the claim that the structure can be used meaningfully with the existing positioning options. More importantly, the structure has made it easy (or easier) to predict/understand the result of choosing particular options. To realize the proposal: (a) the position of the "by" and "to" controls must be switched in sw/uiconfig/swriter/ui/frmaddpage.ui and cui/uiconfig/ui/swpossizepage.ui (b) the label "to" is changed to "of" in both .ui files. No changes in the underlying code is proposed or required. No conflicts with RTL or vertical writing. I believe there are plans/ideas to take different approaches to this dialog. This proposal is not meant to resist those intentions. Rather, it proposes an improvement that can be done here and now, probably within a few hours, which I expect will make it much easier (and more enjoyable) to use the Position dialog.
Eyal had a similar idea to make the content readable.
I guess Heiko is referring to what I wrote in bug 148593.
(In reply to Eyal Rozenberg from bug 148593 comment #6) > Option 1: Enable constructing the following phrases for Horizontal: > > Align [F1] to [F2] with offset [F3] > > F1: Left, Right, Center (and perhaps also Start and End, where these will be > interpreted according to the direction of the anchored-to entity. > > F2: par. area, par. text area, left page border, right page border, page > start border, page end border, page inner border (when we have book > margins), page outer border (when we have book margins), page text area, > entire page . > > F3: text box accepting both negative and positive values. > Option 2: Similar to option 1, but add another field controlling the > direction of offset Think using negative values is not too bad and
(In reply to Heiko Tietze from comment #3) > > Align [F1] to [F2] with offset [F3] Two problems with this proposal. 1. uses "to". Heart of OP is to use "of" instead of "to" -- because it gives a better affordance for an appropriate mental model. (iow -- the syntax is being used here to give insight has to reflect the semantics...) 2. Cursory evaluation suggests that Align (Left, Center, etc.) "to" (Page, Para) etc. does not give an appropriate model.
(In reply to sdc.blanco from comment #4) Strongly disagree. To "create an appropriate mental model" you have to start at the lower level, which is understanding how the different controls combine. This is difficult, or even one could say broken, if controls on a line don't form coherent, grammatically valid sentences. In our case, you suggest that the dialog read: "Position from left of paragraph area by 0.7 cm". You cannot "position from X" in English. While you may have developed a certain assumption regarding what this means, most people don't share it. They have to guess what this might mean.
(In reply to Eyal Rozenberg from comment #5) > They have to guess what this might mean. Or read the documentation. -- where UI choices can make it easier to explain/document. I would propose that you open a new ticket for your intention to make an interface with "coherent, grammatically valid sentences" that is consistent with "the lower level...how the different controls combine." -- with the concrete details laid out with actual examples. (it is unclear to me whether your Align [F1] to [F2] with offset [F3] will actually work with all cases, and if not, what changes in underlying code or UI would be required.) As also noted in the OP, the proposal here is not meant to preclude other further or different developments with the positioning dialog. Meanwhile, although the proposal copied into comment 3 looks -- on the surface -- to be more or less the same as the OP, there was no intention in the OP to follow the design criteria (named in comment 5). Rather, the present proposal (a) works with the existing implemented lower level, (b) where the proposed UI changes have been evaluated concretely in relation to more or less all the anchoring and positioning options, and (c) has been found to assist understanding the operation of the currently existing implementation, and (d) can be achieved quickly and easily as an EasyHack (skillDesign, no skillCpp).
(In reply to sdc.blanco from comment #6) > (In reply to Eyal Rozenberg from comment #5) > > They have to guess what this might mean. > Or read the documentation. -- where UI choices can make it easier to > explain/document. Absolutely not. The user should not read the documentation ton understand what the controls mean, except in very complex and delicate cases (this not being one of them). > As also noted in the OP, the proposal here is not meant to preclude other > further or different developments with the positioning dialog. Perhaps, but it doesn't fix the problem with that dialog, it only shifts it around. > (c) the present proposal > has been found to assist understanding the operation of the currently > existing implementation, I don't see that it has.
(In reply to Eyal Rozenberg from comment #5) > You cannot "position from X" in English. I don't stumble much as native German speaker. The order within a sentence depends on the language and if we make this work (better) in English it won't fit other perhaps. No opinion for to vs. of from my side.
(In reply to Heiko Tietze from comment #8) > (In reply to Eyal Rozenberg from comment #5) > > You cannot "position from X" in English. This example seems to be based on a misunderstanding of both the dialog and the example used in the attachment. 1. There is no proposal for "Position from X". 2. There is an option for the Horizontal control "From left", which was used in the attached example, so that the "by" control could also be included. Otoh, most of the the Horizontal control options do not activate the "by" control, so they would be presented as: "Left" of "Entire Paragraph Area" or "Center" of "Entire Paragraph Area", etc.
(In reply to sdc.blanco from comment #9) > 1. There is no proposal for "Position from X". That's what the mockup says... > 2. There is an option for the Horizontal control "From left", which was > used in the attached example, so that the "by" control could also be > included. Yes, that's the problem: "Position from left of paragraph area by 0.70cm". > Otoh, most of the the Horizontal control options do not activate the "by" > control, so they would be presented as: "Left" of "Entire Paragraph Area" > or "Center" of "Entire Paragraph Area", etc. "Position from left of entire paragraph area" is still unacceptable IMO.
(In reply to Eyal Rozenberg from comment #10) > Yes, that's the problem: "Position from left of paragraph area by 0.70cm". > "Position from left of entire paragraph area" is still unacceptable IMO. Reasons?
(In reply to sdc.blanco from comment #11) > > "Position from left of entire paragraph area" is still unacceptable IMO. > Reasons? Because it's not at all clear what this means, especially since it's not a valid phrase in English. And the combination of these controls - which are "sentence-forming" in nature - should be readable as a sentence.
(In reply to Eyal Rozenberg from comment #12) > (In reply to sdc.blanco from comment #11) > > > "Position from left of entire paragraph area" is still unacceptable IMO. > > Because it's not at all clear what this means. Unclear to me whether you understand this positioning control because it needs to have "by" in this case. > especially since it's not a valid phrase in English. Why not? > And the combination of these controls - which are > "sentence-forming" in nature - should be readable as a sentence. The OP is relative to the existing interface. It does not depend on or presuppose your "sentence-forming" criterion, and there is no reason why that criterion should be an absolute requirement for making any easy, but useful, improvement to the existing interface. (the point of the OP). As noted in comment 6, the OP "is not meant not meant to preclude other further or different developments with the positioning dialog." Simply repeating that you disagree strongly only indicates that the OP does not follow your criterion. That was acknowledged already in the OP.
(In reply to sdc.blanco from comment #13) > Unclear to me whether you understand this positioning control because it > needs to have "by" in this case. "Position from left of entire paragraph area by 0.70cm" still no good. > > especially since it's not a valid phrase in English. > Why not? I don't know, I'm not a linguist... it just isn't. The imperative verb "position" can take a direct object and an indirect object with preposition 'at': "position X at Y". You can't "position X from Y". > It does not depend on or presuppose your "sentence-forming" criterion, and > there is no reason why that criterion should be an absolute requirement > for making any easy, but useful, improvement to the existing interface. > (the point of the OP). I'm trying to explain why I don't see this change as an improvement.
(In reply to Eyal Rozenberg from comment #14) > You can't "position X from Y". You continue to misunderstand the dialog for this example. Using the actual words of the dialog (as proposed, plus a few words usually dropped in controls), the example says, in grammatical English, to position object X: from (the) left (edge) of (the) entire paragraph area by 0.7cm > I'm trying to explain why I don't see this change as an improvement. Yes, but so far the only reason offered is that the OP does not use the criterion that you have put forward. As a matter of logic, a proposal that does not use your criterion will not be seen as an improvement. If you are not willing to consider other criteria, or consider the proposal in its own terms (e.g., an improvement that can be done here and now, probably within a few hours, easier to explain/document), then there is nothing left to discuss.
We discussed this topic in the design meeting. Changing "to" to "of" might be good for some but not all scenarios (for instance 'left of the entire page' is not the same as 'to'). It opens a chain of patches and has no clear benefit for understandability. The proposed rearrangement of controls fails or might be inappropriate for other languages than English and also wont make the functionality easier to understand. The recommendation is to leave the dialog as it is (=> WF), but no strong objection if volunteers want to change it (keeping UNCONF therefore).
*** Bug 149681 has been marked as a duplicate of this bug. ***
Created attachment 180970 [details] Mock-up Sorry for not replying earlier. Out of the running for a few days... COVID-19 I'm still in favor of re-arranging the position controls. I simply can't wrap my head around the current arrangement of the controls. The second issue how to lael the relation between the different drop downs (current done by 'to' and ' by') The sentence concept has some nice ring to it, but it isn't a necessity. The controls/labels must be chosen and positioned in a way which makes the controls self-explaining/intuitive (and well fit within the limited space) Attached a rough mock-up of totally different arrangement. I also invented some new labels (avoiding the whole to/of problem). However I'm not a native English speaker nor did I check the translatability.. I would welcome some feedback..
Created attachment 180972 [details] Mock-up Updated variant of my initial mock-up, getting rid of some confusion compared to the previous one. The grid model prevents re-using the same labels twice for horizontal and vertical. Makes UI less crowded, prevents additional reading. I personally prefer the top down approach compared to horizontal arrangement. I find it slightly easier to orientate. However no UI design specialist with knowledge of the UI guidelines..
(In reply to Telesto from comment #19) > Created attachment 180972 [details] > Mock-up I don't understand the mockup, it's still super-confusing. You have partial bits of the original layout, cut up in mid-control. > The grid model What grid model? :-( Also, what's your opinion of my suggestion here?: https://bugs.documentfoundation.org/show_bug.cgi?id=148593#c6
(In reply to Eyal Rozenberg from comment #20) > > Mock-up > > I don't understand the mockup, it's still super-confusing. You have partial > bits of the original layout, cut up in mid-control. > > > The grid model > > What grid model? :-( > > Also, what's your opinion of my suggestion here?: Telesto, could you anwer those questions? => NEEDINFO
Dear sdc.blanco, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
@Telesto....needs to supply the NEEDINFO...
Created attachment 193604 [details] Mockup
Telesto's mockup in comment 24 (attachment 193604 [details]) provides an interesting alternative to the OP. I will assume this mockup satisfies the request in comment 21, so setting to UNCONFIRMED and also sending that proposal to UX-Eval for consideration.
The alternative places five controls in a line. That can easily exceed the normal width when translated making the dialog unnecessary large. And I kind of miss the of/to and by labels. However, I struggle with the additional "Position" label.
(In reply to sdc.blanco from comment #26) > Telesto's mockup in comment 24 (attachment 193604 [details]) provides an > interesting alternative to the OP. ... but still suffers from the problem I mentioned in comment #5 here and in bug 148593 comment 6: These kinds of combinations-of-controls with tex must form _coherent sentences_. This stands out even more when we place the controls horizontally, visually forming that sentence (which I kind of like). Let us read from the mockup: "Horizontal: Position paragraph area from left 0.0 cm" What does that even mean? Even if we add the column title of the last column, it's still: "Horizontal: Position paragraph area from left with offset 0.0 cm" and I have no idea what this means: * What is "positioning from left"? That's not gramattically-valid English IIANM * Left of what? Are positioning the paragraph's left edge or positioning it to the left of something? * Offset of what, from what? Re-laying-out of controls must also be accompanied by changing the labels and possibly the semantics to match them.
(In reply to Eyal Rozenberg from comment #28) > (In reply to sdc.blanco from comment #26) > > Telesto's mockup in comment 24 (attachment 193604 [details]) provides an > > interesting alternative to the OP. > > ... but still suffers from the problem I mentioned in comment #5 here and in > bug 148593 comment 6: It was more or less a partial mockup limited to arranging the Position Controls as contrast to the suggestion of sdc.blanco. So yes it has the same flaw. In principle I would agree with 'make it a coherent sentence' and "make a grammatically correct sentence", but I fear the bar being to high because that includes the sentence to be coherent in all (current and future) translations. And that's likely mission impossible. > * What is "positioning from left"? That's not gramattically-valid English > IIANM The "From Left" isn't really self-explaining. Aligning Left doesn't allow an offset. "From left" means, Left side (of defined area; for example Paragraph Area) + Off-set. No idea why this category being needed at all. Some could argue that "Left" + offset value = From Left internally, but without exposing this in the dialog. And I have no idea why you aren't allowed to define off-set "From Center" or "From Right" (I'm maybe overlooking something) As wondering: is the category "From Left" actually "From Right" for RTL? > * Left of what? Are positioning the paragraph's left edge or positioning it > to the left of something? Don't ask me where the defined area is actually located. The are highly specific; and because the are specific the become technical. So even help is using a technical description. It's not easy to understand for moderate user, IMHO. I have no clue what will happen, even when reading the help; and when it will produce the same result and in which cases it will differ. So my tendency is stick with default area :-). I'm rather visually orientated, so long technical descriptions are hard regards how well written > * Offset of what, from what? Offset from the (Left) alignment (going to the right). Offset in essence the same as Indent, I think > Re-laying-out of controls must also be accompanied by changing the labels > and possibly the semantics to match them. I agree. However having to consider all the dimensions at once is quite mind boggling/ mind numbing.
(In reply to Telesto from comment #29) > In principle I would agree with 'make it a coherent sentence' and "make a > grammatically correct sentence", but I fear the bar being to[o] high because > that includes the sentence to be coherent in all (current and future) > translations. And that's likely mission impossible. Well, it's true that some problems may arise when translating. But: 1. The better and clearer we make it in one language, the more likely it would be at-least-ok and maybe totally-ok in other languages. 2. If the "imperfection" is just akward-wording rather than difficult-to-understand, we can live with that. > The "From Left" isn't really self-explaining. Aligning Left doesn't allow an > offset. "From left" means, Left side (of defined area; for example Paragraph > Area) + Off-set. We _have_ to have self-explanatory UI, except in extreme cases, which this isn't one of. And in fact, even this explanation doesn't cut it, as you yourself write: > No idea why this category being needed at all. Some could > argue that "Left" + offset value = From Left internally, but without > exposing this in the dialog. > > As wondering: is the category "From Left" actually "From Right" for RTL? Not as such, but you did hit on something here: * With "From left" - if you switch paragraph direction, the textbox position is also switched; * With "Left" - if you switch paragraph direction, the textbox is unaffected. > I'm rather visually orientated, so long technical descriptions are hard > regards how well written Which brings me to the point of the preview being above these settings, and being non-faithful to them (e.g. offset has no effect on the preview when in "From Left" state). > > * Offset of what, from what? > Offset from the (Left) alignment (going to the right). Offset in essence the > same as Indent, I think You can't have offset from an alignment. It could be offset from the left edge of the paragraph, or offset of the paragraph from some edge of the box. And then there's the next box, which in your mockup is called "region or reference", which itself has values with the word left, e.g. "left of paragraph text area". > I agree. However having to consider all the dimensions at once is quite mind > boggling/ mind numbing. Let's ignore vertical foocus just on vertical; but given that - we should undertake this mind-boggling task at some point. We need (IMNSHO) to spell out all of the alginment options, rethink how they should be grouped - perhaps over one some online session or two - then go back to designing appropriate UI.
We discussed the topic in the design meeting. None of the proposed "slight changes" are an improvement for the underlying problems and it's better to start the discussion newly. So the verdict is WF here.