-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional Inline Labels in Toolbar #10524
Comments
This makes sense to me. I'd even prefer to have it as the default with a "minimal UI" as the second option to remove the labels. |
Some background: "icon-only" controls (buttons with no visible text label) are problematic for many reasons. They're an accessibility anti-pattern as pointed out in the first Gutenberg accessibility report from the accessibility team. They're also a big problem for speech input users, as well explained in #470 (comment) A few previous related comments: |
I'd love to see this explored. There are a few challenges, for example we can't predict the length of the labels when translated. Also, I'm not sure how to address other icon-only controls, for example in the block toolbar. I wouldn't group the option under an "Accessibility" section: this would be a feature that can benefit everyone. I'd consider to explore how the text label would look when placed below the icons. The text doesn't necessarily needs to be "big". It can be a bit smaller, as long as it's readable. For inspiration (Android): This would save some horizontal space, even though there needs to be some spacing between the icons. |
I have some kind of 'icon blindness' and struggle to distinguish one icon from another. So having a text option would be a really big help. In most apps, I turn it on whenever I can, though at least on the desktop, many already have them turned on. |
@enriquesanchez I heard you might have some thoughts (and possible mockups) around this. Would you mind sharing? I know my mockups can use a lot of help. 😉 |
👋 Hey everyone! My explorations were very similar to the ones already shared: While I think that having the label below the icon would scale better and should prove to be easier to work with on smaller viewports, I also share @afercia 's concerns about the labels being too long when translated to different languages. To give an idea of how much more space some labels will need, here's a side by side comparison of the toolbar in english and spanish: I assume we might be able to work around this issue by tweaking some media queries, but I'm not sure if this is something that can be done based on what language the UI is set to 🤔 |
Yep. Just noting that on some smartphone UIs, where the pattern with labels below the icons is not unusual, there are clearly strict rules about the length of the labels. Of course, that's possible because the mobile UIs are a very controlled environment but maybe worth exploring some rules to keep the Gutenberg labels as short as possible. |
For inspiration, here's the previous android UI example in different languages (it's from my smartphone Gallery screen): On one hand, it seems there are some length rules, for example:
On the other hand, there seem to be an inconsistency in French:
Regardless of the small inconsistencies, it seems to me the various translations are crafted to respect a maximum length. Wondering if the Gutenberg UI should have a sort of "style guide" for translations. |
As an update, a quick way to add the labels in the browser is via this CSS:
This results in the labels appearing to the right with a small amount of margin that can then be experimented with easily |
Note: do not use the above CSS in production 🙂as it does impact accessibility (just to prevent people reading this issue from copying / pasting and use it on live sites! Excellent for testing purposes.) |
@afercia thanks for the example, I don't have much internationalization experience so this gives me some new information that I hadn't encountered before! |
@LukePettway thanks! I'm just trying to explore and learn new things 🙂 |
@afercia I believe you're correct. I assume it should be "Deseleccionar todo".
I think this is an interesting idea. One option could be to allow the use of differnet words that may not be a direct translation from english but that have the same or similiar meaning. A quick example: I think we can use "Indice" (spanish for "Index") instead of "Estructura del Contenido" (spanish for Content Structure"). |
Thanks @enriquesanchez ! Yep, I think the most important thing for translation guidelines in these cases would be to clearly indicate to translators a strict length limit for some strings. |
This was talked about in today's Design triage on slack. When thinking through translations this gets really complex. Side-by-side icon & label PROS
CONS
Icon on top of label PROS
CONS
Are there other solutions regarding longer text?
|
I think we can begin development on this and make any iterations in a PR.
|
Hey @nicolad! Sorry for the late response, I was out on vacation and I'm slowly catching up. To clarify, this means every single button that currently has no label will have one? Including those on the block toolbar? |
I know there is thought against adding as accessibility option but with #16354, I feel it maybe works? |
@haszari I think the individual block toolbars should be a separate PR that can pull from the learnings when this PR gets merged. |
Would it be worth exploring replacing the icons with labels, instead of just adding labels to the existing icons? Seems like this could help with some of the issues around space on smaller screens. |
I've seen some apps have all 3 choices: text only, text + icon, and icon only. Perhaps we should do the same? I do think that running out of space for toolbar options is inevitable no matter what we do. We have to figure out how to handle that situation when it happens. I'd say just move stuff into the ellipsis menu as necessary, with the stuff on the right being moved into it first. If that causes important actions to get folded into the menu too early, then maybe those actions shouldn't be there in the first place. I know there have been some accessibility concerns about placing the save/publish actions in the top bar in the first place. Perhaps this is a good time to rethink how we organize controls. Why do we have a left half and a right half of the top bar? Why does the Top Toolbar option stick the block toolbar in the middle of the top toolbar? For ideal accessibility, controls should be laid out in a logical order that makes sense. I think a lot of the problems we're running into are a result of the top toolbar being weirdly laid out. |
@tellthemachines it looks like @jasmussen explored that here: #15830 (comment) I like that solution, myself. 👍 I edited the link as noted by @ZebulanStanphill below. |
@mapk I think the link in your comment is pointing to the wrong thing. |
For what it's worth, I mostly explored the text only solution to leave no stone unturned. I am leaning more towards #15830 (comment) as the best approach. And I believe the most important step towards that (but a step that would benefit regardless of the approach), is to rephrase some of the very long labels into something smaller. "More tools & options" comes to mind as something that could be reduced. |
I'd agree. Although there's the need to differentiate the various "More" buttons. Also, when it comes to translations, worth reminding a previous comment:
At the very least, a maximum length should be recommended in a translator comment or by other means. I'd tend to think a real "style guide" for translators, with screenshots of the UI and detailed recommendations, would be even better. |
I'm currently exploring a text-only solution for the top toolbar in #24304 , and it works well in that area, but I'm not fully convinced it'll work as well in the block toolbar, especially with the text formatting tools. Perhaps I'll give it a try with the icons. Would it be useful to have both as an option?
I'll add some comments in. What would be a good maximum length here? |
@jasmussen, I've prepared some iterations and can use some feedback: #24304 (comment) My Figma file has many smaller iterations on various parts of the topbar if you wanted to see those. |
I don't want to block anyone from moving forward, to be clear! Any first baseline seems a good place to start, and there's no reason we can't iterate from there. Blaze a trail! |
I think this is mostly a design decision on whether to allow the buttons to take more space )increase the width) when necessary or not. I'd suggest to switch the user language and check "live" with the PR you're working on how the toolbar would look with such languages. Amongst the European languages, the ones that typically have longer strings are German, French, and also Spanish and Italian. That could give a better idea of the problem that needs to be solved 🙂 |
Is your feature request related to a problem? Please describe.
Icon only toolbars are fine for some people, and some have a preference for it ( e.g. myself ).
However, some people are unable to effectively use icon only toolbars, perhaps it's their preference, but for some people it has an a11y aspect. This could be similar to face blindness or forms of dyslexia.
For those people tooltips are not enough, and the friction of hovering over each button and waiting for the tooltip to display is immense.
Research indicates that a combination of icons and texts yields the widest and greatest recognition speed possible, at the cost of space
Describe the solution you'd like
MacOS solves this problem by providing options when customising toolbars, e.g.:
Icons only:
Icons and text:
Text only:
I've mocked up what an icons and text mode may look like in Gutenberg:
To me this looks like a clear improvement for some, and makes for much larger target areas on larger devices. I believe the icons only should remain as the default option however
I'm unsure how it would look placed underneath as MacOS does. I'm also unsure how well a text only option would fair, but it would look a lot prettier than MacOS given the current Gutenberg UI styling.
The text was updated successfully, but these errors were encountered: