When introducing friends to Libreoffice I've found that some have problems with the text/background coloring UI. When they select a color and click it, they expect it to work much like other character styles: to take place immediately and affect all newly-input text. Like how bold, underline, etc work. But instead the coloring paradigm is completely different as it's an after-the-fact fix tool instead of a current-style tool. Also note that this is NOT the same way that Word 2010 works. Word 2010's character coloring tool works as expected, where it just affects highlighted text or newly-input text. Only Word's Highlighting tool requires you to select text after a color is chosen to modify its background. Now, I'm not certain how long the UI for coloring has existed, and it may not make sense to modify these UI elements. But I think it would be worth adding current-style coloring options to complement the existing tools. I'm still not sure it's even possible to do this currently in LO, which is unfortunate. If it is, it's unclear to me.
Alright, looks like this is more subtle than I originally thought. Selecting a color from the dropdown applies the coloring to the current style, while hitting the button does not. This leads to the confusion in the following scenario: 1) Create some standard black text 2) Select a color from the dropdown and make some more text in that color 3) Move back into the previous black text 4) Click the Font Color toolbutton to enable this color for typing in the middle of the black text. 5) Be surprised that the mouse cursor is a hightlighting icon and the text is still black. So the way the current UI is designed is that it doesn't allow for quickly applying the current style to previously-styled text. Note that this behavior is also not aligned with Word 2010's functionality, where the font color never has highlighting behavior, it always only affects the current style. Clicking the button once a color is selected there applies it immediately. This is also the behavior me, and my friends, expected when clicking that button.
@Bryant, This is simple, we don't care what MS Word does! Sorry, but you're missing the picture here--what you are describing is direct formatting of selected text while you are working, probably in "default" sytle mode. Rather, since LibreOffice Styles are modal and are selected from the Styles and Formatting content panel of the Sidebar we should enter text and deal with styles in blocks. Most often that will be by selecting a preexisting Paragraph style (or modifying it to create a new paragraph style)--but there are panels for applying styles to characters, frames, pages, numbering & bullets. So, as in your example, we create the text in "default" style, select it and chose the style we'd like it to have. Or, we can still apply divergent direct formatting to the selection if that is preferred (simplicity, laziness) using any of the buttons on the formatting toolbar. But beyond changing the selection, you have not at that point changed the "default" style, entering additional paragraphs will again be "default"--as modified by any buttons left active. It is easy to see the effects of correctly applied styles versus what has been directly formatted. Simply select all text (Edit -> Select All) and then remove direct formatting (Format -> Clear Direct Formatting)--what is left (likely all now "default" formatted) is what was correctly Styled. Working with styles in LibreOffice really is very efficient and lends itself to creating consistent documents. It is just not done the way MS Office/Word does it.
From what I'm reading from your comment is that a) consistency with Word isn't important (fair enough) and b) we should be using styles instead (which I take issue with). The reason I don't use styles is because I've inherited documents from my adviser that don't use styles and for quick edits I don't feel like making a bunch of styles and then making sure they're applied everywhere. This is just my argument for the workflow I proposed in #1 to be a valid and supported workflow by Writer. But moving on to my, hopefully more compelling, UI consistency argument. It seems to me that the Font Color split-button works contrary to all other uses of it that I've encountered. Usually with split-buttons they have an alternate set of options that modify the primary functionality in some way, though this normally doesn't affect how the tool is used/applied. For example I've seen paste split-buttons where there's a normal smart paste and then the advanced options change the pasted item beforehand. And even in Writer there's the highlighting tool where the advanced functionality sets a color first and then enables the regular button functionality. And with colored-split-buttons in particular, normally the advanced options ONLY affect the color setting for the primary button. So the primary button is basically a short-cut for the advanced button when the color setting doesn't need to be changed. So it's quite unexpected when the Font Color split-button a) has different functionality than what I would consider expected split-button behavior, especially for colored-split-buttons, and b) differs from the behavior of the highlight split-button. I don't know the proper approach for continuing a bug discussion after it's marked invalid, but I'll leave it as set for now.
@Bryant, Easy, to continue to discuss. Setting it back to NEW, but bouncing to my colleagues on ux-advise. I've adjusted the summary "Color picker actions of toolbar buttons font color and background color seem unintuitive" But if you would, please clean up your discussion regards Font Color split-button being inconsistent. Lay out the argument point by point--attach a panel'd mock-up of how you think it should behave... Stuart
So just my two cents - I tend to agree with VSF here. Yes we're different, but so be it. Different tools have these kinds of differences and users can get used to it (or not). That being said, of course this is left for UX to decide but I'm not a fan of changing the behavior at all. I like it how it is (I use it all the time) and would find it counter-intuitive to change the behavior (even if MSO does it another way) Again just my two cents
I guess i'd have to agree with Bryant here as i would expect the same behaviour when i click on the main button as when i click the drop down to select another color. The font color button isnt a highlight type function, so why should it act like that if i click the main button, but act differently when i select a color from the drop down. So if i start typing some text and then select the drop down to change the font color blue, then go back to another section which has a different font color and want start typing in blue there, i cant click on the main button, i have to open the drop down and select blue again. @Heiko: What are your thoughts?
* Direct click: Modify the current selection or start highlighting * Split click: Change the style for next input * Move position: Use actual style (However, the controls do not convey any cue to what happens. Especially when you switch the position it's not changed accordingly. I'd tread this as bug although I guess it is implemented on purpose just to have another option like highlight.) * Style: Applies the color to all text except the individually formatted Yes, it is over-complicated. But we do not need to copycat alternative programs. I'd rather think about making it clear to the user what is happening and to standardize the workflow. For instance, the awesome highlighting feature of clone formatting outperforms most competitors. Why don't start color "cloning" as well on double click? And having a clear feedback in the buttons in respect to the current selection should support users understanding too. On the other hand we need to design and develop for the user. So if she doesn't like the way LO works we need to adopt other workflows. It makes sense to confirm any suggestion by Bryant, or rather his friends.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
*** Bug 105334 has been marked as a duplicate of this bug. ***
*** Bug 105293 has been marked as a duplicate of this bug. ***
The font color selector in Writer doesn't behave the same way as in Calc or Impress (or Word, Google Docs, Wordpad for that matter). I'm not able to click the font color icon, so I can type in that color next. Instead I get a mouse pointer with a bucked, to change already typed text.
Writer has two kind of icons. One of them gives the bucket and the other doesn't. The bucket version is shown as default. Please look in the customize dialog. The bucket version has the command .uno:FontColor; the one without bucket has the command .uno:Color.
It's quite confusing to read through an old ticket (btw, LibO behavior of font/highlight color is the same as with MS Word) with new issues (differences between Writer and Calc; wherever it should be). So the best is to close this ticket- and to create new in case it's needed.