In terms of formatting, there cannot be a definitive hierarchy of which, between a style, and direct format, overrides the other!There are legitimate cases where a user has applied a style and then wants to tweak it, vs a user has hand crafted attributes directly but only afterwards applies a style. In both cases, the style will be a superset of the directly set attributes and which one wins cannot be programmatically determined, nor just asserted as 'the rule'!
Do you have an example where styles don't suit well? For sure there are many (if not most) users who format text directly due to various reasons. But using styles should always be possible and as simple as DF.
---Perhaps I was unclear. I am not advocating for styles over DF or DF over styles. I am just noting that both are possible and may be used in any order at any time. Orthogonal to that observation I noted that DF operates on ONE attribute of an object but a style operates on ALL attributes of an object - even if the user has only changed ONE or a FEW attributes from their default values.
The result of this, of necessity, is a choice between keeping or overriding the values first set.
As I said, DF of a particular attribute (X) may have been set first, then later, a style is applied. Does the value of the attribute (X) from the style overwrite the value from the value previously set by DF?
If the value of attribute (X) is first applied by a style, does a subsequent DF edit of attribute (X) overwrite the style's value.
I think in both cases the new overwrites the old but with a facility to drop all direct formatting (DF), in favour of the values in the applied style.
Styles are clearly preferable for graphical & typographical consistency in a document and for a business brand but there are edge cases where a minor manual tweak achieves what the user wants. The common and worst case scenario are documents that are mostly DF, where it's pure luck whether the author has kept any consistency. This is absolutely awful in circumstances where (often) a developer has authored a presentation or doc without any styles but the presentation has to be delivered or 'branded' by a designer - it's basically start from scratch, applying styles and takes ages. (just off the cuff, I wonder whether a k-means analysis tool that looks for the closest fit of DF attributes to a style could populate a 'migrate back to a style driven doc' to-do list - if this isn't clear, I'd be happy to discuss in detail but I think it could be a really, really useful tool and differentiate Libre Office - I worked on k-means analysis for mainframe security ease of use.
I think the major problem is that many/most users either don't understand the value of styles or find the poor UX design & implementation of styles too confusing and so DF is the easiest strategy to adopt. I suspect it's not even a strategy, it's just a much lower cognitive load to think "I want this artefact to have this property/look" - and "here's the setting to do exactly that". It's a step up the cognitive ladder to say "if I create a style, which includes thinking about the aesthetic of the whole doc, I have to set many attributes, not just the one I need now, but I'll gain complete consistency, ease of application, stay on brand, share, etc"
It seems to me that some UI flexibility is needed here, where there is an easy default that the user can override, should they require more control. The usage patterns could look like:*Definition of a style: * A style is a named set of related attributes that have default values but where each of the attributes can be changed to a preferred valid value. The set can be saved with a style name and can only be applied to compatible objects, as a set. The applied style inherits from the base style, so within the scope of the document (or section??) changes to the base style will be reflected accordingly. The valid set can be saved, with different names as different styles; all equally but exclusively applicable to a compatible object.
I like it. It perfectly describes what we do. Yet rather from the documentation POV than UI/UX though. If you think this belongs to the HIG you are welcome to create a new page.
---Happy to do that. As for a UX definition of a style, I think that it should major on the attributes I mentioned in my response above:
*More description than definition: *A style contains all the style attributes for an object. Often, a graphic designer will create a set of styles that I can use to ensure my document maintains complete consistency and remains on brand. If I create my own set of styles, there is some up-front effort but it will ensure my document is consistent, and it's easy to apply the styles to this and subsequent documents. I can even share them
*If a style contains the universal set of attributes, any direct formatting will always clash with a valid style for that object!
DF does not clash but overrides styles. If you indent a paragraph via DF, changing the style wont apply to this text. Unlike styles, DF is an arbitrary combination of attributes- and clearing DF removes all those attributes. (With some exceptions, eg. lists.)
--As I said earlier there will be a clash, in the sense that a decision has to be made about which value to keep. As you've stated, there are cases where those decisions have been made - that doesn't mean we have to stick with those decisions. Why, for example would you stick with a para indent but not a font or font size, when subsequently applying a style that is opinionated on all three attributes? Would behavioural consistency not be a better strategy? You've also mentioned the 'drop DF' function here, which I think is necessary.
I would also say that for ease of use, there should be a close, but not exclusive relationship between a style and the attribute value settings dialogue, so the attributes CAN be applied as direct settings OR as a style (probably should be the same dialogue but two different contexts).
I wonder what issues you see regarding styles and DF. Better start off with the problem, right.
---My only point here is that the facilities (dialogues, context menus, properties, etc) should be the same, whether used for DF or style editing and a minor point about their slickness (modality, positioning, etc)
Regards Greg Lubel (UX/UI Designer) -- To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy