Bug Hunting Session
Bug 114701 - [UI] Missing widget labels and tooltips in Customization dialog
Summary: [UI] Missing widget labels and tooltips in Customization dialog
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.0.0.1 rc
Hardware: All All
: medium normal
Assignee: Heiko Tietze
URL:
Whiteboard: target:6.1.0
Keywords:
Depends on:
Blocks: Customize-Dialog 112221 Tooltip
  Show dependency treegraph
 
Reported: 2017-12-26 17:20 UTC by Olivier Hallot
Modified: 2018-01-10 23:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2017-12-26 17:20:06 UTC
The revamped dialogues miss (IMHO) a label for the drop-down boxes on the right part of the dialogue.

"Location"  for [%PRODUCTNAME <module> ; <file>] drop-down

"Menu" for the drop-down containing all menus / context menus / Toolbars

I also demand to replace the "+" and "-" icons with textual "Add" and "Delete" buttons.
Comment 1 Heiko Tietze 2017-12-27 13:20:09 UTC
Pro: better identification, support for a11y; labels could be (from top to bottom) Scope, Target, Functions
Con: those labels clutter the UI, also when placed above the control

Opinions are welcome.
Comment 2 Adolfo Jayme 2018-01-01 02:51:55 UTC
The label can perfectly be a tooltip; it‘s easy to add if you agree.
Comment 3 Cor Nouws 2018-01-02 13:42:28 UTC
(In reply to Olivier Hallot from comment #0)

> I also demand to replace the "+" and "-" icons with textual "Add" and
> "Delete" buttons.

In my theme/Iconstyle, those are Arrows.


(In reply to Heiko Tietze from comment #1)
> Pro: better identification, support for a11y; labels could be (from top to
> bottom) Scope, Target, Functions
> Con: those labels clutter the UI, also when placed above the control

When skipping 'Functions', the other two could be placed let of the lists, without changing the overall view of the dialog too much.
And 'Functions' is clear anyway.

(In reply to Adolfo Jayme from comment #2)
> The label can perfectly be a tooltip; it‘s easy to add if you agree.

is that fine for a11y too?
Comment 4 Cor Nouws 2018-01-02 13:44:25 UTC
(In reply to Cor Nouws from comment #3)
 
> When skipping 'Functions', the other two could be placed let of the lists,

the 'f' slipped away: ... could be placed left of the lists,
Comment 5 Yousuf Philips (jay) (retired) 2018-01-03 15:54:30 UTC
(In reply to Olivier Hallot from comment #0)
> I also demand to replace the "+" and "-" icons with textual "Add" and
> "Delete" buttons.

I wouldnt be infavour of this.

(In reply to Adolfo Jayme from comment #2)
> The label can perfectly be a tooltip; it‘s easy to add if you agree.

Yep this is the way to go.

(In reply to Cor Nouws from comment #3)
> When skipping 'Functions', the other two could be placed let of the lists,
> without changing the overall view of the dialog too much.

The dialog is quite large already (874x674) and adding the labels on the left would add additional width to the dialog, which can be even larger in localized versions.

> is that fine for a11y too?

Yes.
Comment 6 Cor Nouws 2018-01-03 17:00:51 UTC
(In reply to Yousuf Philips (jay) from comment #5)

> The dialog is quite large already (874x674) and adding the labels on the
> left would add additional width to the dialog, which can be even larger in
> localized versions.

Then shrink the width of the lists a bit. At least in Dutch and English, commands/descriptions that are over half the width of the lists, are rare.
Comment 7 Heiko Tietze 2018-01-03 17:41:17 UTC
(In reply to Cor Nouws from comment #6)
> Then shrink the width of the lists a bit.

The list box width is defined by its content. Don't know, however, why we don't define a fix size and use ellipsis or horizontal scrollbar. Muhammet, any good reason?
Comment 8 Olivier Hallot 2018-01-03 20:36:57 UTC
(In reply to Heiko Tietze from comment #7)
> (In reply to Cor Nouws from comment #6)
> > Then shrink the width of the lists a bit.
> 
> The list box width is defined by its content. Don't know, however, why we
> don't define a fix size and use ellipsis or horizontal scrollbar. Muhammet,
> any good reason?

In the past we had tons of ellipsis in the UI. See my rationale against them in
bug#86871. I stand for eliminating them as they are a source of stress/confusion to most users, especially new LO users.
Comment 9 Heiko Tietze 2018-01-03 20:54:01 UTC
We discussed the topic in the design meeting and suggest to place labels left aligned _above_ all controls using Search, Category, Function, and Description on the left side (as today) amd Scope, Target, Function, Customize right hand.

The additional suggestion to have text on +/- won't work. We better provide tooltips on the controls including the add/delete buttons that remain icon only.
Comment 10 Heiko Tietze 2018-01-04 12:16:57 UTC
Patch submitted with https://gerrit.libreoffice.org/#/c/47391/, still a few issues.

Tooltips for discussion:

Search field: "Filter the functions list below"
Category dropdown: "Show all or a subset of commands, or macros or styles"
Description: "Description of the selected function;\n only available when the local help is installed."
Scope: "Select where the modifications should be stored"
Target: "Select where the functions should be added"
Move up/down: "Move up" / "-down"
Add/remove: as before
Comment 11 Yousuf Philips (jay) (retired) 2018-01-05 17:13:33 UTC
(In reply to Heiko Tietze from comment #10)
> Search field: "Filter the functions list below"
> Category dropdown: "Show all or a subset of commands, or macros or styles"
> Description: "Description of the selected function;\n only available when
> the local help is installed."
> Scope: "Select where the modifications should be stored"
> Target: "Select where the functions should be added"

As we are adding labels for the controls, we arent adding tooltips. It was tooltips (regular ones and to be confused with extended ones that come from help) or labels and not both.

> Move up/down: "Move up" / "-down"

+1
Comment 12 Heiko Tietze 2018-01-06 09:43:12 UTC
(In reply to Yousuf Philips (jay) from comment #11)
> As we are adding labels for the controls, we arent adding tooltips.

We agreed on using tooltips not only in this discussion but also before in respect to another dialog. Tooltips are in general very useful to learn how things work and support accessibility.

Found the old discussion, it was about area fill style in bug 104413 set as WONTFIX because of the extended tooltips when the offline help is installed (suggested simple tooltips https://docs.google.com/document/d/18u_DcmjyIPS1HzxhLEMu_1teFL-1uGGs_Xjfpg1l4d4). Cannot recall who was in the meeting but reading over the ticket there is no one else than you against tooltips.
Comment 13 Heiko Tietze 2018-01-06 22:08:48 UTC
Review on Gerrit asking to remove the text in the search field "Type to search". Not sure why this well-working placeholder should get removed and would keep it.
Comment 14 Yousuf Philips (jay) (retired) 2018-01-06 22:15:38 UTC
(In reply to Heiko Tietze from comment #12)
> We agreed on using tooltips not only in this discussion but also before in
> respect to another dialog.

The agreement on using tooltips in this discussion was as we werent going to them rather than labels (comment 2), but when we discussed labels and tooltips in the design meeting, it was one or the other, excluding the buttons which dont have labels.

> Tooltips are in general very useful to learn how
> things work and support accessibility.

Tooltips are beneficial when there are no labels or when the labels arent clear (labels should be changed if they arent clear) or are lacking important information that isnt obvious with basic usage (e.g. no description text when help isnt installed). If users wish learn about controls and how they work, they have the option to install help and have extended tooltips appear. Regarding accessibility, we have means of supporting it even without tooltips. Addition of regular tooltips also adds additional translation work.

> Found the old discussion, it was about area fill style in bug 104413 set as
> WONTFIX because of the extended tooltips when the offline help is installed
> (suggested simple tooltips
> https://docs.google.com/document/d/18u_DcmjyIPS1HzxhLEMu_1teFL-
> 1uGGs_Xjfpg1l4d4).

Regarding bug 104413, the major issue was that we didnt have good labels, especially from an a11y perspective, which then made tooltips important to have if we didnt want to improve the labels, but the correct thing was to improve on the labels, which I did. https://gerrit.libreoffice.org/#/c/44897/

> Cannot recall who was in the meeting but reading over the
> ticket there is no one else than you against tooltips.

If you are talking about the design meeting[1], then you, kendy and I gave input on the issue, while the discussion also happened in the ESC which sophie pasted the excerpt from in the l10n ML[2]. At the bottom of sophie's message, she states, 'The proposal is not to put them everywhere, but when it helps the 
understanding. My opinion (but it's mine :) is that they are very helpful for users and should be added when UX see them needed (and I trust them on that) even if it gives us some work on translation and grow the files.'

I can't speak for everyone, but i'm fully against useless tooltips, like explaining what happens when you type in the field, which has the label 'Search' above it. During the design meeting last wednesday, we discussed having one or the other and if in the end we would have to have tooltips, then we should have gone with the design eliminating all the labels. The end result of the discussion was to 'place text above controls using search, category, function, description on the left and scope, target, function, customize right'. Looking at the emailed notes[3], i see that 'tooltips are the better way to explain the function' was also left in the minutes, which is incorrect as that was the earlier decision we made before we decided to go with moving the labels above the controls.

[1] http://nabble.documentfoundation.org/Minutes-of-the-Design-Hangout-2016-Dec-22-tt4203377.html

[2] http://nabble.documentfoundation.org/libreoffice-l10n-Feedback-on-tooltips-tt4202816.html

[3] http://nabble.documentfoundation.org/Minutes-from-the-design-meeting-2018-Jan-03-td4230149.html
Comment 15 Yousuf Philips (jay) (retired) 2018-01-06 22:29:56 UTC
(In reply to Heiko Tietze from comment #13)
> Review on Gerrit asking to remove the text in the search field "Type to
> search". Not sure why this well-working placeholder should get removed and
> would keep it.

Inline search label is important when there is no corresponding label associated with the textbox, like in the templates dialog or the find toolbar, both for regular users and a11y, but when the control has a label associated with it, it isnt needed, like in the special character or firefox theme dialogs.
Comment 16 Commit Notification 2018-01-10 23:45:04 UTC
heiko tietze committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=92262c813f19f7df90a75d0b5758ceec9c89741e

tdf#114701 Missing widget labels in Customization dialog

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.