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

Added show icon labels option #15830

Open
wants to merge 13 commits into
base: master
from

Conversation

@nicolad
Copy link
Member

commented May 25, 2019

Description

Fixes: #10524
Mockups:
image

How has this been tested?

Screenshots

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
@nicolad nicolad requested review from talldan and youknowriad as code owners May 25, 2019
@nicolad nicolad self-assigned this May 25, 2019
nicolad added 2 commits May 25, 2019
nicolad added 3 commits Jun 16, 2019
@nicolad nicolad changed the title [WIP] - Added show icon labels option Added show icon labels option Jun 17, 2019
@nicolad

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

@mapk, this is ready for design review:

Peek 2019-06-17 09-57

@nicolad

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

Please note that text from labels is reused from aria-label, so there is no custom text added there.

@nicolad nicolad requested a review from WordPress/gutenberg-core Jun 17, 2019
@jasmussen

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

Thank you for working on this. How does this scale to mobile? Are the labels optional or always there?

@nicolad

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

Thank you for working on this. How does this scale to mobile? Are the labels optional or always there?

Good question, on mobile it doesn't scale well:
image

This needs further refinements since it does make sense to have labels on desktop, but not on mobile, because there isn't enough space for them. But in this case the option to show labels would lead to some confusions since it will be enabled, but user will not see labels on mobile.

@mapk any thoughts on how to deal with this issue on mobile from UX perspective?

@nicolad

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

@jasmussen, I see that you also have design/UX super-powers :)
you might have a UX solution here

@swissspidy

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

Curious: there was a bit of a lack of progress on #10524. What makes it suddenly a high priority? Not that I necessarily disagree, just want to understand it better 🙂

@jasmussen

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

I see that you also have design/UX super-powers :)

You are too kind.

There are a few options on our table, which include rephrasing the labels to be shorter, and using the smallest font size that's still legible.

But in addition to this having to work on mobile and with all translations, in the top right hand area there is the spot where plugins can add additional buttons, and the labels here could be arbitrarily long as a plugin can type in any label they want.

In order to solve this problem in a way that acknowledges this extensibility, it's hard to think of a way forward that doesn't involve hiding the labels until the desktop breakpoint, and even then perhaps hides them for extensions, sidebar button, and ellipsis menu.

Creative thinking can help here. For example, is there any inspiration we can take from #13688?

@nicolad

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

Curious: there was a bit of a lack of progress on #10524. What makes it suddenly a high priority? Not that I necessarily disagree, just want to understand it better

@swissspidy initially I wanted to start working on this issue, but thanks to this comment I needed first do this issue in order to start the other one. From what I understand a11y audit is a high priority project for the GB at the moment, this is why I placed that label. Correct me if I am wrong.

display: block;
&::after {
display: block;
content: attr(aria-label);

This comment has been minimized.

Copy link
@mtias

mtias Jun 17, 2019

Contributor

This is an interesting approach. I like it keeps the components relatively clean.

This comment has been minimized.

Copy link
@swissspidy

swissspidy Jun 17, 2019

Member

I'd like to get some A11y feedback on this, as support for content in CSS differs a bit among assistive technologies. We don't wanna end up with a screen reader reading the label out loud twice.

This comment has been minimized.

Copy link
@mtias

mtias Jun 17, 2019

Contributor

Indeed.

This comment has been minimized.

Copy link
@nicolad

nicolad Jun 22, 2019

Author Member

I found that @afercia already had an opinion on this: #10524 (comment)
Will change the approach to meet a11y requirements.

This comment has been minimized.

Copy link
@afercia

afercia Jun 26, 2019

Contributor

@swissspidy thanks Pascal for raising this concern. You're right that some screen readers read out CSS generated content but in this case the whole content of the buttons is overridden by the aria-label so that only the aria-label is announced. To be 100% sure, I tested it also with NVDA and JAWS on Windows Firefox / Chrome.

This comment has been minimized.

Copy link
@gziolo

gziolo Jun 27, 2019

Member

Wouldn't it be easier to inline this label inside HTML when showIconLabels prop is set to true? it also feels like injecting showIconLabels prop should be part of the IconButton component which is the one which actually renders those icons.

@mtias mtias removed the [Priority] High label Jun 17, 2019
@swissspidy

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

Very interested in in-app translating and all things I18N. Can we set up a discussion on Slack about this? Should absolutely also include polyglots and @ocean90.

@davewhitley

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

I suggest we look at Material as a starting point for details on spacing, text size, max character count, etc. Their bottom navigation pattern is similar to this.

Some initial guidelines, taken from Material:

  • ~12 character label limit (@jasmussen I couldn't find anything definitive in Material about this.)
  • Avoid wrapping text
  • Don't truncate text
  • Use short labels
  • 12px font size

Screen Shot 2019-06-26 at 2 14 21 PM

@afercia

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

There's good and bad in every design system, and in this specific case what Material recommends is not necessarily bad. However, I'd like to invite everyone to refrain from referring to Material, at least when discussing features specifically designed for accessibility 🙂 The general opinion amongst accessibility specialists is that Material doesn't shine when it comes to accessibility.

@gziolo

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

  • I thought the tooltips were meant to not be displayed when the icon labels are visible: maybe this can be considered in a next iteration? Thoughts?

Yes, I also assumed that they are mutually exclusive with labels. Although now that I'm reading that there is a discussion about having much shorter labels, maybe we should rethink the approach and find out a good balance where they are two different cases:

  • no visual labels – we use the tooltip to show the label in tooltip (it might be a combination of short label and the detailed description)
  • visual labels – we show short labels next to the icon and use the tooltip only when there is something to clarify with the detailed description. I think More tools & options is a good example which could have More text displayed next to the icon and tools & options inside the tooltip.
@mtias

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

@gziolo I'm slightly worried about consistency and expectations for those cases if we allow them to be mixed:

  • Harder to enforce guidelines for 3rd parties — should I always be trying to expand on the meaning of the label with a tooltip?
  • Very long tooltips are also not a great experience.
  • Tooltips don't work on mobile, so if a button with a label at the bottom is not clear enough a tooltip cannot help much.
@afercia

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

Open to explorations but there's an important thing to consider:

the visible label and the accessible name of the control must match.

Actually, the tooltips use the same text used for the aria-label (which gives controls their accessible name). This is extremely important for voice recognition users who need to be able to voice a command to activate a control. For example, a voice command could be:

"Click Block Navigation"

  • the aria-label needs to be "Block Navigation" otherwise the software wouldn't understand which control to activate
  • the visible label needs to match the aria-label and be "Block Navigation", otherwise users may voice a command that doesn't match the actual name of the control
@ewaccess

This comment has been minimized.

Copy link

commented Jun 30, 2019

This might be the single biggest improvement to my WordPress experience. Thank you all for your effort on this!

This is the change that will get me to switch from the Classic editor in my own sites. I look forward to using this!

@mapk

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

In an effort to help move this forward and consolidate the feedback, here goes nothing...

  1. We need to shorten the labels as necessary. How about:
    Add block, Undo, Redo, Structure, Block navigation, Options
    I know "Options" isn't perfect, but it's better than the 4 words right now.

  2. Let's make sure the labels are in Sentence-case in accordance with this other effort.

  3. I'm not a fan of having the "Icon Labels" as its own setting. Can we move it to the "General Settings" instead? It seems to relate to "Tips" as it's showing text to help the user. Maybe since the other two options say "Enable", this particular one can say, "Show Icon Labels"

Icon Labels

  1. Let's hide the labels on any screen smaller than the Desktop breakpoint as noted in this earlier comment.
@afercia

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

I'd definitely second @mapk on shortening the labels.

Note: The original intent for the More tools & options was to make it descriptive and also different from the block ellipsis button "Options". Definitely in favor of making it shorter but these two ellipsis buttons should still have a different label that clarifies what they relate to.

I'm not a fan of having the "Icon Labels" as its own setting. Can we move it to the "General Settings" instead?

I'd definitely second this as well. Not sure it makes sense to have a group for just one item. Maybe in the future there will be more "preferences" settings and in that case a group may make sense.

Lastly: any exploration to try a slightly smaller font-size? It's a bit weird for an accessibility person to suggest this 🙂but maybe 1 pixel less doesn't make much difference in terms of readability, while it would help to save some space.

Screenshot 2019-08-07 at 10 51 24

Super thanks to @nicolad for your patience and perseverance 🙂

@mtias

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

Lastly: any exploration to try a slightly smaller font-size?

Let's try it. Looking forward to having this in :)

@mtias

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

For "(i) Structure" reads a bit weird to me. What about "Outline"? I think it captures the purpose of that group, including the count stats. Otherwise maybe "Content" could work?

@kjellr

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

For "(i) Structure" reads a bit weird to me. What about "Outline"? I think it captures the purpose of that group, including the count stats. Otherwise maybe "Content" could work?

I wonder if "Overview" makes sense? Or "Summary"? I know those don't match the language used in the label, but they do seem to fit what's in there:

Screen Shot 2019-08-08 at 8 59 16 AM

@davewhitley

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

@afercia What font size is it now? I don't think we should go below 12px. I remember 12px has been discussed as possibly being the minimum font size in general. I realize there are always exceptions to the rule though.

@kjellr

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

What font size is it now? I don't think we should go below 12px.

It looks like it's 13px right now. I think Gutenberg only uses 12px in one place (which seems odd), so the next step down may be 11px as used in the block breadcrumbs and is-small buttons.

@davewhitley

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

Thanks Kjell, I know we don't have a proper type system yet, but I hope we can have one soon. When we do, I suggest that 12px be the minimum font size, since it's the most common one I've seen in other design systems, like Deque. A common type scale from 12px would be 12, 14, 16, 20, 24, etc.

@afercia

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

Yup, as Kjell said the current font-size is 13 pixels. Assuming new, shorter, labels:

13 pixels

12 pixels would look like:

12 pixels

Just saying... this is the new Woo admin (official "WooCommerce Admin" plugin):

jetpack new admin

where:

  • seems to me the bigger spacing between icons makes a positive difference and maybe that's something that could be explored for Gutenberg too
  • the font-size there is 11 pixels, maybe a bit too small for Gutenberg
@kjellr

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

I suggest that 12px be the minimum font size, since it's the most common one I've seen in other design systems, like Deque. A common type scale from 12px would be 12, 14, 16, 20, 24, etc.

Definitely. We discussed that a bit in #15683 (comment), and that sounds excellent to me.

@mapk

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

Alright @nicolad, Looks like we can try 12px as the font-size for these icons as well. Do you think you'll be able to update this PR with the 12px font size, and the requested changes, here? #15830 (comment)

@nicolad

This comment has been minimized.

Copy link
Member Author

commented Aug 17, 2019

Alright @nicolad, Looks like we can try 12px as the font-size for these icons as well. Do you think you'll be able to update this PR with the 12px font size, and the requested changes, here? #15830 (comment)

Hey @mapk, sure, will do these changes during the next week.

@nicolad nicolad force-pushed the enhancement/show-icon-labels branch from 8dd985b to ba66ea0 Aug 24, 2019
@nicolad

This comment has been minimized.

Copy link
Member Author

commented Aug 24, 2019

@mapk updated font size:
image
next, need to inline label inside HTML as @gziolo's has suggested: #15830 (comment)

@mapk

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2019

@nicolad, this is coming together really nicely! Thanks for sticking with it.

Is there anything we can do about this one? I'd love to truncate it to just say "Options" because the label is so big.

Screen Shot 2019-09-04 at 4 40 35 PM

I also noticed that when "Top Toolbar" mode is selected, all sorts of craziness starts to happen.

Screen Shot 2019-09-04 at 4 42 23 PM

You can see these toolbar options also get the labels appended and start aligning very awkwardly. Here's another example of the Paragraph block.

Screen Shot 2019-09-04 at 4 44 23 PM

Also, not for this PR, but it becomes embarrassingly obvious that when using the "Top Toolbar" mode, we have two "More options" buttons there.

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

I think the block toolbar should be shown on a separate line when the "Top Toolbar" option is enabled. It's confusing to mix the main editor toolbar with the block toolbar. It would also give more space for labels to be shown.

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2019

What if the text was put to the right of the icon, but used 2 lines? Would that look better and/or save space?
button-with-label-2-lines

Alternatively, 2 lines could be used below the icon if that works better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.