I disagree with the need for a fontwork sidebar. The feature is just not important enough respectively not frequently used.

(In reply to Heiko Tietze from comment #1)
> I disagree with the need for a fontwork sidebar. The feature is just not
> important enough respectively not frequently used.

But the cool thing is that if the user didn't use fontwork stuff it wasn't visible in the sidebar, but if it was used, the edit stuff will be available. 

So in the end it didn't clutter the UI and help people how use this feature. In addition maybe in the future someone add additional edit fontwork stuff or for example an template drop down menu to change settings, which will fit perfect into an sidebar UI but not to the toolbar.

The Toolbar seems sufficient as the active Fontwork object already responds to fill, weight, and color formatting shown/set from the SB Properties deck.

The NB modes pick up the Fontwork Toolbar UNO controls cleanly.

Really seems there is not much to be added with a SB content pannel, and where would it be positioned? Probably not as a Deck on its own, maybe into the Gallery deck? 

I think best thing here would be not to implement.

-1

There is also an sidebar only layout available in libo. Why should I see an toolbar pop up, when I want to use the sidebar only. And in property deck it should pop up like for example the notebookbar.

Context commands are implemented so you only need an .UI file for the sidebar and link it. Otherwise the sidebar will be empty.

(In reply to andreas_k from comment #4)
> There is also an sidebar only layout available in libo. Why should I see an
> toolbar pop up, when I want to use the sidebar only. And in property deck it
> should pop up like for example the notebookbar.
> 
> Context commands are implemented so you only need an .UI file for the
> sidebar and link it. Otherwise the sidebar will be empty.

Really? Looks to me that the 'Sidebar' UI mode is heavily Toolbar enabled. With a Fontwork draw object active, in addition to the Standard TB, we get the Drawing Object TB docked top and the Fontwork TB docked to bottom of frame.

The hybrid Contextual Single NB, with SB opened, does pretty well adjusting to Fontwork object.

So, really don't see benefit to adding a dedicated Fontwork content panel for the few UNO controls needed from the toolbar:

Insert Fontwork Text
Fontwork Shape
Fontwork Same Letter Heights
Fontwork Allignment
Fontwork Character Spacing

and maybe controls from the 3D-Settings Toolbar, when the Fontworks shape is extruded.

Created attachment 165550 [details]
sidebar layout when select fontwork

(In reply to V Stuart Foote from comment #5)
> Really? Looks to me that the 'Sidebar' UI mode is heavily Toolbar enabled.
> With a Fontwork draw object active, in addition to the Standard TB, we get
> the Drawing Object TB docked top and the Fontwork TB docked to bottom of
> frame.

yes and that's frustrated. (If possible) the sidebar layout didn't need additional toolbars. As you can see in the screenshot the "drawing object property" toolbar commands are available in the sidebar only the fontwork specific ones are missing. 

And yes if I want the sidebar I want to see ONLY the sidebar and maybe the default toolbar. In draw you don't have the "drawing object property" toolbar visible for example.

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.

(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)

@Telesto: there are many questions and also suggestions in your post. But, the fact we decided yesterday against the implementation of a Fontwork sidebar was simply done by orientation on the UX guideline, as you can find under:
https://wiki.documentfoundation.org/Design/Guidelines

Combined with the UX principles https://wiki.documentfoundation.org/Design/Principles do the lead our common way.

I would like to suggest changes on the sidebar behaviour and add additional principles for my suggestions. But this would mean discussions of the whole UX team. So I rather keep it up for now and subordinate myself to those principles as they are.