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.
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.
The label can perfectly be a tooltip; it‘s easy to add if you agree.
(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?
(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,
(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.
(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.
(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 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.
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.
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
(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
(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.
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.
(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
(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.
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.