[RFC] UX issues with icons-only buttons

[CMadden8]

Status: in-review; championed by @cdedreuille

Summary

This is a feature request to change, or give the option to change, the Storybook toolbar buttons to icons and text, rather than just icons. This suggestion is based on a lot of UX research that states icons-only buttons damages the transparency of the UI. There is good reading on the issue via this article on UX myths. The article also demonstrates how Microsoft benefited from changing their toolbars to icons and text.

Problem Statement

As outlined in the above article, it is very difficult for users to understand/memorise icons-only buttons. I currently find it difficult to know what the buttons are for, unless I hover over them - and even then, the tooltip delay is problematic to efficiently understanding the meaning of buttons.

There's nothing to lose by including the button names, as the toolbars are very slight re: the number of buttons. So space should not be an issue.

Non-goals

No response

Implementation

The proposed solution is to simply include text for all buttons where there is currently only an icon to indicate the button's meaning.

Prior Art

Yes, as mentioned in the above article, Microsoft made the same change to their toolbars and saw huge benefits as a result.

Deliverables

1. Transfer the tooltip text to the icon-only buttons as a label
2. Localise the text

Risks

Real estate issues with more verbose translations. However, the number of buttons involved suggests that this would only be an issue for a mobile view - so there would need to some additional responsiveness added for mobile.

Unresolved Questions

• Using a to do list makes it easy to resolve the questions as we move the RFC along.

Alternatives considered / Abandoned Ideas

I've seen no alternatives to this suggestion. Generally-speaking, the entire UX world seems to agree that icons-only buttons can only have negative consequences for the user.

[yannbf]

Hey @CMadden8 thank you so much for writing this RFC down. I believe this is a slightly tricky situation so I'll loop @cdedreuille in for opinions. He's on holiday but will be back shortly. Thanks!

[cdedreuille]

Thanks a lot for this RFC. I do agree with you. The IconButton can do a better job at explaining what would be the main function. In some cases it is quite obvious like a closing button but in the toolbar for example we might want to have better access to the information. There's 2 elements we could improve there:

• On some IconButton we could introduce a better tooltip that will inform about the use straight away as you hover.
• We could move from IconButton to a real button in the toolbar for some actions. For now we don't want to do that mostly because the toolbar is also used on mobile.

Design wise I think it would be great to explore this further to make sure we improve readability and accessibility of these features. We are doing a lot of updates on the core layout of the manager in preparation for Storybook 8.0 including some key mobile updates. When these are done I would love to explore these further.

[Sidnioulz]

@MichaelArestad I'm not sure if you've also taken over Charles' RFCs so I'm taking the liberty to let you know about this one.

[MichaelArestad]

Thanks @Sidnioulz!

[Sidnioulz]

There's nothing to lose by including the button names, as the toolbars are very slight re: the number of buttons. So space should not be an issue.

I think that's not true for all instances and situations. When using extra addons to e.g. select a language, a theme, etc. and when using badges, or when DevTools are open, space can become scarce.

We could want to let end users choose if they want toolbar buttons to show a label. We could also want to treat mobile distinctly from desktop. We would likely need to reserve more vertical real estate for the toolbar.

unless I hover over them - and even then, the tooltip delay is problematic to efficiently understanding the meaning of buttons.

There's an immediate quick win here: we can replace title with Tooltip to reduce the display delay to e.g. 100-200ms. This would provide faster feedback. It would apply to all IconButtons, including those that need to stay as icons.

From an API standpoint, if we wanted to include labels around/below icons, we'd want a separate component from IconButton. IconButton is also used in places where there definitely never is extra space (e.g. clear button in the search input).

If we wanted to validate which icons are acceptable to use without text, the NN Group provide a list of methods for icon testing in their article on icon-only button usability.

[MichaelArestad]

I think that's not true for all instances and situations. When using extra addons to e.g. select a language, a theme, etc. and when using badges, or when DevTools are open, space can become scarce.

You are really highlighting the main reason the buttons don't have text. It's all in an effort to reduce the amount of space they take. That said, I have some ideas that we could maybe try.

1. We could start hiding the labels conditionally as we run out of room. I don't love this as they will likely shift around based on what label is set (in instances where these act as a Select) or when a user resizes the window (common).
2. We could implement an overflow menu. This is something I have proposed in the past, but allows buttons that don't fit to be collected into an overflow menu.
3. We could make showing the label a setting somewhere. I think this could be an interesting place to start.

Ideally, I would like to have more rigor in how we present and configure these toolbar buttons. I am still gathering my thoughts on this aspect.

There's an immediate quick win here: we can replace title with Tooltip to reduce the display delay to e.g. 100-200ms. This would provide faster feedback. It would apply to all IconButtons, including those that need to stay as icons.

There is also a nice option on the Radix tooltip primitive that allows triggering tooltips after the first with no delay. Basically, a minimal delay for the initial tooltip over the first button and no delay for others after that (if you are moving through them in a row to see what they do).

[Sidnioulz]

1. We could start hiding the labels conditionally as we run out of room. I don't love this as they will likely shift around based on what label is set (in instances where these act as a Select) or when a user resizes the window (common).
2. We could implement an overflow menu. This is something I have proposed in the past, but allows buttons that don't fit to be collected into an overflow menu.
3. We could make showing the label a setting somewhere. I think this could be an interesting place to start.

Ideally, I would like to have more rigor in how we present and configure these toolbar buttons. I am still gathering my thoughts on this aspect.

In the spirit of throwing ideas around and not restricting ourselves too much:

4. A more radical option would be to move the toolbar to the side of the screen as vertical space is more valuable than horizontal
5. The toolbar could be made taller and labels shown under their icon, to decrease the horizontal pressure
6. The whole toolbar could be reimagined as a drawer, where only visible settings are shown in a sort of status fashion when it's closed; as it opens, it would show a wider settings grid where each item can take the real estate it needs, a bit like what's done on phones

There is also a nice option on the Radix tooltip primitive that allows triggering tooltips after the first with no delay. Basically, a minimal delay for the initial tooltip over the first button and no delay for others after that (if you are moving through them in a row to see what they do).

That's pretty smart.