Bug 149407 - Proposal for slight change in position and label of controls in the Position dialog for objects
Summary: Proposal for slight change in position and label of controls in the Position ...
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 149681 (view as bug list)
Depends on:
Blocks: Image-Dialog Frame-Dialog Shapes
  Show dependency treegraph
 
Reported: 2022-05-31 16:05 UTC by sdc.blanco
Modified: 2023-10-12 06:37 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Rough mockup for layout of Position controls (77.75 KB, image/png)
2022-05-31 16:05 UTC, sdc.blanco
Details
Mock-up (70.67 KB, application/vnd.oasis.opendocument.graphics)
2022-06-26 10:04 UTC, Telesto
Details
Mock-up (73.05 KB, application/vnd.oasis.opendocument.graphics)
2022-06-26 13:07 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2022-05-31 16:05:21 UTC
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.
Comment 1 Heiko Tietze 2022-06-01 09:06:46 UTC
Eyal had a similar idea to make the content readable.
Comment 2 Eyal Rozenberg 2022-06-01 10:25:12 UTC
I guess Heiko is referring to what I wrote in bug 148593.
Comment 3 Heiko Tietze 2022-06-03 05:49:52 UTC
(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
Comment 4 sdc.blanco 2022-06-03 10:57:10 UTC
(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.
Comment 5 Eyal Rozenberg 2022-06-03 11:43:07 UTC
(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.
Comment 6 sdc.blanco 2022-06-03 12:19:51 UTC
(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).
Comment 7 Eyal Rozenberg 2022-06-03 12:57:17 UTC
(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.
Comment 8 Heiko Tietze 2022-06-07 10:17:47 UTC
(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.
Comment 9 sdc.blanco 2022-06-07 11:04:44 UTC
(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.
Comment 10 Eyal Rozenberg 2022-06-07 20:55:13 UTC
(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.
Comment 11 sdc.blanco 2022-06-08 05:50:01 UTC
(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?
Comment 12 Eyal Rozenberg 2022-06-08 06:20:29 UTC
(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.
Comment 13 sdc.blanco 2022-06-08 09:40:02 UTC
(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.
Comment 14 Eyal Rozenberg 2022-06-08 19:37:07 UTC
(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.
Comment 15 sdc.blanco 2022-06-08 22:35:07 UTC
(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.
Comment 16 Heiko Tietze 2022-06-09 05:59:40 UTC
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).
Comment 17 sdc.blanco 2022-06-24 15:50:54 UTC
*** Bug 149681 has been marked as a duplicate of this bug. ***
Comment 18 Telesto 2022-06-26 10:04:00 UTC
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..
Comment 19 Telesto 2022-06-26 13:07:12 UTC
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..
Comment 20 Eyal Rozenberg 2022-06-26 21:31:29 UTC
(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
Comment 21 Dieter 2023-10-12 06:37:22 UTC
(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