Should toggle button show its current state or the state to which it'll change? (2010)
1–10 of 303 posts
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#2The point about play/pause is really interesting because it goes against the conclusion. However, it's following physical precedent that's well understood. It's also (usually) obvious when music or a movie is playing, so the button icon wouldn't even need to change for the user to understand what pressing it will do. This stands it separately to the toggle question, I think.
Back to toggles and UIs, changing the colour of the toggle from light grey to slightly lighter grey is unhelpful in the extreme. Give me labels. If labels don't fit your motif then get better designers.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#3The best thing was that it also solved the latency of an async operation. You’d click the switch which toggled, and then some moment later the light came on. It felt incredibly satisfying and gave confidence that yes, this interaction has done something.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#4Re: Should toggle button show its current state or the state to which it'll change? (2010)
#5I can’t find it but one of my favourite designs was a switch with a “light” beside it that lit up when the state was “on.” The best thing was that it also solved the latency of an async operation. You’d click the switch which toggled, and then some moment later the light came on. It felt incredibly satisfying and gave confidence that yes, this interaction has done something.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#6But if I join using the phone app on my phone, the same microphone with a line through it (that means you are muted on Teams) indicates that you are currently NOT muted, but you can use that button to activate mute. After pressing it, the icon is still a mic with the line, but it changes to a filled in background (reverse video).
Is this because in one case, that button is a "mic on" button, but in the other it is a "mute on" button, using the same icon? And the button still does an OK job of indicating what state you are currently in, as long as you know what the button looks like in the opposite state (I always have to toggle the mute button a couple times to observe what paradigm the given app is using).
I wonder if this is the price we pay for "flat UI", where designers are still figuring out design elements without a real-world reference to look back on.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#7I can’t find it but one of my favourite designs was a switch with a “light” beside it that lit up when the state was “on.” The best thing was that it also solved the latency of an async operation. You’d click the switch which toggled, and then some moment later the light came on. It felt incredibly satisfying and gave confidence that yes, this interaction has done something.
So when I revisit that page after a long time and see that the light is lit, does it mean that the state is currently ON or does it mean that the state will change to ON when I click it? How can I tell this by instantly looking at the lit light?
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#8The link should include a year in parantheses, as it's a 13 year old question.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#9I agree with the conclusion, but would like to add that it should be obvious what the current state is, and what the state will change to when the toggle is changed; too often I have to change it in order to work out that I didn't need to change it. The point about play/pause is really interesting because it goes against the conclusion. However, it's following physical precedent that's well understood. It's also (usu…
The physical precedent would be to show the behaviour as the button image (play) and then the depressed/undepressed visual state would show if the behaviour was active or not. Software designers didn't follow this and invented swapping between the play/pause icons causing this new confusion. Not for any user friendly reason, more because skeuomorphic 3d buttons went out of fashion.
> It's also (usually) obvious
The only virtue of indicating the state at all is for when you have a problem. Very common for audio at least (muted sound, unplugged headphones, linux audio drivers have become borked again... sigh).
I still get that twang of cognitive dissonance when I see play/pause buttons and have to think about it and might just double toggle it anyway when I've got an issue because I can't be 100% sure what a pause button means.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#10I can’t find it but one of my favourite designs was a switch with a “light” beside it that lit up when the state was “on.” The best thing was that it also solved the latency of an async operation. You’d click the switch which toggled, and then some moment later the light came on. It felt incredibly satisfying and gave confidence that yes, this interaction has done something.
> I can’t find it but one of my favourite designs was a switch with a “light” beside it that lit up when the state was “on.” So when I revisit that page after a long time and see that the light is lit, does it mean that the state is currently ON or does it mean that the state will change to ON when I click it? How can I tell this by instantly looking at the lit light?
Just like most devices with signal lights — which have been that way for decades. Historically, the lights are signaling power being supplied.