[Libreoffice-qa] [libreoffice-design] Minutes from the UX/design meeting 2023-Jul-13

[Eyal Rozenberg]

Oh, no, no, no, come on... I know I wasn't in the session (which I
couldn't since it was in the middle of a workday), but - there had been
extensive discussion on the bug pages, and the session itself seems to
have just ignore it all. This is really exasperating.


------------------------------------------


 >   * Autocorrect replaces " - " with " – " instead of " — "
 >     (en-dash instead of em-dash)
 >     + typically two hyphen is an EN-dash, three EM (Heiko)

I've explained several times on the bug page that this bug is not about
when people are trying to explicitly express a choice between the two
kinds of longer dashes.

 >     + two dashes with / without spaces is kind of standard and
 >       working like this in MSO (Hossein)

Same point. Heiko had definitely read the bug page, so he should have
known this already; Hossein - perhaps the bug was mis-described in the
Jitsi session and you didn't have the time to read the comments?

 >     + maybe drop the conversion of single hyphen (Stuart)

(This is not a misinterpretation, but it may be inspired by the
misinterpretation above) Of course not drop the conversion of a single
hyphen! That's an very important autocorrect feature: Most people use
minus/dash because they are unaware of the different types of dashes, or
because they don't know / haven't thought about how to insert different
kinds of dashes (or because they're lazy). This autocorrection helps
improve the typesetting quality of the work of "lay users".

 >     + clearly described in
 > https://help.libreoffice.org/latest/en-US/text/shared/01/06040100.html

1. It clearly says in the help page that space,minus,space is replaced
with space,en-dash,space. Which is the behavior I'm suggesting be changed.
2. Help contents is never a justification for a choice of behavior of
the app itself.

 >     + two dashes without spaces like 1--2 is not correctly
 >       converted (Heiko)

That's interesting - but unrelated to this bug. Open a separate bug...
No "bug hijacking" with something which is clearly not part of the scope
of the original bug.

 >     => bug; do not change the behavior as described in the help

How does this conclusion relate even to what you guys were saying before?!

And other than Stewart's position (which I disagree with but nullifies
the question in this bug) - none of the discussants even tried to argue
that it is better for text to have space,en-dash,space's instead of
space,em-dash,space's.


------------------------------------------

>   * Support distinction rather than override of conflicting
>     subdocument styles
>     + https://bugs.documentfoundation.org/show_bug.cgi?id=155740
>     + unclear use case (David)
>     + some confirmation per document (Shu)
>       + if we better go with a global master switch (Heiko)
>     + master documents are a special workflow aiming for style
>       consistency, WF (Mike, Hossein)

No, they aren't. A single document is the workflow for absolute style
consistency. Master documents are workflows for composing a larger
document from smaller documents, _which well be valid documents on their
own_.

>     + unclear use case (David)

Second time this is said. Actually, third time, since this was said on
the bug page, and I clarified. What about that did not seem clear?

>     + copy/paste could solve alternative workflows (Shu)

If it could, we wouldn't need master documents in the first place.

And, again, that's just a repetition of points which had been made, and
rebutted, on the bug page. To make them again, one must address and
reject the rebuttal.

-------------------------------------------

>   * When setting the Heading/Outline Numbering for a level to "None",
>     still getting separators
>     + https://bugs.documentfoundation.org/show_bug.cgi?id=156089
>     + works like in MSO, WF (Justin)
>     + no reason to block, WF (Heiko)
>     + asking to _clear_ the separator fields in case of None (Eyal)
>       + remembering "Chapter/:" is not a (good) solution since users may
>         change it for None into "-/>", or the like, making it very
>         difficult to follow
>     + behavior existing for years shouldn't change without
>       good reasons (Hossein)
>     + list style is something you shouldn't change multiple times

Less frustrated about the objections here, but - the basic argument,
which was not rebutted, is that our current behavior is the opposite of
what the user expects to happen.

An especially problematic argument is "this has been the behavior for
years". Most of the bugs we consider in the design sessions are about
behaviors LO has had for years. That's not an argument against
addressing them, it's just a sign of the limitation of our resources.