Skip to content
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

Closed
tomjn opened this issue Oct 11, 2018 · 37 comments · Fixed by #24304
Closed

Optional Inline Labels in Toolbar #10524

tomjn opened this issue Oct 11, 2018 · 37 comments · Fixed by #24304
Assignees
Labels
[Feature] UI Components Impacts or related to the UI component system [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@tomjn
Copy link
Contributor

tomjn commented Oct 11, 2018

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.:
screenshot 2018-10-11 at 17 24 05

Icons only:

screenshot 2018-10-11 at 17 23 23

Icons and text:

screenshot 2018-10-11 at 17 23 29

Text only:

screenshot 2018-10-11 at 17 23 37

I've mocked up what an icons and text mode may look like in Gutenberg:

screenshot 2018-10-11 at 17 19 59

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.

@Soean Soean added [Type] Enhancement A suggestion for improvement. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Feature] UI Components Impacts or related to the UI component system labels Oct 11, 2018
@mtias mtias added this to the Future: 5.1 Onwards milestone Oct 12, 2018
@mtias mtias added the Needs Design Feedback Needs general design feedback. label Oct 12, 2018
@Luciaisacomputer
Copy link
Contributor

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.

@afercia
Copy link
Contributor

afercia commented Feb 23, 2019

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:

@mapk
Copy link
Contributor

mapk commented Mar 8, 2019

Maybe we can add a checkbox in the Options modal which, when selected, turns on those icon labels? Something like this?

screen shot 2019-03-07 at 8 48 53 pm

@afercia
Copy link
Contributor

afercia commented Mar 8, 2019

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):

37083107-c3abb932-21ee-11e8-91b5-7acc08bceaf6

This would save some horizontal space, even though there needs to be some spacing between the icons.

@mikelittle
Copy link

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.
I also agree it should not be an 'accessibility' option it should be a standard configurable option like 'top toolbar'.

@mapk
Copy link
Contributor

mapk commented Mar 12, 2019

I wouldn't group the option under an "Accessibility" section: this would be a feature that can benefit everyone.

That makes sense. Thanks for sharing!

icon-labels

@mapk
Copy link
Contributor

mapk commented Mar 16, 2019

Here are some mockups regarding this discussion.

Top: The icon only state.
Middle: Icons + text (side by side)
Bottom: Icons + text (underneath)

Screen Shot 2019-03-15 at 5 33 11 PM

@mapk
Copy link
Contributor

mapk commented Apr 10, 2019

@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. 😉

@enriquesanchez
Copy link
Contributor

👋 Hey everyone!

My explorations were very similar to the ones already shared:
Screen Shot 2019-04-10 at 4 16 28 PM

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:

Screen Shot 2019-04-10 at 5 05 41 PM

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 🤔

@afercia
Copy link
Contributor

afercia commented Apr 10, 2019

concerns about the labels being too long

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.

@tomjn
Copy link
Contributor Author

tomjn commented Apr 11, 2019

It might be worth accounting for the eventual case where they do overflow. When firefox has more tabs than it can render, it adds arrow buttons and allows them to be scrolled. What happens at the moment if the buttons don't fit?

edit:

Screenshot 2019-04-11 at 10 31 11

@afercia
Copy link
Contributor

afercia commented Apr 11, 2019

For inspiration, here's the previous android UI example in different languages (it's from my smartphone Gallery screen):

English:
en

Spanish:
es

French:
fr

German:
de

Italian:
it

On one hand, it seems there are some length rules, for example:

  • Spanish: "deselec" seems to me a truncated word (anyone can confirm?)
  • Italian: "Deseleziona" omits "tutto" because it would be too long. On other screen with more room I've seen it's "Deseleziona tutto"
  • German: not sure about "Abwählen": any German speaker here?

On the other hand, there seem to be an inconsistency in French:

  • "Désélectionner tout" is very long and goes in two lines

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.

@tomjn
Copy link
Contributor Author

tomjn commented Apr 11, 2019

As an update, a quick way to add the labels in the browser is via this CSS:

.edit-post-header button::after {
    content: attr(aria-label);
    margin-left: 0.5em;
}

This results in the labels appearing to the right with a small amount of margin that can then be experimented with easily

@afercia
Copy link
Contributor

afercia commented Apr 11, 2019

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.)

@Luciaisacomputer
Copy link
Contributor

@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!

@afercia
Copy link
Contributor

afercia commented Apr 11, 2019

@LukePettway thanks! I'm just trying to explore and learn new things 🙂

@enriquesanchez
Copy link
Contributor

enriquesanchez commented Apr 11, 2019

Spanish: "deselec" seems to me a truncated word (anyone can confirm?)

@afercia I believe you're correct. I assume it should be "Deseleccionar todo".

Wondering if the Gutenberg UI should have a sort of "style guide" for translations

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").

@afercia
Copy link
Contributor

afercia commented Apr 11, 2019

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.

@mapk
Copy link
Contributor

mapk commented Apr 16, 2019

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

  • It looks pretty slick and keeps an evenly distributed space between each item's label and next icon.

CONS

  • Long words may not fit in the spacing provided.

Icon on top of label

PROS

  • The text can stack, or be hyphenated.

CONS

  • The toolbar becomes more visually prominent and takes more space.
  • Long words can still cause an issue with spacing.
  • The icons with longer labels begin to be spaced visually awkward in comparison with the other items.

Are there other solutions regarding longer text?

  1. Limit the strings for translations as @afercia noted above.
  2. Automatically detect the amount of space and if items are not fitting, start pushing them into a dropdown.
  3. Other ideas?

@mapk
Copy link
Contributor

mapk commented May 7, 2019

I think we can begin development on this and make any iterations in a PR.

  1. Add the option to toggle this setting as stated in this comment above.

  2. Stack the icons with labels below as in @enriquesanchez's mockups.

@mapk mapk added Needs Dev Ready for, and needs developer efforts and removed Needs Design Feedback Needs general design feedback. labels May 7, 2019
@enriquesanchez
Copy link
Contributor

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?

@karmatosed
Copy link
Member

karmatosed commented Jul 5, 2019

I know there is thought against adding as accessibility option but with #16354, I feel it maybe works?

@haszari
Copy link
Contributor

haszari commented Dec 5, 2019

Does this issue cover block toolbars also? These are visual-only at present.

Screen Shot 2019-12-05 at 3 19 16 PM

@mapk
Copy link
Contributor

mapk commented Dec 16, 2019

@haszari I think the individual block toolbars should be a separate PR that can pull from the learnings when this PR gets merged.

@mapk mapk added Needs Dev Ready for, and needs developer efforts and removed Needs Design Feedback Needs general design feedback. labels Dec 16, 2019
@tellthemachines
Copy link
Contributor

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.

@ZebulanStanphill
Copy link
Member

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.

@mapk
Copy link
Contributor

mapk commented Jul 29, 2020

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.

@tellthemachines it looks like @jasmussen explored that here: #15830 (comment)

I like that solution, myself. 👍

I edited the link as noted by @ZebulanStanphill below.

@ZebulanStanphill
Copy link
Member

@mapk I think the link in your comment is pointing to the wrong thing.

@jasmussen
Copy link
Contributor

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.

@afercia
Copy link
Contributor

afercia commented Aug 3, 2020

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:

Regardless of the small inconsistencies, it seems to me the various translations (note: on other apps) are crafted to respect a maximum length. Wondering if the Gutenberg UI should have a sort of "style guide" for translations.

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.

@tellthemachines
Copy link
Contributor

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.

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?

At the very least, a maximum length should be recommended in a translator comment or by other means.

I'll add some comments in. What would be a good maximum length here?

@mapk
Copy link
Contributor

mapk commented Aug 4, 2020

I am leaning more towards #15830 (comment) as the best approach.

@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.

@jasmussen
Copy link
Contributor

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!

@afercia
Copy link
Contributor

afercia commented Aug 6, 2020

What would be a good maximum length here?

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 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] UI Components Impacts or related to the UI component system [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.
Projects
None yet