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

111–120 of 303 posts

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

#111

Post by cobbal »

gedy wrote: post #109
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…

This is a case where I think the indicator (LED in real world) should be separate from the button, which label does not have to change.

Should the LED indicate mute on or mic on? I could see it both ways, and so I would also have a hard time trusting this UI at first.

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

#112

Post by delecti »

ikealampe200 wrote: post #104
toast0 wrote: post #69

Earlier quoted context omitted.

> cruise control with "follow speed" If I'm reading you right, you want your car to follow the speed of the car in front of you? Usually delivered by radar assisted cruise control? That's complicated stuff, and you'll probably get lane keeping assistance too, because it's a package. At least on my car with lane keeping, there's a big button in the center console to disable it.

This is not particularly advanced. Mercedes offers “Distronic” since 1999 and it seems Mitsubishi developed something similar even around 1992. [ https://en.m.wikipedia.org/wiki/Adaptive_cruise_control ]

Oh is that what "Distronic" does? I literally work there on a backend system that has that term for one of the features, and I've just never known. I always thought it sounded like something AV related (it sounded "disc" adjacent).

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

#113

Post by alpaca128 »

The only two good suggestions I saw were radio buttons as well as toggles with labels on the left & right (so basically two merged radio buttons).

I think the play/pause button in media apps is an acceptable exception simply because it's obvious whether it's playing or not - you could even use it without recognizing the symbol, if music is playing you know a click will pause it.

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

#115

Post by deepsun »

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.

And should the sides switch in right-to-left scripts? :)

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

#116

Post by samatman »

furyofantares wrote: post #82
actionfromafar wrote: post #60

Earlier quoted context omitted.

Can someone make a car which has none of the complicated stuff? List of features I want: - automatic transmission (if ICE) - bluetooth and FM radio - no self steering - cruise control with "follow speed" - not-batshit-insane self-brake-system (use whatever Volvo uses, it works!) - good airbags and decent structural integrity - classic sedan height

No, you can't get a car with exactly the feature set you specifically want and nothing more. This is because other people want a different feature set. It's even true of things that are vastly less expensive to produce than a car.

This is true in general (for all feature sets anyone might want, there must exist a car with those features) but doesn't have to be true in particular (for a given feature set, there may exist a car with those features).

I suspect you have no idea if OP's feature set is available on the market. I certainly do not.

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

#117

Post by samatman »

delecti wrote: post #112
ikealampe200 wrote: post #104

Earlier quoted context omitted.

This is not particularly advanced. Mercedes offers “Distronic” since 1999 and it seems Mitsubishi developed something similar even around 1992. [ https://en.m.wikipedia.org/wiki/Adaptive_cruise_control ]

Oh is that what "Distronic" does? I literally work there on a backend system that has that term for one of the features, and I've just never known. I always thought it sounded like something AV related (it sounded "disc" adjacent).

It is "disc" related, the discs in question are the brake discs.

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

#118

Post by SoftTalker »

cobbal wrote: post #111
gedy wrote: post #109

Earlier quoted context omitted.

This is a case where I think the indicator (LED in real world) should be separate from the button, which label does not have to change.

Should the LED indicate mute on or mic on? I could see it both ways, and so I would also have a hard time trusting this UI at first.

Should be a text label in present tense not (or not only) an "LED". I like radio buttons but something equally unambiguous could also work.

  Microphone Status
    [ ] Muted
    [x] Unmuted

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

#119

Post by samatman »

ZitchDog wrote: post #81
taeric wrote: 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?

The interfaces you are talking about require years of training, study and passing multiple tests to demonstrate proficiency. In software UX we are talking about discoverability and approachability for the untrained operator.

Since failure to operate the controls correctly can get hundreds of people killed, there are detailed regulations governing how those controls must work.

OP is entirely correct that the UI field could learn a great deal from those standards.

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

#120

Post by Izkata »

mapreduce wrote: post #7
Waterluvian wrote: post #3

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.” 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?

This interface has both a toggle switch and a light indicator next to it. Both state and action (ish).

The light is independent of the toggle and shows the current state, which is why they mentioned a delay - clicking the toggle doesn't immediately change the light indicator next to it, clicking the toggle tells the system to turn it on and the toggle changes immediately to show desired state, and only after the system changes and sends back "I'm on now" does the light indicator change.

Post reply on HN