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

21–30 of 303 posts

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

#21

Post by wodenokoto »

master-lincoln wrote: post #19
wodenokoto wrote: post #17

In defense of the ambiguity of digital toggles, I’d like to add that this is unsolved on most, if not all, physical light switches in homes and offices. Despite having existed for more than 50 years and most people are using multiple toggles a day with its labels, most people are unaware of the meaning of power symbol ( https://en.m.wikipedia.org/wiki/Power_symbol )

Really? For me this always made intuitive sense reading it as one and zero, where zero would be off.

You probably also work in IT and might even now what binary is not to mention what boolean means.

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

#22

Post by piva00 »

vsnf wrote: post #5
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.

Without seeing the design in question, I think this still demonstrates the ambiguity the post is discussing. Is the icon what will happen, or what is currently happening? Is it the state, or is it the action? Maybe this particular design was unambiguous, but the description of it isn't.

In electronic music instruments (which derived interfaces from electronics lab equipment) it's quite intuitive there's a switch with a light on next to it the next state is off and the light switches off.

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

#23

Post by Waterluvian »

robinsonb5 wrote: post #12
vsnf wrote: post #5

Earlier quoted context omitted.

Without seeing the design in question, I think this still demonstrates the ambiguity the post is discussing. Is the icon what will happen, or what is currently happening? Is it the state, or is it the action? Maybe this particular design was unambiguous, but the description of it isn't.

If the light is beside the switch (rather than being the switch) then I'd say it clearly and unambiguously indicates the current state of whatever the switch operates? (A light also has the advantage of being a skeuomorph - much as those are now out of fashion - we all know how to interpret indicator lights in the real world.)

> A light also has the advantage of being a skeuomorph

Unless you’re my TV and it’s completely backwards for some reason.

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

#24

Post by CalRobert »

master-lincoln wrote: post #19
wodenokoto wrote: post #17

In defense of the ambiguity of digital toggles, I’d like to add that this is unsolved on most, if not all, physical light switches in homes and offices. Despite having existed for more than 50 years and most people are using multiple toggles a day with its labels, most people are unaware of the meaning of power symbol ( https://en.m.wikipedia.org/wiki/Power_symbol )

Really? For me this always made intuitive sense reading it as one and zero, where zero would be off.

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

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

#25

Post by chatmasta »

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…

> it should be obvious what the current state is

Yeah, I don't need to know which direction of my light switch means "on" (and in fact I don't know), because I can see whether the lights are on.

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

#26

Post by unnah »

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.

That would be a great use for an HDR screen - make the "indicator light" extra bright compared to the rest of the screen, to make it really obvious that the light is now "on". Of course this would only work as long as the user doesn't keep their screen too bright to begin with...

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

#27

Post by xamde »

chatmasta wrote: post #25
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…

> it should be obvious what the current state is Yeah, I don't need to know which direction of my light switch means "on" (and in fact I don't know), because I can see whether the lights are on.

Unless there is an issue with either the light source or the power source. Muted/unmuted is also a pair where unmuted often does not equal "we can hear you"

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

#28

Post by resters »

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.

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

#29

Post by maicro »

knallfrosch wrote: post #13

The solution that reliably works are lots of switches on the same screen. The user extrapolates from a single known state. Mobile users might be confused about whether Auto-Rotate is on, but they do know whether Airplane mode is on.

Mobile users shouldn't be confused about whether Auto-Rotate is on, because Auto-Rotate should always be off. /rant

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

#30

Post by kragen »

master-lincoln wrote: post #19
wodenokoto wrote: post #17

In defense of the ambiguity of digital toggles, I’d like to add that this is unsolved on most, if not all, physical light switches in homes and offices. Despite having existed for more than 50 years and most people are using multiple toggles a day with its labels, most people are unaware of the meaning of power symbol ( https://en.m.wikipedia.org/wiki/Power_symbol )

Really? For me this always made intuitive sense reading it as one and zero, where zero would be off.

this is backwards from the perspective of digital logic circuits

physical light switches toggle between closed-circuit and open-circuit, not high and low voltage levels. 'on', where current can flow, is a closed circuit; 'off' is an open circuit

in digital logic, when there is a correspondence between closed/open and high/low, the correspondence is virtually always that closed is low and high is open. for example: ttl inputs always treat open-circuit as high; the can bus and i²c bus "recessive" states (when nobody is transmitting) are high; avrs have optional pullup resistors on their gpios but no optional pulldowns, so if you want to connect a pushbutton or toggle switch to a gpio, you have to connect it between the pin and ground, not between the pin and vcc; 8051s' 'quasi-bidirectional' i/o ports similarly feature a weak pullup and a strong pulldown, so that, again, an open circuit is a logic high level

(and normally high is 1, low is 0, though sometimes this convention is also violated)

the only exception i know of is that 60-milliamp and 20-milliamp digital current loop interfaces, as used on teletypes, treat a closed circuit (current flowing) as a logic 1 ('mark'), and an open circuit (no current flowing) as a logic 0 ('space')

incidentally, 'closed circuit' and 'open circuit' are also confusing. a closed circuit is 'closed' in the sense that a plane curve is 'closed' if it divides the plane into an inside and an outside region. on a closed curve, you can walk around the whole circuit and return to your starting point without turning around, which is in some sense what the electrical current is doing. but of course actual electrical circuits exist in three-dimensional space, where a 'closed' curve does not divide space into an inside and an outside region, because you need a surface for that. and in all other contexts, something that is 'closed' is something that does not permit flow: a closed barn door, a closed window, a closed valve, etc. nevertheless, it is far too late to eliminate this two-dimensional flatland thinking from our vocabulary

Post reply on HN