In bug 135501 comment 81, ajlittoz made a good argument for improving LibreOffice UI in a way that encourages the use of styles. This task is about creating sketches for any or all of the UIs found in View - User Interface in order to make it appealing and convenient to use styles. The relevant part of ajlittoz's comment: UI is not the target in an application. The target is the usefulness of application purpose and UI is only a tool to serve this usefulness. What is the chore of LO and its distinctive power feature? Styles. Styles are present in Writer, Calc, Impress and Draw at different level of abstraction and power. Style usage should be encouraged by all means because they are the key to full LO power. When you must review and reformat a sophisticated document, the task is overwhelming if direct formatting was the base of the workflow. IMHO, M$ Office-like UIs are wrong because: 1 - they lead to the "intuitive application control" syndrome making users falsely think they master the application 2 - they encourage direct formatting because the alternative style control is not that obvious (and styles are far less developed in the competition) 3 - being immediately accessible, they postpone the need to read the Guides The net result is a tremendous number of angry questions on AskLO from users ranting that LO is not M$ Office. In my point of view, LO doesn't offer yet a full original style-oriented UI. In Writer, the paragraph styles sit in the toolbar with their own menu but character, frame, page and list are not there. You must display the side style pane and selecting one non-paragraph style requires first to click on an icon to change the displayed list. As a long-time advocate of styles, I find this is not the correct way to push users towards styling.
I'm sorry for a wall of text; I'm not good in sketches; and IMO what follows would be best presented in words, giving some ideas and reasons instead of images. Here is what I think about a possible direction of such an UI. One of the powers of styles is their customizability and flexibility; but that is one of the biggest challenges in creating a UI that would both promote use of styles, and at the same time be usable even for newbies. Direct formatting talks in "static" terms; "Caladea" font, or 12 pt, or "Bold" is ~same on any system and in any application (we don't dive into what "bold" *might* mean for a really advanced typography lover). But what does "Style X" mean? It depends on a document, maybe on template, or even on a software version (when we might change the defaults). OTOH, there's no more "natural" place to look for most used tools (at least for most users on this Earth) than on the top of the application window, the place where most UIs have something like menu, or toolbars, or notebookbar, etc. - the areas usually packed by default with direct formatting elements. So IMO it's natural to try to create a UI that would resemble current existing UI, just having individual controls doing conceptually different tasks. The new controls need to drive user attention to the structural, semantical meaning of the change ("formatting") they do, rather than on the resulting look. That should be done using *names* of the controls - the names need to allow user to grasp the idea how that would look like (at least by default), so that new user would still realize what to press, and yet need to not mention the specific appearance details (no "bold"/"italic" and so on). I suppose that it would be reasonable to try to reuse the existing pre-defined style set (I focus on Writer now) to provide a set of controls that would suggest to apply *syntactic* meaning to text, where currently similar controls allow to apply direct formatting. They could suggest to *emphasize* text (= apply Emphasis style by default); or "create citation"; or "make it a heading". (By the way, many Web tools already suggest similar concepts - like buttons making some text "quotation" or "source code", so possibly that could be partially familiar to users.) The controls need to have a way to immediately *customize* the look of the applied style (= open style settings dialog); and also to define another style associated with the control (so that users could decide to use own set of styles with the same buttons, where they decide to not use pre-defined styles for some reason). Some of such controls have a natural need to have selection over variants (Heading N). The set of the controls need to allow creating wide range of documents - but indeed, there can't be a truly all-encompassing UI, so there would be no need to pack it with every possible style. Whenever the user needs more styles (categories of styles) that are provided by the top panels, they need (and likely are ready for) style manager (F11) and other more advanced tools. There need to be a way to apply direct formatting - but those controls need to only appear on explicit request ("Format selection directly", maybe showing some toolbar that would close automatically after use). I hope that the correct naming of the controls that user uses since the start, every day, suggesting them to think what the text will mean as a result of a button press, could shift the focus gradually from the DF-centric to semantical meaning, allowing natural pre-adaptation to acceptance of styles and their conscious use (beyond pressing the toolbar buttons).
I didn't want to sidetrack the discussion on bug 135501, so I did not answer ajlittoz there, but I do have a few points to make about it... * The "usefulness of an application" and the quality of its UI are not distinct things. The User Interface is how you _use_ the application. If it is _useful_, then its amenable to _use_. So a good UI _is_ part of the objective of LO. By analogy, a good handle grip is part of what makes a hammer useful - even if, eventually, a hammer is about forceful blows, not about gripping. So, when producing a hammer, it is definitely part of the objective to give it a good handle grip. > Style usage should be encouraged by all means No. It should be encouraged by some means - but not to the extent of making it difficult to create a simple document with direct formatting, or to make direct-formatting changes to an existing document. > M$ Office-like UIs are wrong Do you mean ribbons? > they lead to the "intuitive application control" syndrome Never heard of that, but - I think I disagree. Ribbons make it clear that you do _not_ control the application and, instead, are spoon-fed a subset of its features. > they encourage direct formatting because the alternative style control is not that obvious The main ribbon in MS Office has styles at the center of it, plus you have the Style bar. There's room for improvement, but styles are quite visible. > being immediately accessible How are ribbons more "immediately accessible" than menus? Or do you mean the single, main ribbon > In my point of view, LO doesn't offer yet a full original style-oriented UI. This is the interesting part. I'd love to see some ideas for that.
(In reply to Mike Kaganski from comment #1) > So IMO it's natural ... etc. etc. ... no "bold"/"italic" and so on For a rather spartan example, but which take this approach at least partially, have a look at the LyX editor of LaTeX documents. It calls its approach "what you see is what you mean"; you mostly just can't apply direct formatting - although it is not oriented towards customizing styles. https://www.lyx.org/Screenshots (I'm not saying we should adopt any of this.) > I suppose that it would be reasonable to try to reuse the existing > pre-defined style set (I focus on Writer now) to provide a set of controls > that would suggest to apply *syntactic* meaning to text, where currently > similar controls allow to apply direct formatting. They could suggest to > *emphasize* text (= apply Emphasis style by default); or "create citation"; > or "make it a heading". (By the way, many Web tools already suggest similar > concepts - like buttons making some text "quotation" or "source code", so > possibly that could be partially familiar to users.) Indeed, the default style set is under-utilized. Its presentation is currently only a hint of something which you might want to use. I would also expect there to be UI which is "inviting" to the user to share information about aspects of their intended structure. One possible example would be numbering. Instead of the UI focusing on how a number/bullet and indentation would look on the current paragraph (which is the focus of both the buttons and the dialog right now), the focus would be the user telling LO about a list that they want to have: Whether is it a one-off list or whether they want to have recurring lists of the same kind; whether it is contiguous or interspersed with other content; whether list items are no-paragraph, a single-paragraph or multi-paragraph (do we have an open issue about this feature?); what name should this kind of list be given (= the style); whether it is single-level or multi-level; and on with features such as association with paragraph styles. This could happen in an "add list" wizard. And we could have a "convert to list" wizard. If those were the buttons rather than "slap a number onto it and don't ask any questions", you could say we have moved the UI to be more style-focused. This makes me think of how, when examining existing styles (default or non-default), we are not presented with their raison d'etre, or if you will, the "elevator pitch" for using them. They're just names in a list (or tree) in a sidebar. Guidance on how to format with styles should also be more immediately accessible (in the sense of "Are you trying to do X? Let us explain how you can do it the LO way" and such). > and other more advanced tools. Perhaps a style search, which in addition the the style name, would also search some paragraph(s) of explanatory text about when and what for the style is to be used. > There need to be a way to apply direct formatting - but those controls need > to only appear on explicit request ("Format selection directly", maybe > showing some toolbar that would close automatically after use). Or perhaps with a global toggle between "Style-oriented mode" and "Direct-formatting-oriented mode". > I hope that the correct naming of the controls This is important. But the button design would be even more challenging, since the level of abstraction buttons represents would now typically rise.
I agree with Eyal statement that styles "should be encouraged by some means - but not to the extent of making it difficult to create a simple document with direct formatting, or to make direct-formatting changes to an existing document." To that end, we should provide some new features for users who are interested in using styles in their documents and that will make their lives easier. I'll share a few ideas: 1) Create a feature to "Mark all direct formatting". In Writer, this would search the document and highlight which portions were formatted with Direct formatting instead of styles. This would also be useful while inspecting documents (such as books, theses, etc) in search of portions of text where direct formatting would be in the way of styles. 2) In Writer we could create an edit mode called "Prefer styles over direct formatting". If this mode were ON, applied styles would have precedence over direct formatting on the entire document. Also, every time the user applies direct formatting, Writer could add a yellow-line (similar to the red line) below the text emphasizing that this portion is formatted with direct formatting, indicating that this is not desirable in a style-oriented document. Placing the mouse over such "yellow line" could suggest similar styles to apply or even recommend creating a style based on this section of text, which would automatically apply to all other occurrences of the same direct formatting. 3) We could add an option to automatically detect all occurrences of direct formatting in the text and group them by frequency, such that we show the user common direct formatting options used in the document. This would help identify possible missing styles and let the user create new styles based on them. I know all of my ideas are vague, but maybe they may lead to some more refined ideas.
(In reply to Rafael Lima from comment #4) Your proposal has two main parts: 1. #1, #3: detect existing DF. This is something targeted on resolving *problems*, i.e., it's not a feature to help *creating and working* on documents normally, but a means to rectify some document causing headaches because of its (lack of) structure. While it's useful, I disagree that this mental model should be considered the main UI part. IMO we should not make Writer look like repairment toolset (which is the central part *currently* for anyone *already fluent with styles*, and who has to rectify everything before starting to work creatively). Its UI should focus on ease of creation good documents from start to end, using proper tools, so *initially* I suggest to focus on an idealized workflow as if user does not use DF in wrong ways, and the existing documents and templates are using styles. So for that idealized model, the UI would *not* need repairment tools at all. Start with some limited workflow where all the content comes from user typing and drawing themselves, and make that comfortable using styles as main tool. Then extend the workflow to pieces of content coming from outside, like using clipboard - and then again, don't focus on repair, but think what workflow could make it correct from start (e.g., what limits usefulness of paste as plain text? that it drops *content* and *styles* along with other formatting. Imagine "Paste with clean formatting" pasting rich content, and only dropping DF in the process automatically, and make it the default paste - and one place where we need repairs would be gone). After a UI is prepared with that mental model, we could *then* think how to supplement it with convenience tools to repair what needs repair. Also that part alienates DF completely, making it something completely "bad", to be avoided at all cost. Note that that approach is wrong. There are lots of DF that is OK and beneficial, and which lack would force users to have exponentially growing number of styles: e.g., each time I switch keyboard layout from English to Russian on my Windows system, my Writer applies a DF with respective language to the typed text, and I don't need two paragraph texts, two emphasized texts, two footnotes, ... Same for rsid - the identified added as DF to allow comparing documents better. Not to mention many legitimate one-off DF use cases. Writer has styles *and* DF, and the goal should not be "never ever use DF". 2. #2: make documents ODF-incompliant, and in fact make DF completely useless (simply because if styles have precedence over DF, it is equivalent to DF completely absent: there is no formatting that is not defined in some style (e.g., in paragraph style) at least implicitly; so no matter what DF you would try to apply, it would not be used, because respective formatting from paragraph style would be used).
(In reply to Rafael Lima from comment #4) > This would also be useful while inspecting documents (such as books, theses, > etc) in search of portions of text where direct formatting would be in the > way of styles. Unfortunately, it will very often be the case that _most_ of the document will be marked. In fact, when only a small fraction of the document is marked, the author is likely already using styles for most things... > 2) In Writer we could create an edit mode called "Prefer styles over direct > formatting". If this mode were ON, applied styles would have precedence over > direct formatting on the entire document. What would that precedence mean? > 3) We could add an option to automatically detect all occurrences of direct > formatting in the text and group them by frequency, Note that MS Office can show pseudo-styles - combinations of direct formatting - in the styles bar, and lets you select all items with the same pseudo-style, possibly replacing it with an actual style.
Some bugs related to Rafael Lima's suggestion and my reply: * Bug 127712, regarding whether applying a style clears direct formatting. * Bug 147769, regarding selection of all content with a specific style or specific DF.
Since I seem to be the culprit for causing this discussion, I'll elaborate a bit on my idea about style UI. First of all, a document processing app like Writer is used for various purposes (types of document) by people with very different skills and typographical culture. The UI must not be repellent and block people from using it. It must allow to play with the app and discover what it can do without forcing people to read a thick austere documentation. After all, I started using it pressing buttons, using formatting menus, in short direct formatting my documents. With time, I learned how to structure my mind about writing principles and switched more and more towards styles, discovering progressively the tremendous advantages of separating contents and "shape". A UI should allow both "discovery" and "expert" uses. In "discovery" mode, the available commands are presented without any "organising" and educational goal. They are just here and user may test or combine them in any way. "Expert" mode should encourage a more structured approach, implementing or being support for a writing method. LO has a highly valuable feature in the choice of UI. In addition to the present toolbars/menus, we could have this new "expert" toolbar with an emphasis on styles. This would not disrupt present habits with existing UIs. Direct formatting is not a sin per se. There are many "commands" which can't be driven by a style, e.g. restarting a list number. So, an "absolutely-no-DF" methodology is not possible. However, using DF judiciously and consistently requires an expert knowledge of Writer possibilities. I'd say that DF is the approach of a complete newbie and at the extreme opposite of an absolute guru, the gap between both being style formatting. Also suggesting that in "expert" mode, style formatting should override DF is a fundamental flaw. Independently from Mike Kaganski's argument, having mode-dependent precedence rules is a huge flaw. We can't have para-char-DF in standard modes and DF-para-char in "expert/styled" mode. This will confuse users even more than Writer (see M.K.'s argument). In short, a style-oriented UI could be an additional UI, an arrangement of existing UI bits in a specific combination of menus and toolbars. Users will ultimately be free to choose this or not according to his skills and methodology.
Since the discussion is going towards Writer only: we have the meta ticket for a "Style-focused formatting toolbar" with bug 117022. In fact, the inbuilt "Formatting (Styles)" toolbar is meant as replacement for the ordinary Formatting toolbar. However, I would challenge the idea of educating users (just for sake of the argument). We can force users into learning a paradigm or - the actual challenge for UX/IT - make the software smart. Simple solution is to change DF = bold into CS = Emphasis (with the only attribute bold). Or change two empty paragraphs into a heading plus spacing. But I believe this "convenience solution" would be the wrong way even when requested by the users. Competitors do so - on cost at flexibility and clearness. Everyone who tried to work with styles in MS Word knows that LibreOffice is way superior in this regards. My solution would be to not force users into a certain workflow but rather give better feedback. Like done/planned with the accessibility checker or suggested in bug 38194. We could show a "traffic light indicator" in the statusbar with green in case of no DF and a low number of PS/CS, yellow for a few DF or large number of PS/CS, and red.
(In reply to Mike Kaganski from comment #5) > (In reply to Rafael Lima from comment #4) > After a UI is prepared with that mental model, we could *then* think how to > supplement it with convenience tools to repair what needs repair. Hi Mike, I agree with your point of view. My idea while proposing these "repair tools" is that when users are interested in being compliant with styles, they will enable these tools and seek to achieve a document that is free from any warnings concerning the application of styles. Over time this can educate users to a new workflow that avoid these warnings. But again, I get your point that we should rethink the entire workflow so that using Styles become the "natural" way. Your idea reminds me a bit of how Latex works: when you use some markup code, the final document will be rendered based on a template that explains how that markup should be rendered. The main problem with all word processors (Writer, Word, Google Docs, etc) is that when the user enters the main application, he/she has a blank page to type text into and a main Toolbar (or ribbon) with DF commands to choose the font name, size and apply bold, italic and underline. This is the same as telling them that using DF is the way we expect them to use the application. (In reply to Heiko Tietze from comment #9) > In fact, the inbuilt "Formatting (Styles)" toolbar is meant as replacement for the ordinary Formatting toolbar. We could provide a standard interface where the user is faced with commands in the main toolbar where he/she has to choose headings, emphasis level, etc (all of them style-based). I for one did not know about this "Formatting (Styles)" toolbar, since I use mostly the Tabbed UI. But I think that presenting the user with such a set of tools from the beginning would be a way to let them know how we think Writer should be used. > Since the discussion is going towards Writer only As for other LO applications (Calc, Impress and Draw) styles will have very different roles and their current implementation do now allow for a deeper discussion. For instance, in Impress/Draw we do not have Character, Paragraph and Numbering styles, which would be crucial for us to have a Style-oriented UI. In Calc, styles are only applied at the cell level. We should have at least Chart styles and Table styles (see bug 132780) to start discussing a style-oriented UI for Calc. Let alone that Writer does not support shape styles (which are supported by Impress).
(In reply to Heiko Tietze from comment #9) > Since the discussion is going towards Writer only Sadly, we do tend to do that... but TBH: * Calc work involves a lot less styling, typically, regardless of whether it's DF or cell/text styles. * Impress and Draw are under-developed IMHO w.r.t. styles, so there's less to expose with the UI. Is there a meta-bug about this? > However, I would challenge the idea of educating users (just for sake of the > argument). We can force users into learning a paradigm or - the actual > challenge for UX/IT - make the software smart. Simple solution is to change > DF = bold into CS = Emphasis (with the only attribute bold). Or change two > empty paragraphs into a heading plus spacing. Some changes are more difficult to accept in a deeper sense. For example, if you change the empty paragraph into a heading + space - the heading style you would choose would likely not be what the user expected, and they would be tempted to either DF the heading, or just undo the change. I'm not sure the user would realize "oh, I should specify the semantics of my document elements rather than their visual layout/styling". I wonder if users could be encouraged to watch a tutorial about preferring styles over DF. > But I believe this "convenience solution" would be the wrong way even when > requested by the users. Competitors do so - on cost at flexibility and > clearness. Everyone who tried to work with styles in MS Word knows that > LibreOffice is way superior in this regards. in most aspects of style handling. It's still easier to convert a bunch of identical DF into a style in MS Word. > My solution would be to not force users into a certain workflow but rather > give better feedback. But the argument is that our current UI nudges users towards DF and does not make the use of styles obvious/attractive enough. > We could show a "traffic light indicator" in the > statusbar with green in case of no DF and a low number of PS/CS, yellow for > a few DF or large number of PS/CS, and red. Before doing that, we should think about how to explain what such a traffic light means; which brings me to wondering about whether there could be some official tutorial, static or dynamic, for "DF is bad, Don't do DF, mmmmkay?"
(In reply to Eyal Rozenberg from comment #11) > * Impress and Draw are under-developed IMHO w.r.t. styles, so there's less > to expose with the UI. Is there a meta-bug about this? Answering myself: Well, there's Bug 90497 about implementing "themes", which is at least part of what's missing. And of course, there's the Impress-and-Draw-Styles meta-bug, Bug 100373.
We discussed the topic in the design meeting (and I messed up with attributing comments to persons). Most of the discussion has been done here and I suggest to make it a duplicate of bug 117022 (or resolve WF). We could also aim for a new UI variant to more easily switch from "Standard" to "Style focused" but comments in bug 135501 indicated that we have too many options right now. Ultimately the ticket has no clear goal and is hard to decide.
Ok, let's not ask for sketches, then *** This bug has been marked as a duplicate of bug 117022 ***
This is totally not a dupe of bug 117022, which is much much more specific. Please consider reopening.
Ok, let's create sketches
Don't see a BZ ticket requesting sketches as actionable. Make it INVALID if not a DUP.
(In reply to Heiko Tietze from comment #17) > Don't see a BZ ticket requesting sketches as actionable. Make it INVALID if > not a DUP. I don't get it, why?
(In reply to Buovjaga from comment #18) > I don't get it, why? What outcome could lead to a resolved state of this ticket?
(In reply to Heiko Tietze from comment #19) > (In reply to Buovjaga from comment #18) > > I don't get it, why? > > What outcome could lead to a resolved state of this ticket? After the most awesomest sketch is submitted. This requires quite some innovation.