https://bugs.documentfoundation.org/show_bug.cgi?id=149230
--- Comment #11 from Eyal Rozenberg <[email protected]> --- (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?" -- You are receiving this mail because: You are the assignee for the bug.
