[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #20 from Buovjaga  ---
(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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #18 from Buovjaga  ---
(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?

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Buovjaga  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #16 from Buovjaga  ---
Ok, let's create sketches

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #15 from Eyal Rozenberg  ---
This is totally not a dupe of bug 117022, which is much much more specific.
Please consider reopening.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Buovjaga  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #14 from Buovjaga  ---
Ok, let's not ask for sketches, then

*** This bug has been marked as a duplicate of bug 117022 ***

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Heiko Tietze  changed:

   What|Removed |Added

 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda
   |.freedesktop.org|tion.org
   Keywords|difficultyInteresting,  |
   |easyHack, needsUXEval,  |
   |skillDesign |

--- Comment #13 from Heiko Tietze  ---
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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #12 from Eyal Rozenberg  ---
(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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #11 from Eyal Rozenberg  ---
(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, kay?"

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Eyal Rozenberg  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=14
   ||9271

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #10 from Rafael Lima  ---
(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).

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Heiko Tietze  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=11
   ||7022

--- Comment #9 from Heiko Tietze  ---
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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Heiko Tietze  changed:

   What|Removed |Added

   Keywords||needsUXEval
 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #8 from ajlittoz  ---
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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #7 from Eyal Rozenberg  ---
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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #6 from Eyal Rozenberg  ---
(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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-23 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #5 from Mike Kaganski  ---
(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).

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-23 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #4 from Rafael Lima  ---
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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-22 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #3 from Eyal Rozenberg  ---
(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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-22 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Eyal Rozenberg  changed:

   What|Removed |Added

 CC||eyalr...@gmx.com,
   ||page74010...@yahoo.fr

--- Comment #2 from Eyal Rozenberg  ---
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.

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

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-22 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

--- Comment #1 from Mike Kaganski  ---
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.

[Libreoffice-bugs] [Bug 149230] Create sketches for ajlittoz's vision of a UI promoting the use of styles

2022-05-22 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=149230

Buovjaga  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=13
   ||5501
 Status|UNCONFIRMED |NEW

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