[Libreoffice-bugs] [Bug 135871] Highlighting no fill is not the same as no fill; there is still direct formatting present according to paragraph style

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #37 from Mike Kaganski <mikekaganski at hotmail.com> ---
Let me try to express it another way.

People who try to show this behaviour as a bug are trying to think about
document structure when working with DF. This is a nonsense, and they trying to
display it as "Benjamin's" problem is absolutely wrong. They declare Benjamin
as someone who is thinking about structure (see comment 36 - "to (from the
naive user's perspective) toggle back to regular style"); they try to split
Benjamins into sub-types (see comment 31 - "And we should define types of
benjamins.. Grandma running LibreOffice twice a month. Something else as
Benjamin is working professionally. Not sure if UX has the typology say 40 type
of users with background story?").

But this is just wrong. DF is not about (even naive) ideas about document
structure (styling, or internal representation); Benjamin is not about
backgrounds, professional vs home, or even not using styles. Benjamin is a
person who may have whatever end goal or background; they use whatever tools
are there in the UI, but the big difference from Eve is that *they don't know
or think about structure*; they use the tools to express *immediate wish* to
change something to look as they want. DF must make that immediate idea happen:
"from now on (or for this selection) I want it to be bold"; "from now on I want
it to be not bold", etc. No more involved thinking here: just "make it look as
I want it". If a tool is doing what Benjamin wants, they use the tool; so that
may use styles (e.h., paragraph styles from the toolbar drop-down) without
thinking about structure. They may know that Heading 1 makes it large and bold,
and they only think about this formatting when use that tool, making something
bold and large; then they see that more than few words in the sentence become
bold, and use toolbar "B" button to make the rest of the sentence not bold; and
that must work for them in the way they expect - even though that workflow is
creating a mess of a structure. And that means that DF must be robust and
efficient in making unconditional changes: "not bold" or "not italic" must mean
"not bold *unconditionally*, no matter what", not "not bold *unless* there are
some things that Benjamin doesn't care or realize even existing, like styles
and their inheritance and structure and anything".

What Telesto and Luke are talking about is a bad mix of using DF and caring
about document structure. Document structure is *not* possible to use when
using DF, ever. Styles are for that.

That said, I am all ears about good proposals to make DF better in that
regards; but *any* such proposal *must* take into account *real* Benjamins -
see above - not those chimeras that Telesto and Luke are talking about, in the
first place: i.e., every such proposal must keep real Benjamins safe to keep
using those DF tools (mixed with styles used unconsciously, or coming from
outside) to make their work done, simply by pressing a toolbar button over a
selection or in a current position, and have the rest *look* as expected,
without caring about internals.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200920/f1ea54e4/attachment-0001.htm>