The character-level UNO commands like .uno:CharFontName and .uno:FontHeight would need to be contextually sensitive so that they can modify both paragraph and character styles. So when the cursor is above text with a character style, it modifies the character style, else it modifies the paragraph style.

Having UNO commands for all properties duplicated, one for direct formatting like .uno:Bold the other for modifying the style .uno:BoldStyle, bloats our commands too much in my opinion. Plus, I don't see the need to quickly and easily change style properties. Just to have it on a toolbar? Keep it simple.

WF, IMHO.

I don't see why new uno commands are an issue of the UX team.

Anyway, these commands are necessary to fullfil the needs of people who want to work with styles instead of direct formatting (and also necessary for bug 106781 and others. Most commands in toolbars, sidebar, shortcuts are for direct formatting now. This is a disadvantage for style users and unlogical in the LO UI. You restrict the power of styles when closing this bug to avoid a handful of new commands?

(In reply to Thomas Lendo from comment #3)
> I don't see why new uno commands are an issue of the UX team.

Not the code but the user requirement and the benefits and drawbacks of new functions are in the UX business.

> Anyway, these commands are necessary to fullfil the needs of people who want
> to work with styles instead of direct formatting (and also necessary for bug
> 106781 and others. Most commands in toolbars, sidebar, shortcuts are for
> direct formatting now. This is a disadvantage for style users and unlogical
> in the LO UI. You restrict the power of styles when closing this bug to
> avoid a handful of new commands?

I expect a lot of confusion when Benjamin makes the style bold and unbolds after per direct formatting. Styles are not meant for this frequently and single-click modifications but a once in a time setup. And the dialog is perfectly suited for this.

A two step approach to reach the desired goal is: apply direct formatting, update style.
(And one can set a style to auto-update, of course that is different).

First, it's unfair to style users that they must use the style dialog window to change some properties instead of using toolbar buttons for example.

Second, Benjamin will not come in touch with these commands as they have to be inserted by the users themselves (with the Customize dialog) or they're only part of the 'Formatting (Styles)' toolbar and not part of the default 'Formatting' toolbar.

Third, making property changes with with direct formatting commands and then updating the style is a perverse strategy for only-style users -- besides that, what if there are no direct formatting toolbar buttons available because they are deactivated to avoid direct formatting by the user?

(In reply to Heiko Tietze from comment #4)
> I expect a lot of confusion when Benjamin makes the style bold and unbolds
> after per direct formatting. Styles are not meant for this frequently and
> single-click modifications but a once in a time setup. And the dialog is
> perfectly suited for this.

These uno commands will not be used by Benjamin, then are for the style toolbar and for those wishing to customize their toolbar to add it to existing toolbars.

Summarizing the input from UX (primarily my own opinion): Styles are supposed to be static. Text body, for example, consists of a number of properties such as 12pt, normal weight, no indentation, 0.5 cm spacing etc. Those properties do neither change frequently nor alone. Having UNO commands mean to quickly access it on-the-fly, which is the opposite.
However, there is also support for the idea in the design team. It's close to the request to get rid of direct formatting and to apply a certain character style with making a section bold, or to modify the paragraph style for other properties. Saying that I'm aware that the request is about a styles toolbar with separate commands. But in the end I guess most users will not understand the duplication.

I generally support the idea.

The most important factor that makes direct formatting that popular is thet using it is *easy*. Thus, people who (unkowingly?) disregard the power of styles, argue that it doesn't worth the effort (and later, when they have created enough formatted content, they can't even evaluate what they miss now).

Reasoning like "styles are supposed to be static" concentrates on thoughtful approach to styles, that values organized way of working on documents. That is fine and all, but that is not the only approach in existence. And only making tools convenient for that workflow inevitably leaves out other workflows, forcing anyone with "chaotic" approach to use direct formatting, while everyone around would look at that and say "you do that wrong! you need to use styles!!!11".

So yes, *if* working with styles is *only* possible in that structured way, and providing another way of working with styles would impact organized users in a negative way, then yes, by no means provide easy styling tools to other workflows. But is that so? Maybe we just didn't try enough?

I could envision a switch which would turn all existing direct formatting commands into style modifying actions (by internally executing the new UNO commands), so that there were no duplicating commands in UI; with some easy-to-use tool to create new style (like possibility to edit the style name in style boxes, with a tiny plus button, so that one could not enter into style dialogs for that). At any rate, the idea offers possibilities IMO.