Should we show an "Add" label next to the Block Library button on desktops?

[jasmussen]

The Block Library (aka "Inserter") is one of the most important interfaces in Gutenberg. The purpose is to level the playing field for blocks — everything is inserterd using this interface.

You can insert using the Editor Bar (top left). You can insert using the slash command. You can insert using the button on the side of an empty paragraph.

For the top left button in the Editor Bar, should we add a label on wider breakpoints, when there's room?

Mockup:

One challenge her is translations, as those usually ad a fair amount of width to labels. Here's german:

We would want to show this label at desktop breakpoints, not mobile or small screen widths. We would show the label only for the button in the editor bar. We might want to hide the label when a user has the "Fix toolbar to top" option checked.

Thoughts?

[karmatosed]

This is interesting and whilst I understand it's good as an indicator of state - icons are well only good if they are understood by everyone and that's a stretch to assume - I do wonder if it's creating confusion now being different. For example, now the by content just has '+'. I also feel it seems more like an extra link and makes me question why redo/undo haven't got text. Something to think on though because if we are doing this for some should we do for all? I don't think that's a clear yes but I am not sure if this halfway position doesn't cause further issues.

[jasmussen]

Totally fair points.

In my head, it's all about balancing the wealth of features that WordPress have to offer, and giving them a varying amount of real-estate and presence depending on the importance of the feature. "Publish" needs a label. "Bold" probably works fine as just an icon with a tooltip (and perhaps similarly Undo/Redo). In this case, "Add block" has worked for us so far, but given that it's an important interface, perhaps it deserves the extra attention that a label would give it. Given the label is "responsive" in its appearance, in that it appears on desktops and not mobile, I think it could serve to reinforce the plus/circle icon's meaning when shown in other contexts, as the icon remains unchanged.

Though if we can do without the label, I'm also fine with that.

[karmatosed]

I am ok if we want to try this as a test, we can always remove if we feel that's better. Maybe we could also have this as a controlled test?

[hedgefield]

I think it's a good idea, with three considerations:

1. I agree that it further emphasizes the consistency issues - we have buttons with shapes and no icons, buttons with icons but no shape, icons by themselves... More on that below.
2. I think translations will be okay, there's a lot of space to work with even on smaller screens.
3. What will be essential in this design exploration is knowing what the widest toolbar is so we can determine where the breakpoint should be.

I did a test with the paragraph toolbar and a slightly longer string, which works fine even slightly past the point where the content starts getting resized.

But regarding point 1, I think it will be no surprise that my vote would be to at least give all the icon buttons a label.

I tried this, and that still works pretty well up to the content width breakpoint too. 🎉

I'm not super jazzed that the whole bar is full, but then again, this will not be the default as the toolbar is only contextual, and pushing the viewport one pixel further would collapse things down to the icon-only buttons we have now.

I like this better than only having some icons with text, what do you think?

Speaking of, was there any further decision made on fixed toolbar vs block toolbar, or whether it will stay a choice?

[jasmussen]

Great thoughts, Tim.

I think perhaps you are too optimistic about the responsive and translation aspect :D — without element queries we have to rely on media queries to decide whether to show a label or not.

In other words, you can probably find a breakpoint where labels for all the buttons show up fine in English, but in German it would be cropped, not hidden. The alternative is to use JS to calcalate available space, which becomes a rabbit hole.

That's why I've focused this ticket strictly on the Add button for now.

[karmatosed]

I have to say I worry deeply about the translation issues having everything have a label opens. I just can't see it fitting unless you have a huge screen, which feels less than optimal. The visual complexity seeing it with all labels brings adds to causing usability issues with those perhaps on the spectrum or with reading differences like dyslexia. It's a balancing act but I think this visual representation shows what happens when we go to far, unfortunately.

[karmatosed]

Speaking of, was there any further decision made on fixed toolbar vs block toolbar, or whether it will stay a choice?

This is a fun one, the feedback still sits pretty much 50/50 on either. I kind of am partially thinking leave the option in at this point. Which yes is super weird to think.

[hedgefield]

Yes, having it only docked to blocks would open up a lot of space to play with here 😉but I am also 50/50 on what I prefer there, so it's good to offer the option.

I hear you though, I'm not super jazzed with how much is going on in the toolbar with all the shapes and patterns, I just wonder how we can make it unified and readable for everyone.

[afercia]

Dyslexia is not the only impairment we should account for. When it comes to other impairments or disabilities, text is needed. For example, consider speech recognition software users. It's a balancing act. As accessibility team we've given feedback many times before, always pointing out that plain text is always a better choice than icon-only controls. Of course, we should avoid "walls of text". Ideally, visible text labels are always preferable, that doesn't mean text must be necessarily big in size. It must be readable though.

I think it's probably too late to rebuild the UI accounting for visible text labels. However I'd just like to show an example of what other UIs do (and I've already used this example in some previous issue):

I guess the Android UI has gone through a fairly good amount of research and user testing 🙂and in many cases (not everywhere to be honest) it uses icons + text.

[karmatosed]

@afercia I absolutely don't want us to cater for only one, I also mentioned a few. As said it's about balance. This is an interesting and good problem for us to all work through. I also mentioned translation which for any text causes issues.

[afercia]

Sure 🙂I share the concern about translations, I think we'll face it also in other parts of the UI.

[hedgefield]

The example of text below the icons is interesting at least, that is something I could explore in a mock.

[karmatosed]

@hedgefield I don't want to stop any exploration but I feel for now we need to maybe settle on what we have and then after wider feedback review. I am concerned a lot about the translations and that is something we are going to have to review in feedback too.

[hedgefield]

Yeah let's kick off with just the Add label and see how it feels 👍

[afercia]

Implementation details: it't not clear if the visible text "Add" is going to be the button text or some additional text displayed close to the button. From an a11y perspective, the visible label needs to be the accessible name of the button:

For example, speech recognition software users will see a visible "label" that says "Add"; thus, they will try to voice a command "Click Add" and this will work only it the button accessible name (its text or aria-label or element referenced by aria-labelledby) is "Add". Of course, when the "Add" is displayed, the button shouldn't have a tooltip.

On small screens, when "Add" is not displayed, the tooltip should work though.

[karmatosed]

Let's take what we have into wider testing and we can always come back to this point. Noting a closed issue doesn't mean we can't reopen.