Live data from Hacker News

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

ux.stackexchange.com

71–80 of 303 posts

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

#71
I'm surprised we are still iterating on ideas like this, to be honest. Seems flight decks have been rather successful on complicated dashboards for a long time. Same with boats. Why can we take approximately no lessons from them?

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

#72
post #59

There are a number of ways to get this wrong. The shuffle button in Spotify on our Tesla is a grey color, and you have to wonder if it's dark ENOUGH a grey to indicate that it's on, or a light grey to indicate that it's off. So then you go to toggle it on and off to see the state change, but actually it's buggy so it doesn't do anything. When you finally get it to toggle on, you realize the shuffle lines turn GREEN,…

Also, the problem with buttons like this is that the shade of grey depends on the angle you're looking at the screen, so you end up moving your head around trying to figure out if it is actually on or off.

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

#73
post #41
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

This is what I like to use. Two states with a clear selection of one, all visible at all times.

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

#74

Why not just use a checkbox? Is anyone here a designer with a serious answer to this?

Cuz they ugly

The dribblization of UI lead to a bunch of people trying to make things pretty for their own benefit. Then they look at it in Figma and it looks absolutely stunning. Never mind that actually needs to be understood and used by someone, that’s irrelevant.

Just today I saw a HSL color slider on Twitter that was a single hue slider with two half-arc sliders on the main slider’s handle: one above for saturation, one below for lightness. It sounds like a joke but…

https://twitter.com/jh3yy/status/1756429165803246028

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

#75
post #45

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.

Yes, 100%! This is my second most frustrating UX gripe with the Tesla trunk UX - the first being the super long animation you have to wait through in order to open the trunk after putting the car in park. Overall tesla UX is miles ahead of other cars, but the little things like this are so frustrating!

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

#76
post #71

I'm surprised we are still iterating on ideas like this, to be honest. Seems flight decks have been rather successful on complicated dashboards for a long time. Same with boats. Why can we take approximately no lessons from them?

overpriced ux designers

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

#77
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 shu…

have you tried to use spotify with a screen reader lately?

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

#78
post #35
post #15

Using words often works. But let me chime in with some outrage about the icons on an Android tablet - a triangle, circle and square with no discoverability and no ability to add text to icons on the home screen? WTF?

It takes 1 day to learn, to avoid years of extra clutter on the screen. But an option or a long press tooltip would be nice for special cases.

Legibility isn't clutter. We moved away from hieroglyphics a long time ago because alphanumeric characters are objectively better.

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

#79
I have some old NASA push button switches that have two bulbs in them. When the switch is off both lights are off, when you click the switch the yellow bulb comes on and lights up the switch, and when the device you turned on actually turns on a green light turns on ( and the yellow turns off ). The idea is you push the button and the yellow state is the confirmation that you toggled the switch, but the green is the confirmation that the action you wanted occurred. Kind of an interesting 'state feedback' mechanism.

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

#80
post #71

I'm surprised we are still iterating on ideas like this, to be honest. Seems flight decks have been rather successful on complicated dashboards for a long time. Same with boats. Why can we take approximately no lessons from them?

Perhaps what we do on a pc is not really that complicated or critical compared to flying a plane or steering an oil tanker. Just a thought.
Post reply on HN