Design/Whiteboards/Styles Management: proposals collection

    From The Document Foundation Wiki

    Current status: work in progress - please don't hold your breath

    Summary

    Styles are one of the "fortes" of LibreOffice, but still one of its weaknesses. They're hard to master, quircky and somewhat hidden. A lot of good ideas have appeared in the mailing lists (main references: https://www.mail-archive.com/design@global.libreoffice.org/ and https://lists.freedesktop.org/archives/libreoffice-ux-advise/ -- there's still the bugs list to go through). This page tries to collect all of them, in an organized form. Please be free to add any one that might have been left out.


    The collection

    There are four main elements to styles management. They are: (1) the dropdown and button in the toolbar, the main menu and the context menu; (2) the styles and formatting window, AKA "stylist"; (3) the Properties dialog and (4) the logical elements, i.e. the styles themselves and their organization (categories, hierarchy etc.). Each suggestion should fall into one of these 4 elements, and are divided this way in this collection.


    Toolbar, Main menu, Context menu

    Checkbox in toolbar sets AutoUpdate

    • Description

    A simple checkbox in the main toolbar that allows current style to be set to AutoUpdate, without the need to go through the properties dialog or even the Stylist. It would affect only paragraph styles, as they're the only ones accessible through the toolbar.

    • Why?

    One page documents require a lot of work when formatting with styles, unless one uses no more than the basic 4 styles (Text Body and Headings 1, 2, 3) accessible through the toolbar, and still only if one doesn't change them. This would allow one page documents to be formatted with styles with much ease and speed. Moreof, the Stylist is hidden by default, so this would take styles management closer to the unexperienced user.

    • Contras
    1. There's still no clear way of showing users how this works, which could confuse them. AutoUpdate is prone to surprise users with unexpected behavior unless they already know what's going on.
    2. This is a lame idea, this belongs to the Stylist for sure, but not the toolbar. Besides, we'll have much better Template management and basic styles defaults, so this is not a thing to worry about.
    • To Do
    1. Think of an icon or small phrase that could fit into the toolbar next to the checkbox and the styles dropdown, which could be self-explanatory of the feature it affects. Might just "AutoUpdate" work?
    2. This would still not allow the use of more than the 4 basic styles without the need to access the Stylist.
    3. There's still no way of using Character styles in a seemingly quick way, so this would solve only half the problem.
    • Assigned to / author of proposal

    // this one is just a placeholder //

    • Discussion and links

    Mail thread

    Style selector/status bar

    • Description

    A separate selector and/or status bar indicator for current selection styles. This would be much the same as we have for Paragraph styles, but could be applied to all types of styles (character, page etc.).

    • To Do

    Design: where do we put this, and how does it look?

    • Assigned to / author of proposal

    Ricardo

    • Discussion and links

    Mail thread An image is worth a thousand words


    Stylist

    Selected view for Stylist should be remembered

    • Description

    Stylist have a choice of style categories to be viewed, e.g. Hierarchical, Applied Styles or All Styles. This choice is common for Paragraph styles, Character styles and son on. The choice should be style type specific, so one could have Hierarchical view for Paragraph styles, and Applied Styles view for Character styles, for instance, without the need to change view every time he goes from Paragraph to Character list of styles.

    • Why?

    This improves workflow and is more logical, since the use of different types of style diverse, and not all of them are suitable for all kinds of view (for example, there is not such a thing as hierarchical page styles).

    • Contras

    None from the usability point of view.

    • To Do

    Nothing on design side. Discuss and talk to developers about viability.

    • Assigned to / author of proposal

    zapyon at gmx.net

    • Discussion and links

    Mail thread i#91094


    Properties Dialog

    .

    Logic and organization

    Style cut down and redefinition

    • Description

    It has been mentioned a handful of times that LibreOffice has just too many styles, and that the majority of them don't present significant difference from the others to justify them as single styles. They need to be cut down to only the essential ones, leaving out those which are redundant or that could be merged with another due to resemblance, and those that are so rarely used that don't justify the clutter implied with their keeping.

    • Why

    LibreOffice has so many features that there's few people that can master the majority of them. Same applies to styles: there are so many of them, one can hardly find a use for them all. Plus, styles are difficult to master, and the fact that there are just so many of them makes it more confusing and difficult to learn. Stripping them down could make this much appreciated feature more usable for both beginners and professionals. Redefining the remaining styles would add for good looking documents and good defaults, making the whole formatting process easier and faster, while retaining its power.

    • Contra

    This is an anti-feature, since we will actually remove functionality. While the reason for this is noble, making the software less cluttered and easier on the learning curve, there are a part of the user base that could feel handicapped by this change. This must be done extra-carefully.

    • To Do
    1. Select which styles are necessary
    2. Get user cases for the dubious or rarely used styles
    3. Detect redundant styles, and those that can be merged together
    4. Redefine remaining styles for beauty and usefulness
    5. Preferably, but not necessarily, in that order
    6. Plus, see below for Bullets, numbering and outline and its relation with styles
    • Discussion and links

    Please add as stumbling on, there are just too many.

    Templates

    • Definition

    There is, similar to the above, a lack of templates available to the public, and less of them to make a good use of styles so as to make good formatting of common kinds of documents easier and more consistent.

    • Contra

    Is this still true?

    • To Do

    Please update on this issue, and link to the discussion.

    Linking Page styles

    • Definition

    Linking, or inheriting, styles are a mighty feature, but Page styles don't have it.

    • To Do

    Not sure how this would be implemented, not even if there's something on the design/usability side to check.

    • Discussion

    Mail mention

    • Assigned to / author of proposal

    Ricardo

    Math styles

    • Definition

    Those are absolutely absent, but would certainly be useful.

    • To Do

    Not sure how this would be implemented, not even if there's something on the design/usability side to check.

    • Discussion

    Mail mention

    • Assigned to / author of proposal

    Ricardo

    Table styles

    • Definition

    There are shortcomings in the autoformat for tables, table styles could come as a solution for this.

    • To Do

    This would require a whole road plan.

    • Discussion

    Mail mention

    • Assigned to / author of proposal

    Ricardo

    Drop the term "style"

    • Description

    The term "style" don't describe with precision what it refers to. It should be dropped for something else.

    • Contras

    The term "style" is well assented, and the option proposed, "template", already describes something else. It has been pointed that the chain Format->Style->Template is good as is and shouldn't be messed up with. Besides, "style" describes something we are used to, it is a metaphor for our dressing and it suits and describes well what we do with them in an office suite. (Ricardo)

    • Discussion and links

    Mail thread

    Show XML tags in the interface

    • Description

    Styles are defined by rules, which are written as tags in the XML file. These tags could appear (in a changed form) in the interface, so they could be dealt with directly, or through a dialog.

    • Why?

    This would allow for deletion and import/export functions of single rules in a style.

    • Contras

    The interface would grow clumsy; there's is already the properties dialog for that (which could be improved, but that's another project.

    • Discussion and links

    Mail thread


    Problems still to be addressed

    Here goes other problems we sense, or have otherwise been pointed out in bugzilla or surveys but still don't have a proper solution.

    Duplicated properties dialog / precedence of direct formatting

    There is the properties dialog for each style, and then there is the properties dialog accessible through the toolbars, the main menu and the context menu. They're much the same, except one goes for direct formatting and the other one for style formatting. They are both concurrent, so one could add a direct formatting to an existing style-formatted element (word, phrase, figure, cell whatever). While this is intended behaviour, it is somewhat confusing, and suggests style formatting is not the main way of doing things, since it is accessible only though a button and dropdown in the menubar, while direct formatting is accessible from 3 different places. It makes use of direct formatting prefered by design, when there is a general recomendation on using style formatting (or is this disputed?). It should be addressed that style formatting is at least as much accessible/apparent as direct formatting.

    Bullets, numbering and outline clarifying

    Quoting Ricardo (not the economist): "we have a powerful, solid but obscure system for numbering. Once you understand how it works, it's just great, but learning how it works... not an easy task." How does a user knows there are two incompatible ways for numbering, so he chooses one? How do you understand the logic around associating outlines and styles, and moreover, Outlines and numbering styles? How do list and numbering Paragraph styles relate to list and numbering List styles? Does this work as it should, or there are duplicate formatting that confuse things? Ricardo said he has a book on this, but is there a way to work with them without reading that book (even if it's really cool?). Chris Noack suggests this documentation to help understanding how it works, and suggests also that "1) re-define the paragraph styles related to numbering by referring to the numbering styles having the same name; 2) manual numberings / lists should inherit the settings of the first "corresponding" numbering style".

    • Discussion

    Mail thread