https://bugs.documentfoundation.org/show_bug.cgi?id=165507
--- Comment #11 from Eyal Rozenberg <[email protected]> --- (In reply to Jonathan Clark from comment #7) > Our GUI doesn't necessarily > need to perfectly report exactly what we're doing; as long as we can provide > enough information so curious or advanced users can understand what's > happening, it's probably good enough. So, it's good that this view is also represented in our discussion. But - I partially disagree. That is, I would distinguish between the case of the GUI being a little more vague or inexplicit for the benefit of UX, and the case of the GUI saying something that's incorrect. The first - I would accept or reject on a case-by-case basis; I agree that it's something acceptable to only give a rough idea and let users dig if they want the details. But as for the second option - it frustrates users' legitimate expectations, and the longer-term effect of user miseducation and inability to trust what the app says exceeds the short-term gain of familiarly. For example: > > * If we press the now-left-align button, then switch the direction, the > > active button will switch to the new-right-button? > Yes I'm ok with this level of "fudging": Offering 4 buttons instead of 6, and kind of fudging the difference between Start/End and Left/Right for the purposes of a toolbar representation. But, > > * Will the tooltips say 'Align Start' and 'Align End'? And change labels > > when we switch directions? > I think the tooltips would always say "Align Left" and "Align Right". That is quite unacceptable, and would, in fact, be a bug: Since those buttons would align to Start, not to Left. We must not tell the user that they align one way, only for them to get incorrect alignment when they switch directions. And, of course, we will also have an actual Align Left button, even if it won't be on the toolbar by default; and we can't have that button have both the same image and the same tooltip as Align Start. -------------------------- > > * What will we see when the user chooses 'Align Left', e.g. via Format > > > Paragraph... or when opening a file which has that setting? i.e. will one of > > the 4 buttons be pressed? Two? None? > If the caret is inside a paragraph aligned with the left margin, the align > left toolbar button would always appear pressed. This would be true whether > this is achieved via align Left, Start, or End. I'm guessing you meant the "Align Start" toolbar button? If we only have the four buttons, "Align Left" won't be up there. Also, suppose I opted to put the four buttons on my toolbar: Start, End, Left, Right. You're suggesting that two of these should be pressed for any of the four alignment choice (other than Center or Justify)? > > * What buttons will the UNO commands for Align-Left and Align-Right have? > > Same look but without the switch on direction switch? Or something to > > distinguish them from Align-Start and Align-End even when static? > Do we need to preserve the existing buttons? UNO commands have buttons. And of course we need buttons for the different paragraph alignments. > (In reply to Heiko Tietze from comment #5) > > Commented on bug 169035 that a simple Start might be confusing and we better > > go with "Start (Left)" in case of LTR. Other than that I agree with the > > default. > If we make these labels context-sensitive, what about just calling Start > "Left" in the case of LTR, "Right" in the case of RTL, and then rename the > prior fixed Left alignment something like "Force Left/Top"? 1. Do you mean, in dialogs? Tooltips? Elsewhere? 2. Oh, no, that would make a pig's breakfast of everything. It will not just stunt the education of users about the different alignment values, and about Start/End vs Left/Right generally, but actively undo that education, because no users will see the app itself conflate the two terms. The only context in which this may be acceptable is when we have disabled full RTL-CTL support. And this is part of the reason we have not made a decision to just enable this support unconditionally, for all users: There are significant tradeoffs to consider between access to functionality and semantics, and simplicity for users who don't experience RTL content. -- You are receiving this mail because: You are on the CC list for the bug.
