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

151–160 of 303 posts

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

#151

Post by kqr »

AceyMan wrote: post #123
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…

When I was just starting in IT (~1999) it was already a joke that you could identify where different MSFT teams wrote elements of software (say, Outlook) when a common action was implemented two different ways (explained by Conway's Law as I know now).

This is an older joke than that. My parents used to say the same about switches in cars going the opposite direction for activating stuff.

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

#152

Post by fckgw »

superjan wrote: post #122
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

They won’t. The car maker has the Budget product and the Premium product. The car maker wants to justify a high price for the Premium product, so they put in all conceivable features, useful or not. What you want is a Decent product. If they add it to the product line, it would cannibalize sales for the premium product, so they gain nothing. For the same reason my wife’s Premium electric toothbrush has a color screen…

All these features are available in a base model $20k Hyundai Elantra though.

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

#153

Post by SkyMarshal »

Should show both, just as analog switches do. You want it to clearly unmistakably show the current state, but also the state to which it will change.

Apple has really nailed that with its sideways slider toggles. You can clearly see where the toggle is currently, what it will change to, and whether the current setting has made some feature active (blue background inside the slider) or inactive (grey background inside the slider).

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

#154

Post by fckgw »

actionfromafar wrote: post #60
rjmunro wrote: 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.

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

You're looking for literally any Hyundai, Kia, Toyota, Honda, Chevy or Mazda sedan. Hope this helps.

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

#155

Post by kqr »

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.

It should have a label saying "recording" or something to that effect. I don't know microphone terminology, maybe it's "picking up".

With a label, a light indicator is unambiguous.

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

#156

Post by mywittyname »

denton-scratch wrote: post #86
bee_rider wrote: post #55

RIP Checkbox, 1990-2009, you were perfect and unambiguous but for some reason smartphone designers hated you.

I agree that checkboxes are perfect; but that's because I never try to fill forms on a smartphone. Native browser checkboxes are often unusable on smartphones; too small to hit with a thumb.

Properly designed, the tapping/clicking the text should also trigger the checkbox.

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

#157

Post by crazygringo »

sitzkrieg wrote: post #77
crazygringo wrote: post #48

Earlier quoted context omitted.

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

Not being vision-impaired, no.

Can you elaborate what your point is, since not having done so, I can't begin to guess?

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

#158

Post by Someone »

pera wrote: post #142
bee_rider wrote: post #55

RIP Checkbox, 1990-2009, you were perfect and unambiguous but for some reason smartphone designers hated you.

Who created the checkbox widget? System 1 (1984) had check marks on the menu and "x boxes", which are equivalent, but not checkboxes afaik

> System 1 (1984) had check marks on the menu and "x boxes", which are equivalent, but not checkboxes afaik

I think it had (https://andymatuschak.org/files/papers/Apple%20Human%20Inter..., page 56)

I don’t know whether those were the first, but https://skeuomorphic.design/p/from-paper-ballots-to-pixels-t... claims they were, in the sense that the Mac made radio buttons different from toggle buttons.

Does anybody know in what cultures a checkmark would be inappropriate, as that page claims?

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

#160

Post by croes »

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.

A checkbox show both, the current state and the possibility in form of a simple yes/no option.

A toggle button is confusing because I don't know the designers intention unless the button shows both options beside it

Mute On[---()]Off

Post reply on HN