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: [email protected]
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
