Why not just use a checkbox? Is anyone here a designer with a serious answer to this?
I think toggle switches are newer and therefore designers think they are more fancy to use.
Should toggle button show its current state or the state to which it'll change? (2010)
91–100 of 303 posts
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#92A 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.
"Mute" "Unmute" I want a button to tell me what it does if I click it. If you want to show the current status that is a different thing, not a button. A button exists to be clicked, it should communicate what it will do if you click it.
So, while the button is not interacted with (unmuted) and not hovered over you would like a mute button to be what? Would you like it to be black and white with a microphone symbol where the microphone is white and the background is black? When you hover your mouse over it should a no symbol in red appear over it which could appear black for color blind? When you toggle this mute button should that no symbol stay on the icon and invert all of the colors so now the background is white the microphone is black and the no symbol is white?
I'm really confused by the concept of a button showing me what a button should do All of the time because if that button is showing me what the button should do then that button is indicating to me that that button is doing what that button is doing not what the button should be doing. That's why there is a hover over state if you're using a mouse things become more complicated when you're using touch which is why I think the button should not communicate what the button should do when interacted with but the current state.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#93Earlier quoted context omitted.
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.
I mean, sure? But, to that point, why discuss the conventions? If the goal is to have a predictable interface, it seems fair and in scope to study larger interfaces that people have to read quickly.
Don’t get me wrong I actually agree with you. I’d also love to have more consistent ui’s, but at the same time I get why the business wants to differentiate it self from the competition by not having a super effective “boring” ui.
What I’m getting at is that it’s a lot more nuanced than what I as a software developer might like.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#94Tesla makes this mistake with their ambiguous "lock" button on the iOS app. The button toggles between an open/closed padlock icon. I often lock the doors remotely and since I can't physically see the car to confirm, I get paranoid about whether the icon is representing state or action.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#95In 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 )
While the NEC does not specify light switch toggle orientation, there seems to be a general convention among electricians and installers for the toggle switch to be positioned up for "on" and down for "off."
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#96I'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?
I mean, we do have solutions to this problem. You use them every day. The problem is that, unlike air travel or the military, nobody can say "everybody must do it this way". So, a lot of people do it their own way.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#97We had radio buttons forever, but no, let's complicate things.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#98RIP 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...
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#99RIP 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.
True.
It seems like an odd historical problem though. We could just render checkboxes bigger or with more white space around them, and make the touch area bigger in any case.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#100This is a problem for forms where companies are legally required to follow the users instructions but may not want to. I find myself not trusting them to not pick deliberately unintuitive interpretations. Think the kind of designer that comes up with "check this box to receive transactional emails but not marketing emails", when an unchecked box leads to marketing and transactional emails.