https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #1 from Mike Kaganski <mikekagan...@hotmail.com> ---
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to