DEV Community

Discussion on: Should a button communicate the current state, the intended behavior, or both?

Collapse
 
cjbrooks12 profile image
Casey Brooks

The button should describe the action to be performed. Use a separate label or some other indicator to show the current state.

As a demonstration, most video conferencing apps confuse me with their "mute" button. I'll see a full mic and I'm never quite sure if it means "my mic is currently on" or "click me to turn your mic on". Since they almost always act as both the action and the indication of state, I'm left always worried that I misread the UI and am actually unmuted when I think I'm muted.

Another thought: if a button is intended to convey both state and action, it should be designed as a switch. A switch cognitively makes it clear whether it's on or not, and also indicates an action can be taken. Here, I would expect the switch's text label to indicate the current state, with the switch's own appearance, together with the label for the current state, implying what will happen when I click the switch.

Collapse
 
jeyj0 profile image
Jannis Jorre

I don't think the label for switches should change between states. That is always something that confuses me:
[ON] Do something
[OFF] Don't do something
When seeing the first it's clear: right now "do something" is on, so it'll be done. But the second isn't: "don't do something" is off - does that mean it will now be done? Or not?
If the text were to stay constant, I can switch "Do something" on or off, which makes it really clear in my opinion.

Also, always use the positive clause to avoid double negations.
Do: [y/n] do something
Don't: [y/n] don't do something.
The second could lead to "not don't do something" when read out, which doesn't make much sense. "Yes, do something" and "Not do something" make more sense. :)