Use cases for a button with multiple states

[lukewarlow]

This issue is for collecting use cases for a button with multiple states. Referred to as cycle buttons in some prior discussions.

I'm not looking for ideas on how this could be implemented (e.g. button, checkbox, switch, select), just for examples of how it would be used.

Usecases could have any number of states but ideally should be (for the sake of discussion) less than 10.

[o-t-w]

I've not seen this in any design systems (and over the years I've looked at most of the big ones). The only use case I can think of right now is dark mode/light mode/system. It seems pretty niche - I've had a look around and struggled to find any real-world examples. I do like the idea of <option>s inside of button though.

[o-t-w]

Found this example on the Otta website:

[lukewarlow]

The repeat button in youtube music seems like a perfect example of this. It has 3 states Repeat Off, Repeat One and Repeat All

[keithamus]

GitHub's repository action buttons have state.

Unwatch/Watch and Starred/Star

Similarly the issue subscription button which is Subscribe/Unsubscribe:

[o-t-w]

There's a fun theme-picker example here: https://www.vectrotype.com/vctr-mono.

[scottaohara]

Probably the most common types of cycle buttons:

Play / Pause
Mute / Unmute

Follow / Unfollow

Really, any type of button that changes its visible label / accessible name, rather than a distinct property could fall into this category. Though, not all instances of these in the wild would necessarily be good use cases for a cycle button - especially if a state exists which would allow for a consistent accessible name.

For instance, many instances of "show more" / "show less" buttons often could have been a button with a single name and an aria-expanded state.

[o-t-w]

If a button only has two "states", couldn't it also be represented as a "pressed/not pressed" toggle button? I'm having trouble fully understanding the difference.

[gfellerph]

If a button only has two "states", couldn't it also be represented as a "pressed/not pressed" toggle button? I'm having trouble fully understanding the difference.

A cycle button could have two completely opposite states while a pressed button toggles one state on or off (kinda like a switch).

https://m3.material.io/components/switch/guidelines provides some examples. A cycle button could cycle between map and list view (two opposing states), a pressed button could activate or deactivate writing in bold in a rich text editor (a single state on or off).

[scottaohara]

@o-t-w sure if it only has 2 states then it “could” be created as a pressed / not pressed button. But the key difference is if the name / purpose changes

maybe referring to these as “states” is the wrong way to be thinking about it, and part of the reason why the html thread had people talking past each other.

A state is more like a pressed/not pressed, checked, selected, etc. an adjective to describe the current state of a control whose purpose (name) remains consistent

so a play button that was in a pressed state is playing. But in a “not pressed” state is “paused”. But the name of the button would always remain “play”

a cycle button swaps the name of the button to indicate its new purpose. It’s not really a state (at least not how that term is actually defined)

so a cycle button would swap out its name “play” and “pause”. There is no additional state that is needed (and a common a11y error is when developers change the name of a control AND add modify a state, such as pressed/not pressed. It is confusing to know what the control is actually doing or not if you’re being told opposing things. E.g., “paused, not pressed” - is this paused or not?)

The real kicker that was causing lots of back and forth in the html thread is that some people want to use a cycle button to represent changing “values”.

So a play/pause cycle button has a name that represents the opposite of what the media player is doing.

The GitHub cycles behave in the opposite fashion, where the current name represents the current user choice. Essentially behaving like a 2 option select element where the current choice for that element is the “value” it would submit if part of a form.

But your Otta example behaves even a bit differently to the above two. The name / purpose of those don’t change, but an extra state/value cycles (no opinion, like, must have) are cycled.

It’s all a bit messy - wanting all these different behaviors for one control. It can probably be done, but people need to have a consistent baseline of understanding that we are all asking for different things and acknowledge whether or not we need them all, or if other existing controls might suffice - and are some of these cycle buttons really just - for instance- select elements that you need to expend more effort to choose an option? Or do we try and fit all these bits into a single control and write very detailed author guidance so they understand these differences and can provide users a consistently good experience.

(sorry. This became a lot longer than I thought it would. I hope this is helpful to level set though)

[o-t-w]

Thanks for such a clear explanation.

I really liked the UX of the Otta example. When there are three options it seems like a nice pattern (any more and I would opt for a select). With a select you have to press once to open the dropdown, and press again to select an option, so arguably the cycle button is fewer steps. Visually, having a great deal of select elements would look odd and ugly imo.

[lukewarlow]

maybe referring to these as “states” is the wrong way to be thinking about it

Yeah that's probably my bad could have worded it better. Tried to avoid using a word that was an implementation detail. But might have made it more confusing.

[scottaohara]

@o-t-w - that's fair, and one reason why i was saying having a cycle button with MANY options to choose from in it is a bad idea. it's a rather hostile UX - it'll be very hard to convince me otherwise. But i don't disagree that 3 maybe 4 options max, that can be equivalent to the number of clicks/keyboard key presses to using a select element and finding the right choice.

@lukewarlow no worries on the wording. it's hard to choose one word when we really need 3, and there is no one word that equally describes each. "state" is probably the 'best' word to introduce the issue, and it's only when you get super pedantic, like me, and start gerrymandering what people are trying to do with these (change action, choose value, arguably modify state/value) that it starts getting murky :)