Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should toggle button show its current state or the state to which it'll change? (2010)

ux.stackexchange.com

Post reply on HN
Print view View original

41–50 of 303 posts

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#41

Post by krab »

resters wrote: post #28

A toggle button should show its current state. A checkbox is a good example. Muted [] vs Muted [x] It's pretty obvious. What gets tricky is when designers create UI that does not have as clear a connection between the word used and the visual design, such as: Mute Off [---( )] Mute On [( )---] I have no idea what either of these mean because they include the action in the description of the state.

If there's enough space, a toggle emulation with two labels works well.

Loudspeaker [()---] Crossed-out loudspeaker

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#42

Post by thinkmassive »

The Tesla app is horrible about this.

What does a greyish padlock icon indicate? Let me tap it twice to cycle through states, then I’ll click once more if the original state needed to be toggled. If there’s any delay in the car’s response, prepare to complete another lock/unlock cycle, more slowly this time to be certain.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#43

Post by tshaddox »

thinkmassive wrote: post #42

The Tesla app is horrible about this. What does a greyish padlock icon indicate? Let me tap it twice to cycle through states, then I’ll click once more if the original state needed to be toggled. If there’s any delay in the car’s response, prepare to complete another lock/unlock cycle, more slowly this time to be certain.

It’s also inconsistent. From what I remember, the padlock toggle shows the current state (an unlatched padlock means the doors are unlocked, and pressing it will lock the doors), but the trunk button shows the opposite (an open trunk means the trunk is closed, and pressing it will open the trunk).

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#44

Post by Agraillo »

The designers of everyday things also fall into this trap. My favorite example is the hammer drill, this kind should had the mode switch. I have a very decent device but implementing the same problem on/off approach showing and hiding the state. I almost always pause before choosing the right one. The example of the better design (mention in the stackexchange answers) is visible at the hammer drill polish wiki page: https://pl.wikipedia.org/wiki/Wiertarka_udarowa

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#45

Post by rjmunro »

The absolute worst example of this I have seen is the Tesla dashboard screen UI. It shows a car with labels on it, not buttons, that say "Open". That unambiguously means that the particular part is open. But that's not what it means. The labels are in fact buttons to open the parts, and you have no way of knowing.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#46

Post by sojournerc »

Agraillo wrote: post #44

The designers of everyday things also fall into this trap. My favorite example is the hammer drill, this kind should had the mode switch. I have a very decent device but implementing the same problem on/off approach showing and hiding the state. I almost always pause before choosing the right one. The example of the better design (mention in the stackexchange answers) is visible at the hammer drill polish wiki page:…

I have a welding mask with a "grind" mode that has the same issue. Not exactly something you want to get wrong when welding.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#47

Post by signaru »

It is forgivable if the wrong choice is not so harmful (e.g. play/pause a video) and the effect is reversible. There's an e-commerce website I use that has an option to post product reviews as anonymous with a "slide toggle" typical of mobile devices. The only feedback is after the review gets posted which cannot be undone. I just learned by experience, but it is always confusing to interpret.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#48

Post by crazygringo »

BLKNSLVR wrote: post #2

I 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…

> Give me labels. If labels don't fit your motif then get better designers.

That's unhelpful and unreasonable, particularly on mobile.

There's no room on Spotify for labels behind every button, for instance.

Not if you want room to show the cover art, which I do.

It's not a question about "better designers" -- space constraints are real, and sometimes you really need things available at a single tap. I don't want shuffle to be buried behind a pop-up menu.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#49

Post by crazygringo »

lupire wrote: post #32
CalRobert wrote: post #24

Earlier quoted context omitted.

It always seemed backwards to me, since a circle should represent a closed circuit

An open circuit would then be a C not a |

Those wouldn't be easily distinguishable though.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#50

Post by Kuraj »

derekp7 wrote: post #6

This has been really frustrating to me lately with Microsoft Teams. If I'm in their app, the mute button is a microphone with a line through it (if mute is activated, i.e. if the mic is off). And the icon changes to a microphone without the slash over it to indicate that you are no longer muted. Makes sense. But if I join using the phone app on my phone, the same microphone with a line through it (that means you are…

Man... That's one button where you really DON'T want to be confused
Post reply on HN