In the Style dialogs, under the Organizer page, one of the rows is a drop-down list with the label "Next Style". The function of this (pair of) control(s) is not clear, especially to the newbie user: * Is this intended to reposition the style within the list of styles on the sidebar? * Does this have to do with some order of preference or falling-back among styles? * Is this the next style to edit in the style editing dialog, i.e. such that if you select it you get to edit it? It will probably not even occur to most newbie users that this might be "the style to apply to a next object of the same category inserted after an object with the style currently being edited." - for styles which have a different "Next style", such as "List heading" with "List contents" or "Heading" with "Text Body", you can guess. If you just get, say, "Addressee" and "Addressee" - you would probably not guess. So, what is to be done? 1. Label change This is the easiest thing to do, but the choice of label is a bit tricky and it would still be imperfect. Concrete suggestions: For a FOO style (Page, Character, Paragraph etc.), "Next FOO Style" "Succeeding FOO Style" "Next Object Style" "Succeeding Object Style" 2. Something else I actually don't have a good idea here. Perhaps... the label could take the full width of the drop-down list, and have a descriptive sentence about when the "Next Style" choice gets applied? I don't know.
Same argument could be taken for the "Inherit from" attribute and anything else that is advanced. I don't think these are beginner options. So another "solution" might be to trust in the (online) help. | Next Style | Select an existing style that you want to follow the current style in your document. | For paragraph styles, the next style is applied to an empty paragraph that is created | when you press Enter at the end of an existing paragraph. For page styles, the next | style is applied when a new page is created. Pretty clear to me. => NAB And we also have the opportunity to clarify a label per tooltip / extended tooltip. If we do this it should be done for all items on the tab.
(In reply to Eyal Rozenberg from comment #0) > In the Style dialogs, under the Organizer page, one of the rows is a > drop-down list with the label "Next Style". > > The function of this (pair of) control(s) is not clear, especially to the newbie user: This is a documentation/User Guide issue, *not* a UI issue. _Creating and Using Styles: Component_ (Write, Calc, Presentation, Drawing, Formula, Base, 7thComponent ) Each type (Paragraph, Character,Frame, Page, List, Table, Cell, Format, etc.) of style used by that component has one chapter that describes: * what each item within the style composition does; * what the acceptable parameters for that item are; * how the item affects the style overall; * how to utilize that item within the style; Note: The document describes the style type. EG _Page Style_. It does not go into the differences between the styles that are shipped with Libo. IOW, it does not explain why Endnote pages exist, or how to correctly use Footnote pages.
We discussed the topic in the design meeting. Labeling it "Next paragraph style", for example, adds no information. It is reasonably clear what the dialog/label is talking about. Short labels also have the advantage to make the UI feel less cluttered.
(In reply to Heiko Tietze from comment #1) > Same argument could be taken for the "Inherit from" attribute and anything > else that is advanced. No, it could not, because "Inherit from [SomeParent]" is an imperative-form sentence describing a feature of the style being edited, while "Next Style [SomeStyle]" is a merely a noun-phrase, whose completion into an imperative sentence, or perhaps an adjective-phrase, regarding the style being edited requires a complex transformation. > I don't think these are beginner options. So another > "solution" might be to trust in the (online) help. > > ... documentation quote ... > > Pretty clear to me. => NAB 1. Help/documentation, in general, should never be considered a solution for a usability problem. It is always a fallback if the actual solution is faulty or imperfect; never something to send the user to consult by default. 2. Indeed, these are not beginner option. So, let me rephrase: These options are not clear to the user who is beginning to explore this part of the dialog. That is not the absolute-beginner user, it's the user who wants to get into more complex management of styles. That is the key user for the UI to target. > And we also have the opportunity to clarify a label per tooltip / extended > tooltip. If we do this it should be done for all items on the tab. Why? Do you believe some of the other labels are unclear?
(In reply to jonathon from comment #2) > This is a documentation/User Guide issue, *not* a UI issue. No, this is a UI issue. I didn't claim there's anything wrong with the documentation. If you mean to say that, in order to understand this part of the UI, the user should read the documentation - that is an inacceptable claim, as I've argued above. The UI must be self-explanatory. Exception to this should be extremely rare, well-justified, and typically involve telling the user explicitly they need to go read some document. This is really not one of those cases. So, please don't quote the documentation to me. If I thought the documentation was lacking or misphrased I would have opened a bug against the documentation component (although TBH it's not obvious whether a bug against Writer documentation should use the Writer component or the Documentation component).
(In reply to Heiko Tietze from comment #3) > We discussed the topic in the design meeting. In an inappropriate manner, without giving reasonable prior notice of the discussion despite my having explicitly asked for this not to happen. > Labeling it "Next paragraph style", for example, adds no information. Ah, I see what you mean! The user can't tell whether "next" is the next style or the next-paragraph. Yes, indeed. Well, the label could be, say, "Style for next paragraph", or "Style for succeeding paragraph". A bit longer, but perhaps with just a line extension of the area for a label, it could be a two-liner, e.g. Style for / \ Next paragraph \ / Note that maintaining non-ambiguity would require a bit of delicacy in translation. Based on this and my two earlier comments - changing back to UNCONFIRMED.
(In reply to Eyal Rozenberg from comment #4) > "Inherit from [SomeParent]" is an imperative-form... while "Next Style > [SomeStyle]" is a merely a noun-phrase, whose completion into an imperative > sentence, or perhaps an adjective-phrase, regarding the style being edited > requires a complex transformation. Sometimes using the ideal form of a phrase makes understanding even harder, and this is such a case to me. I cannot follow your argument (and none at the meeting could) that "Next Style" requires a complex transformation. So up to the native or more experienced English speakers to decide.
Stuart, what do you think about it?
(In reply to Dieter from comment #8) > Stuart, what do you think about it? Conciseness of the labels in standard technical English is generally preferable across the UI. That better supports localization of the UI by the l10n teams, who are familiar with the usage of the controls. With more detailed usage explanation delivered via localizable tooltip, online/offline Help, and user guides like the Writer Guide or the Byfield 'Designing with LibreOffice' text. So to me use/comprehension of the style centric Organizer tab of the .uno:EditStyle dialog is best achieved by documentation efforts, not haphazard relabeling in the UI. IMHO => WF
(In reply to V Stuart Foote from comment #9) Every time someone says "Let them look it up in the documentation" - that's a definite sign of a UI problem. > Conciseness of the labels in standard technical English is generally > preferable across the UI. Conciseness is a spectrum. If it is generally preferable - we could just shorten the label further and just say "Next". After all, this is the _Style_ organizer and the control is a list of _styles_, then why bother saying that? This is reminiscent of the "tale of the fishmonger", as told for example here: https://mannerofspeaking.org/2010/01/16/a-public-speaking-fable/ Conciseness should be moderated with outer virtues of the text. In our case, this is a dialog tab which has lots and lots of space, vertically and horizontally, and our balance should clarity and straightforwardness over saving a bit of dialog real-estate (and a few more words to be localized). Recall, finally, that tooltips and documentation pages require their own work on localization, just like the main UI.
Hi Eyal, (In reply to Eyal Rozenberg from comment #0) > The function of this (pair of) control(s) is not clear, especially to the > newbie user: Might be. > * Is this intended to reposition the style within the list of styles on the > sidebar? > * Does this have to do with some order of preference or falling-back among > styles? > * Is this the next style to edit in the style editing dialog, i.e. such that > if you select it you get to edit it? Quite extreme and thoughts - not some I would expect from a normal user. > 1. Label change Others do not support that idea. Also, since it is more then obvious that it relates to the list, i.e. styles (and only in case of paragraph and page styles) adding the word 'style' to the label is not needed. > 2. Something else A tool tip might indeed help. 'After Enter, the next paragraph will have the following style' or 'A next page will have the following style' But the Help text is (In reply to Eyal Rozenberg from comment #10) > Every time someone says "Let them look it up in the documentation" - that's > a definite sign of a UI problem. To me, sometimes it just means that the possibilities of the program are too complex to understand without some reading/training/trying.
do we have tool tips in dialogs? If so, I would support adding that for Paragraph and Page styles.
(In reply to Cor Nouws from comment #12) > do we have tool tips in dialogs? Sahil and Ilmari say that we do. > If so, I would support adding that for Paragraph and Page styles. Well, tooltips would help, but they don't solve the problem of some users assuming one of the other (not-unreasonable) interpretations. Still think we should rephrase the label. Another option for the label bikeshedding list: "Style for Succeeding FOO"
Then let's add an extended tip. For inspiration, page 126 in Writer Guide: https://nextcloud.documentfoundation.org/s/cfQM2jBBFzeWb28
(In reply to Buovjaga from comment #14) > Then let's add an extended tip. For inspiration, page 126 in Writer Guide: > https://nextcloud.documentfoundation.org/s/cfQM2jBBFzeWb28 You can certainly do that, in a related bug. But it won't resolve this bug.
Patch submitted for extended tips https://gerrit.libreoffice.org/c/core/+/176805
(In reply to Eyal Rozenberg from comment #15) > You can certainly do that, in a related bug. But it won't resolve this bug. At some point a request has been resolved. I see no reason to keep this ticket open after Olivier's patch. There will be no other modifications to this dialog.
(In reply to Heiko Tietze from comment #17) > (In reply to Eyal Rozenberg from comment #15) > > You can certainly do that, in a related bug. But it won't resolve this bug. > At some point a request has been resolved. I see no reason to keep this > ticket open after Olivier's patch. The same reason it was open before the patch. > There will be no other modifications to this dialog. There hasn't been a proper modification to the dialog which resolves the problem. Users are still likely not to realize what "Next Style" will do, and either ignore it or misinterpret it, just like in bug 163885.
(In reply to Eyal Rozenberg from comment #18) > There hasn't been a proper modification to the dialog which resolves the > problem. Users are still likely not to realize what "Next Style" will do, > and either ignore it or misinterpret it, just like in bug 163885. You are apparently referring to the comment of a new triager in training with no prior experience with LibreOffice. The original reporter did not describe anything related to Next Style.
This has been through UX-advise already. No change to the UI => WF, though the tab label in the dialogs has since been changed from 'Organizer' to 'General' at the 24.8 release. And of course it would apply to all modules with Paragraph styles--not just Writer. And as in my comment 9, documentation *is* the correct resolution whenever UI might be unclear--users are expected to review Tooltip, Help and published documentation to effectively use a module (and Style inheritance is cross module--not just Writer). Thrash in the UI is generally counter productive, both to users (Benjamin's and Eve's) and to the development and maintenance effort. Olivier's extended tip on the 'managestylepage.ui' exposes guidance as tooltip, and it is otherwise covered in published cocumentqation. IMHO the UI is sufficiently clear, remains => NAB, with a => WF resolution. -1
s/cocumentqation/documentation
(In reply to V Stuart Foote from comment #20) > IMHO the UI is sufficiently clear That's your basic argument, not all of the rest of the comment. But it is untenable. > This has been through UX-advise already. Where no one made a convincing argument why "Next Style" is a sufficiently clear and non-confusing label. > And as in my comment 9, documentation *is* the correct resolution whenever > UI might be unclear Documentation is not just an incorrect resolution whenever the UI is unclear; it is _never_ the correct resolution. In some extreme cases of high subtlety and complexity - this not being one of which - there is simply nothing to be done other than offer documentation; but generally, unclear UI must be made clear, or minimally unclear. > Thrash in the UI is generally counter productive, both to users (Benjamin's > and Eve's) and to the development and maintenance effort. When we this label last changed? Not for a good number of years IIRC.
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6e8ca63a61e3314e91a9b20cf371dd76969bc669 tdf#153600 Extended tips for Style General page It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.