Created attachment 121058 [details] Screen shot showing disabled options in dialog Replicate 0. Install LibreOffice from PPA 1. Start LibreOffice 2. Press Ctrl+n to create a new text document 3. Type: Chapter One 4. Press F11 to show the Styles and Formatting dialog 5. Change the Chapter One to the Heading 1 style 6. Right-click the Heading 1 style to display the context menu 7. Select Modify 8. Switch to the Outline & Numbering tab Expected Results Able to change the Numbering Style for Heading 1. Actual Results All the options to change the heading style are disabled: http://i.imgur.com/dhirtA3.png Additional Details Version: 5.0.3.2 Build ID: 1:5.0.3~rc2-0ubuntu1~trusty2 Locale: en-CA (en_CA.UTF-8)
From a user experience point of view, disabled options should not be presented without explicitly telling the user what is required to *enable* them. It is far better to write software that does not have *any* option disabled. When the user tries to use an option that is in an invalid state, tell the user at that time what they need to do to use that option. For example, as per the replication instructions: 8. Switch to the Outline & Numbering tab 9. Click *Edit Style* The system displays a dialog with the following content: "Warning. You are about to change the Paragraph Style for all future documents. Are you sure you want to proceed?" The user has options: Yes/No/Help. Clicking "Help", in this hypothetical contextual situation, should explain what the user needs to do to enable changing the paragraph style for only this document. *THIS WAS MERELY AN EXAMPLE OF HOW TO AVOID DISABLING FEATURES WHILE CLEARLY COMMUNICATING THE INTENT TO END USERS. SIMPLY DISABLING OPTIONS WITHOUT TELLING THE USER __WHY__ THE OPTION IS DISABLED IS FRUSTRATING AND TIME CONSUMING AT BEST. IT LENDS TO A EXTREMELY POOR IMPRESSION FOR USERS. DON'T DISABLE THINGS.*
Off to UX.
No idea why the numbering is diables (you may change it at the parent style "heading") but I disagree with the generic statement that controls *never* should be disabled. But it has to be clear from the workflow, perhaps changing the tooltip or adding a hint about the situation makes sense. And I'd sign it rephrased to "avoid disabled states, if possible". Anyway, no idea about the reason. There are smarter people around,
There are smarter people around, Stuart might know what happens here (cc'ed him).
The default setting is, that the styles "Heading 1", "Heading 2", ... are assigned to outline levels via Tools > Outline Numbering. If you want to change the kind of numbering, you have to do it in Tools > Outline Numbering. If you want to assign an outline level to a paragraph style besides the automatic, this style must not be used in Tools > Outline Numbering. I strongly recommend using Tools > Outline Numbering. Only that way you get, that the style is automatically adapted, when you change the outline level via Navigator. If you need to have a paragraph style that looks like "Heading 1", but has a different numbering, then derive it from "Heading 1". I mean, set its 'Inherit from' field to "Heading 1". Such might be needed, if you want, that an appendix heading has the same style as "Heading 1" but uses different numbering. In such child style the fields 'Outline Level' is enabled. For me this is not a bug in the code, but perhaps the documentation needs to be improved.
Migrating Whiteboard tags to Keywords: (needsDevEval)
See Joel Spolsky's post http://www.joelonsoftware.com/items/2008/07/01.html . See his comment http://ux.stackexchange.com/questions/12756/dont-hide-or-disable-menu-items#comment15651_12761 : "When I wrote the original blog post I was thinking of typical desktop programming environments which did not, by default, provide any mechanism for the user to learn why a menu item was disabled; they just left the user to scratch their heads and caused a usability problem. If you are 100% confident that your users will understand WHY something is disabled, or if you can provide a tooltip explanation that will be easily found, disabling is fine." What I mean by "never disable options" is echoed at http://ux.stackexchange.com/a/12761/15694 : "Explain why an item is disabled: Great advice that almost no one follows! Google search 'greyed out menu' and you'll find heaps of people wondering why their menu items are disabled, because the app doesn't tell them." See http://ux.stackexchange.com/a/926/15694 : "I generally have found that users don't read anything." See http://ux.stackexchange.com/a/76155/15694 : "Tooltips are a greta solution, but as you mentioned, many people are not aware they are there. Thus this tiny indicator invites the user to look for help only when they need it." Without any usage statistics to back up the idea, it's anyone's guess as to whether tooltips are actually helpful. Therefore, my original premise stands. Don't disable anything. Leave everything enabled and, when the user tries to use the feature, provide them practical help on why the feature is unavailable and how to resolve the issue. Further, this should not require the user going to external documentation (that is only available via the Internet). Although it would be cool to have the internal documentation link to a wiki or Q&A site that contains answers related to that particular feature.
Summary: Cannot Change Heading Style That is false and it has been explained in comment #5 how you can do that. So closing as WorksForMe. Now, if you really think that the UI shouldn't show grayed menu and dialog entries, please file a dedicated enhancement request for that which applies to the whole UI and is subject to involve a big code refactoring. Best regards. JBF