Live data from Hacker News

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

ux.stackexchange.com

131–140 of 303 posts

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

#131

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 )

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

What? This has been solved for physical light switches since before physical light switches existed.

If the light is on, the switch is set to "light on". If the light is off, the switch is set to "light off".

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

#132

Earlier quoted context omitted.

Because language works through association and analogy, you don't actually need to know the etymology of a word or symbol to use or understand it. Any English speaker can understand perfectly well the words manual, manufacture and manicure without ever reflecting on the fact that "manus" in latin means "hand". We clearly haven't needed to rename these words "handual", "handufacture" and "handicure" for these concepts…

> you don't actually need to know the etymology of a word or symbol to use or understand it. Etymology, etc. helps to understand what other people mean and have meant by the word, and what others will understand.

No, it doesn't?

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

#133
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…

I think part of this confusion stems from the "default mic on" mindset, where "mic active" is assumed to be the default, and mute is a deviation from that state. We can trace this pattern back to the UI of phone conference systems, back through analog phones, back to the time of a literal wire connection between parties.

Many/most audio mixers (in the context of live music and recording) and their digital brethren use the same pattern - a "Mute" button which lights red to indicate that channel is silenced. But a few have an ON button above the fader which lights to indicate the channel is active.

I think it's about time conference applications rip off the bandage and take the "audio off by default" approach. We can kinda see it already with UI elements that light up when a speaker is talking.

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

#134
I usually make a toggle button reflects its current state and shows the next state in some other way, like in the hover over tooltip or small subscript text. That means a toggle updates two things, the button itself and the tooltip.

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

#135
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…

Discord is worse. Their buttons for mute-microphone and turn-off-camera are inverses of each other.

Yes! So confusing.

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

#136
The main issue with toggle buttons is that you have an object that at the same contain the state of the system and the action to change it.

The consequence is that it is not clear if the "ON" that you see on it is the current state (so pressing on it will turn it to "OFF"), or the action that you will invoke when you press it.

The solution is to separate (part of) state and action, and this can be done in a few ways. One possibility is to do like one of the answers in the link suggests, and write the label _outside_ the button. If you don't have a switch but a toggle button (like the teams example in some other comment), leave the icon alone, and change some other properties of the button (for example leaving it pressed to signal the "ON" state, like it has been done for decades without any issue....)

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

#137

There should be no ambiguity here! A toggle button is an analogue for a physical switch. Unless the switch state is dependent on other switches, it must always display its current state. i.e. ENABLED is always true unless POWER is OFF.

There is ambiguity in the physical world. Some audio equipment have what's called a ground lift. It physically disconnects the ground conductor between two devices, and it's usually a single push-toggle in/out button. I've seen some devices with "Ground On/Off" - does that mean grounded (not lifted) or not grounded (lifted)? IIRC one of the DI boxes I've used is the opposite of what you'd expect - "Off" means lift is off, meaning ground loop is connected. The sensible devices have two states "Lift/Gnd".

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

#138

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…

I like it. Why doesn't our "industry" look at aviation/military more often where miscommunication gets people killed.

I think the answer is that "looking pleasant" is much more of a goal for commercial software. In usability terms the much denser GUIs of the 90s were arguable better in some ways than what we frequently see today, especially for power users.

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

#139

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…

I like it. Why doesn't our "industry" look at aviation/military more often where miscommunication gets people killed.

[deleted]

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

#140
post #98

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

This is extra silly because you can make what's effectively a checkbox look really nice and toggle-y. Although this is a bad example it shows that it doesn't have to be a square with a check mark in it: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...

Issue is that modern UX designed moved away from this type of 3D buttons. There was a big transition from UIs using heavy skeuomorphism to a more flat and digital look.

To achieve hat you're showing you need some depth to the button. Hard to accomplish with today's design trends.

Post reply on HN