[Libreoffice-bugs] [Bug 136140] Sidebar: Fontwork sidebar is missing

Thu Sep 17 15:48:42 UTC 2020

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

--- Comment #8 from Telesto <telesto at surfxs.nl> ---
(In reply to Heiko Tietze from comment #7)
> We discussed the topic in the design meeting and agreed to not have fontwork
> in the sidebar. It's just to rarely used and well suited for a dialog.

Not objecting against the decisions here.. but still I would love some kind
guide(line) book for the fundamentals of LibreOffice UX design. 

This helps to have a frame work for communication, to understand UX decisions,
make arguments and might result in better discussions. And would make it
succession proof too. Else there is a risk of total different approach if
people move on etc.

Some area's of interest: 
Idea behind tabbed/toolbars etc. Is they sidebar seen an supplement or as an
replacement? Matters for topics like Fontwork in sidebar

Also something about accessibility matters. Not used to look at software from
this perspective. So some guidance would be helpful. (Reset button Paragraph
styles needed?)

Some descriptions of Benjamin and Eve users. There are plenty of
interpretations possible. Which makes communicating about user, user needs
rather hard. Someone is talking about Benjamins in company setting others about
Benjamin in home setting

Some guidelines about core features functionality and 'extras. Markdown isn't
essential core feature (sorry keep bringing this up). Which means (disabled by
default, IMHO). Or it might be even an extension. 

Same story with tabbed bars variants. 
So two questions: which parts get into LibreOffice itself, which part should be
extensions. And If it should be embedded with LibreOffice (default: on/off). 
And if something gets managed as extension how do you embedded it into dialogs
and such. 
Which also affects QA(more embedded settings, more stuff never gets tested;
will be broken (like Autocorrect -> Options -> Apply Style setting; currently
crashing; not enabled by default etc.. so not to often noticed).
However this is also matter of API etc.. can stuff be done with extensions..
And how do you embedded those 'advanced' features nicely. 

---
For the record: I don't expect a full blown documentation guideline from the
start. But seems practical to have a working in progress draft with some kind
UX guidelines for LibreOffice. I assume Linux distro's have something similar
(copy cat) 

This helps with making UX-decisions and communicating those. I would even
consider dumping every topic ever managed into it. As discussions of the past
explaining the current state of the GUI. It's pretty hard to accessible (split
across plenty of open (and closed bugs). And in mailing list. There is likely
much being said in 10 years LibreOffice (and probably in the time before)

It's always practical to know why Highlighting got a different tab and the
position it currently has (I personally tend to drop it into the font effects).
The major objection for me is the size of the dialog (it doesn't fit to well).
Note: I could think of subtabs, like highlighting tab has (non/color). So one
Font tab; with 3 area's (Font, Font effects & Highlighting). Objections might
be accessibility, in the sense of extra click. Or the size of the dialog

GUI guidelines should also list number clicks, depth of the setting (Character
Style is really hard to manage) without Inspector deck or Character style deck
open). And if sidebar is being intended as replacement this become even
harder.. And if Sidebar is intended as addition (it's also problematic; small
screens can't use the sidebar; style deck nor Inspector deck) [Can't remember
arguing about that]. So a checklist would also be nice, to having a list of
topics to take in consideration :-)

Might matter too in case of the whole sidebar resize individually issue; or the
add an configuration wizard on first launch (tabbed/toolbar) matter. If there
are UX-guidelines to minimize the usage of dialog to a minimum; it's already an
argument (to object). Or minimum requirements for like accessibility matters.

And also rules about 'naming of tools'. No-fill/no-fill. Or To Page anchoring.
Or Reset/Standard matter. 

And maybe even procedure of 'experiments'. I still think LibO fresh should be
used to do some UX experiments once in a while.. With risk of backfiring (and
last resort reverting). Sometimes arguing hard without data. A says people get
confused, bad idea. B says dramatic view, everything will be all right. We end
up in a status quo; a stand still. Might be liked by some, but dislike by
others. Do we really have to wait until someone else invented it? Or being
tremendously conservative.

It's a project (not a product). (Social/UX) experiments are allowed. [Except we
are seeing LibreOffice as a product.. TDF, what's the vision on this topic?]
Yes, might be sometimes work for nothing (implemented, backfired, revert) but
always adds something anyhow. Or knowledge or a different design..

However I assume some people don't like 'experiments' with fresh. While fresh
being for me more a public/beta/RC. As there is no large testing community;
everybody wants 'stable'; so they get an beta/RC called fresh.. 

It would generate attention (media) and people actually using it.. so potential
feedback.. drop an info bar with link to a poll.. how to you like they
changed.. 
Yes, telemetry might be better, but I assume this won't be enabled. And if
enabled quite a number people would opt out again (so being not to
representative either). Not sure what other sources could be used got get
insights.. 

O and for people preferring 'stable/ stable there they stable branch or maybe
even they eco-system partner super stable version. Lacking behind enough to be
guarded against sudden UX changes.. After say 1,5 years it must be clear if
something is working or not. But this is again depending on the commercials
interests of eco-system partners and the vision of TDF on this topic]. 

So quite number of topics stuck in the middle as long TDF/eco-system partners
don't have a vision/idea what direction to go. Even if it means throwing out
DOCX export as Eric proposed in his blog; leaving in the middle of this is the
right thing to do (i'm still seeing something in the export model). But this
are pretty questions in principle what LibreOffice; say MSO clone or something
else. I have seen enough emulation between handling in MSO and LibreOffice,
never will be exact MSO DOCX compatibility. While we are pretending being
compatible with direct save. The DOCX generated surely not naive MSO. Sometimes
at import/sometimes at export. Page breaks difference (page breaks all over the
place), table styles difference (dynamics lost), heading differences (export
produces DF + styles). Highlight colors (shading/highlighting + conversion)

-- 
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/20200917/986084c0/attachment.htm>