This is definitely valid. Setting as NEW and enhancement.

Confirming issues as identified on Windows 7 sp1, 64-bit en-US with
Version: 4.5.0.0.alpha0+
Build ID: aeeff83595a176805d74ad4e35d946eb6a8e1b25
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2014-12-20_00:13:27
Locale: en_US

@Mike, we'll assume you were commenting on recent builds, and not 3.3.0--if that is not the case, please identify any specifics in the older builds.

Each of the issues raised is currently valid. 

With the mix of UI widgets available to various developers to implement buttons and menus in the GUI the function can end up different as you note. Yet maintaining consistency in the UI is important to the user experience so these and similar are valid issues. 

Unfortunately very subtle differences in the GUI may have considerable divergence in the underlying code. Especially legacy vs. newer UI based items. I think that is the case here. And correcting them could require considerable rework, no telling when it will be addressed.

For now adding to meta bug 81475, but we Design/UX team may need to start keeping track of them specifically.

Obviously we need a guideline. 

Adjusting the importance to medium/minor - user experience is not trivial.

(In reply to Mike Kaganski from comment #0)
> Pressing arrow next to "Font Color"/"Highlighting" toolbar button brings the
> drop-down panel that has a caption, that can be used for dragging. When
> dragged, it becomes a floating window. The drop-down (not draggged) stays on
> screen while the main application window is resized/moved.

Caption should be removed (tooltip and icon already tell you what will popup from the spit buttons) and dragging should be disabled as there is no means to dock it like the sidebar or toolbars, making its floating functionality very limited.

> Pressing arrow next to "Insert Table" button gives a drop-down with caption;
> it behaves like draggable, but on release it disappears. Trying to
> resize/move main app window hides drop-down (as expected).

Caption should be removed (tooltip and icon already tell you what will popup) and dragging should be disabled as it provides no useful functionality.

> Pressing arrow next to "Bullets On/Off" (or "Numbering On/Off") gives
> drop-down without header/double lines, not draggable, no borders. Items have
> flat appearance with thin black border on hover. Trying to resize/move main
> app window hides drop-down (as expected).

Didnt get what "without header/double lines" or "no borders" meant. Flat appearance is important as its showing a preview of how it looks on a flat page.

> Pressing arrow next to "Line Spacing" (recent versions) gives not draggable
> drop-down with some border. Items look like 3D buttons on hover. Trying to
> resize/move main app window hides drop-down (as expected).

3D buttons when hovering isnt good as these should be standard toggle buttons or checkboxes (bug 113633).

> Pressing arrow next to "Insert Field"/"Paste" gives not draggable drop-down
> with some border. Items look like menu items (standard OS menu look;
> system-defined highlight color, etc). Trying to resize/move main app window
> hides drop-down (as expected).

Acts the same as other split/group buttons that pull out menu items like new, open and save buttons.

(In reply to Mike Kaganski from comment #0)
> Pressing arrow next to "Bullets On/Off" (or "Numbering On/Off") gives
> drop-down without header/double lines, not draggable, no borders. Items have
> flat appearance with thin black border on hover.
That widget tries to emulate a menu to some extent, e.g. it has a menu background, and the "More" item at the bottom has a menu-like highlighting when hovered. But that emulation isn't good enough (e.g. no margins), and the "black border on hover" indeed doesn't fit that well. I guess we should fix the theming there to be more menu-like.

(In reply to Yousuf Philips (jay) from comment #5)
> (In reply to Mike Kaganski from comment #0)
> > Pressing arrow next to "Font Color"/"Highlighting" toolbar button brings the
> > drop-down panel that has a caption, that can be used for dragging. When
> > dragged, it becomes a floating window. The drop-down (not draggged) stays on
> > screen while the main application window is resized/moved.
> 
> Caption should be removed (tooltip and icon already tell you what will popup
> from the spit buttons) and dragging should be disabled as there is no means
> to dock it like the sidebar or toolbars, making its floating functionality
> very limited.
I disagree. The floating functionality might be limited, yet it proved to be useful for some users, e.g. Bug 32676, Bug 106762, Bug 114935. And obviously the functionality can be improved if we want. Also dragging the color picker was possible since forever in LO and OOo, and I'm against breaking it.

The title might be duplicating the icon/tooltip, but:

1. Icons are rarely a good indication (IMHO). Even for a good fitting icon, I doubt that one that never used the software before, will know for sure what the button does w/o looking at the tooltip, or actually trying to use the button. Icons can help you find the button you need, *after* you remember what that icon means.

2. The tooltip isn't visible by default, and it shows with a delay after hovering the button. It also won't show after the popup is already opened.

3. The text title is in fact the title bar of the popup window, and is what makes it possible to drag it. It isn't different from a title bar of a floating toolbar (e.g. have the same size and font), except that it have a different background color, to blend nicely with the toolbar button when connected. And that "title bar look" is what gives the users a clue that it can be in fact dragged away. It should be possible to change that to a graphic grip, like we have now for the shapes popup, but I doubt such a small dragging area will look good for a big popup like the color picker currently is.

4. At least for the undo/redo popups, the title area is used to display the count of actions to undo/redo. Having similar titles for other popups, even if less useful, just adds consistency to the UI, not otherwise.

> > Pressing arrow next to "Insert Table" button gives a drop-down with caption;
> > it behaves like draggable, but on release it disappears. Trying to
> > resize/move main app window hides drop-down (as expected).
> 
> Caption should be removed (tooltip and icon already tell you what will
> popup) and dragging should be disabled as it provides no useful
> functionality.
Yes, dragging should be disabled (as it won't be useful to have this popup floating, as it isn't an attribute like a color which might be useful to apply to other objects in turn), but the title should stay.

> > Pressing arrow next to "Line Spacing" (recent versions) gives not draggable
> > drop-down with some border. Items look like 3D buttons on hover. Trying to
> > resize/move main app window hides drop-down (as expected).
> 
> 3D buttons when hovering isnt good as these should be standard toggle
> buttons or checkboxes (bug 113633).
I'll add a comment there.

(In reply to Maxim Monastirsky from comment #6)
> I disagree. The floating functionality might be limited, yet it proved to be
> useful for some users, e.g. Bug 32676, Bug 106762, Bug 114935. And obviously
> the functionality can be improved if we want. Also dragging the color picker
> was possible since forever in LO and OOo, and I'm against breaking it.

Then i suggest changing the title label to draggable grip, to unify it with the shapes split button.

> 1. Icons are rarely a good indication (IMHO). Even for a good fitting icon,
> I doubt that one that never used the software before, will know for sure
> what the button does w/o looking at the tooltip, or actually trying to use
> the button. Icons can help you find the button you need, *after* you
> remember what that icon means.

For someone new to LO and doesnt know the buttons available in the toolbar or someone trying out an new icon theme, icons need to be gotten used to, but icons are the best indication of functionality.

> 2. The tooltip isn't visible by default, and it shows with a delay after
> hovering the button. It also won't show after the popup is already opened.

Tooltips fall in second for indication for users who arent familiar with the button layout and icons.

> 3. The text title is in fact the title bar of the popup window, and is what
> makes it possible to drag it. It isn't different from a title bar of a
> floating toolbar (e.g. have the same size and font), except that it have a
> different background color, to blend nicely with the toolbar button when
> connected. And that "title bar look" is what gives the users a clue that it
> can be in fact dragged away. It should be possible to change that to a
> graphic grip, like we have now for the shapes popup, but I doubt such a
> small dragging area will look good for a big popup like the color picker
> currently is.

Yes i finally get it that it is a title label bar now and still believe the draggable grip is the best option for the color pickers.

> 4. At least for the undo/redo popups, the title area is used to display the
> count of actions to undo/redo. Having similar titles for other popups, even
> if less useful, just adds consistency to the UI, not otherwise.

A changing title label like this might be the only exception that might be worth keeping a title label for, but really how useful is it to know the number of undo or redo steps that you are going to make. That changing label could easily be placed below the undo/redo listbox as that information is secondary to the listbox details. I'm assuming you are for disabling dragging here as well.

> Yes, dragging should be disabled (as it won't be useful to have this popup
> floating, as it isn't an attribute like a color which might be useful to
> apply to other objects in turn), but the title should stay.

In MS Word, the title label for inserting a table changes to show the table dimension, but we already have that displayed as a tooltip while dragging the mouse, so i'm still for removing it.

So for me this would be the guidelines:

1. Never have title label bar as icon and tooltip already cover this.

2. If it is to be dragged have draggable grip.

3. If the contextual/changing label is needed in the widget, have it below the primary control as users eyes will be looking downwards when using the primary control and not upwards where the current title label bar is.

(In reply to Yousuf Philips (jay) from comment #7)
> A changing title label like this might be the only exception that might be
> worth keeping a title label for, but really how useful is it to know the
> number of undo or redo steps that you are going to make. That changing label
> could easily be placed below the undo/redo listbox as that information is
> secondary to the listbox details.
Yes, that in fact how it was in OOo (and still in AOO). Just for a reference, here are kendy's commits which introduced those titles - https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=toolbar-decorations

> I'm assuming you are for disabling dragging here as well.
True.

> So for me this would be the guidelines:
> 
> 1. Never have title label bar as icon and tooltip already cover this.
> 
> 2. If it is to be dragged have draggable grip.
> 
> 3. If the contextual/changing label is needed in the widget, have it below
> the primary control as users eyes will be looking downwards when using the
> primary control and not upwards where the current title label bar is.
OK, I can agree with that. As long as the color pickers are draggable I'm happy.

Anticipating positive review, the guideline for floating widgets is here https://wiki.documentfoundation.org/Design/Selection#Appearance. I'd suggest to make this issue a meta ticket for those controls that don't behave as defined (and if it makes sense in the particular case).

Dear Mike Kaganski,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug