I know the right side is on.
But whenever I have to use them, I always have this little doubt on my mind of "did I really set it correctly?"
Am I going crazy or are these things a fad with much worse usability than checkboxes?
1)I'm going to give you an easy one to start. You see a toggle switch. It is set to on (probably - the little colour bar in the switch is coloured in).
It is labeled "Disable fnurbification".
Okay now what? Does "on" mean I'm going to be fnurbified? Does switching the switch disable the fnurbification so I actually have to switch it to "off"? No that's crazy. "on" means "disabled", cognative dissonance aside.
2) You see a toggle switch. It is set to on like before. It is labeled "Disable fnurbification".
We learned before that "on" meant "disabled", but that filled us with a vague sense of unease. For whatever reason we try toggling the switch. The text changes to just "Fnurbification"
Okay really now what? Is my fnurbification on? You try flicking the switch back. The colour fills in and the label changes to "Disable fnurbification" again. Okay what are we supposed to do?
What's happened is the designer has read a post on medium about accessibility and that screen readers don't read out the colour of the filled in part of a toggle switch, and has decided to help by changing the label when the state of the switch changes.
The problem is now the label could either be describing the current state or be describing what happens when you flip the switch. And there's really no way of knowing. I've seen this very often with the UX for boolean selectors where they use things like buttons rather than toggle switches. Does pressing the button do the thing it says on the label or does the label describe where we are now and pressing the button will reverse that? No way to be sure.
Postscript: Notice that whatever you decide is correct in the second case could change what you would do in the first case if the first type of selector is one that would change label when you toggle it.
Clarification: the label should toggle when the GUI toggle switch is toggled.
That said, people use this UX pattern all over the place, and sometimes I'm sure on purpose. Istr one iteration of facebook's data privacy and sharing dialogue used to have it. There was a switch called something like "Enable privacy protection" and you see it set to "off". So you switch it "on" and the label changes to "Disable privacy protection". So which one gives me the privacy protection?
Privacy protection [ o-- ]
Privacy protection is disabled. Other users can blah blah blah
Privacy protection [ --o ]
Privacy protection is enabled. Other users cannot blah blah blah
I imagine at least 90% of people, upon seeing an option to enable privacy protection, would enable it. But by making the option confusing, you'll end up with people that want it on and inadvertently turn it off.
It certainly wouldn't be Facebook's only dark pattern.
[ ] Foo
*Foo is disabled*
[X] Foo
*Foo is enabled*
I'm not a UI designer but I think this is pretty obvious to anyone that has used bad checkboxes (like OP). (I don't think the problem is unique to slide toggles; I've definitely seen similarly bad checkboxes.)
Hmm, I'd like it if that always made sense, but sometimes the default state, with nothing active, is for Foo to be on. So "Disable Foo" is doing something not normally required, or something most people don't want. Sometimes it does make sense that _not_ performing a reduction in Baz is default, and that default is off.
You could probably solve it by renaming a feature to used an antonym, but not everything has an antonym [that people know, or that makes sense].
The language even for discussing this is tiring to read…
This is quite common in UIs. It also has the benefit of working for all controls, not just checkboxes.
Then foo will be checked on by default. That's not a problem.
[X] Send notifications
What I'd like to see with every option like that is something showing whether it is in default state or not so user can easily glance what was changed from default. "reset to defaults" per page of settings is also appreciated.
I personally prefer a balloon that says "x is on" that appears when you toggle the switch.
the people who think the button should show what state it is in.
and the people who think the button should show what state it will change to when activated.
It says what it is, and the toggle says if it's on or off.
The toggle is just a visual, it can be tapped just like a checkbox.
Should this show the state or the action?
This gets messiest imo when it's a toggleable button like thing, or an unclear link. Buttons seem good candidates for "trigger an action", checkboxes instead suit "this is the state".
"Flubber enabled" [toggle ON]
"Flubber disabled" [toggle OFF]
The toggle being off means it looks like "Flubber disabled: off" or "Flubber disabled: no" but it means "Flubber disabled: yes"
Flubber disabled [ ] <-- Does that mean that flubber is not disabled ?
Never touch the label, and never tell state outside of the checkbox:
Flubber [X] <-- Clearly, flubber is enabled.
Flubber [ ] <-- Obviously, there's no flubber.
Enable Flubber [X]
But not when labeled
Flubber Enabled [X]?
To me there problem here is understanding if the toggle is displaying a state or action because English is limited. But in the past tense version that is far less confusing because it clearly expresses that this is a state and cannot be an action (i.e. "Would you like to Flubber Enabled?" doesn't work nor does "Would you like to Enabled Flubber?" but "Would you like to Enable Flubber?" does). The "ed" matters as well as the word positions. The reason being is that the second word describes the state of the first which is why you can change it. In your example it is easy to understand with the checkbox but the thread at hand is about how toggle switches' visual appearance is confusing so your example is clearly not obvious (otherwise this thread wouldn't be on the front page). The idea of toggling the label means that there are now two indicators of __state__ that should verify one another and thus reduce confusion.
It is common in telling someone how to use a UX that they need to "disable" X or Y option, but, again, that is to say that the intended state is on or off.
"UnFlubberize:disabled [__O] enabled"
The ARIA guidelines for switches even have a big warning about not doing this[1].
On a similar note, I find it hard when I don't know if I need to save or submit.
However when I make textual change and there's no save button I'm still confused.
There's no standard how to indicate imediate change in textbox.
I think it's a good design that tell users your changes are persisted "now" ?
And this can be probably applied to all options that take effects instantly.
Another idea:
When you start typing textarea visually changes style to indicate editing. Once you leave it it changes style back to indicate that this new content is written.
Optionally additionally while editing small X icon might show up and clicking it might cancel the change instead of saving it.
Fnurbification disabled
O
|
Fnurbification enabled
Fnurbification enabled
|
O
Fnurbification disabled
This really depends on the part of the world you are living in.
When I was living in Central Europe the light switches were on when they were in the up position.
Edit: Even all my Canadian switches are like this. Up is on.
Especially annoying are the posh toggles, unnecessarily popular in some European countries (e.g. CH) that don’t have any physical indicator of on-off status.
Off: https://media.istockphoto.com/photos/light-switch-in-off-pos...
Also off: https://upload.wikimedia.org/wikipedia/commons/thumb/6/65/Ro...
Unless you mean this kind that offer either way: https://m.media-amazon.com/images/I/71BTb1oUUYS.jpg
(B) The standard three way* switch would like a word.
* Which actually means two switches (or more).
FNURB
NORM c- ALTN
FNURB
[ ] < normally blank
[ ] < shows ALTN when selectedI think it's also worth noting that it is usually very obvious what state a media player is in, so it makes sense we would have different expectations from that UI vs one where we aren't sure of the current state.
It was easier to have "stop" be mechanics to disengage head, "play" to engage head" and "pause" being just on/off switch for the motor than trying to merge play/pause into 1.
> Most of us were trained to expect that before contemporary media players started showing up.
CD players started getting play/pause precisely because they didn't need to. Most VCRs also had digital controls (coz moving mechanisms via push of button would be harder with big tapes and heads) and they also did often have play/pause integrated.
Some opted for copying tape 1:1, some merged play/pause into one button, it certainly wasnt that all of them had separate pause.
Anecdotally (in UK&EU) every old tape, CD, or VCR player I ever had combined play and pause on a single button, even devices where there was no screen to show current state it was just the norm that the same button toggles the current state.
Except when it isn't playing. It get confusing/frustrating when dealing with low volume, buggy software like the Iphone Podcasts app or Bluetooth. Then you think, oh, maybe it's in a paused state.
A media player can be in the "user wants to play" state and not be playing, because buffering is taking place. This is a very common state, yet all the media players I've seen have an ambiguous or confusing display during this state.
Non-default state should also be indicated
> and the people who think the [checkbox/toggle] should show what state it will change to when activated
These people are wrong. The simplest thing should be the default and this adds extra indirection (projecting future state from current state), therefore it's not the simplest, therefore it's wrong.
Unless of course you mean something strange by "activated".
With toggles, I'd almost rather see them aligned center with explicit state description to either side.
Three, apparently: there are the people (such as me) who think the button should "show" what it does when you click it. It shouldn't indicate anything else (except it's enabled/disabled state, i.e. whether you are allowed to click it). Button text should be constant. If you need an indicator, that should be another widget.
The less cynical take is that you only ever interact with privacy controls when they’re wrong, and the subset of those which are confusing are the most salient.
I realized the same pattern but in reverse in my phone provider's app. When you're making a payment with your credit/debit card, there is a toggle that you can turn on for them to tokenize your card. By default, the toggle is to the left side and it's colored light blue. When you toggle it to the right it become gray. I believe they have done it on purpose to confuse prople who don't want their card tokenized.
a) don't save CC info at all
b) save CC info in tokenized form (whatever that means)
And since I never save CC info on websites (only in the phone wallet feature) I've always rejected these "tokenized" prompts. But it seems I need to research this thing more next time.
> a) don't save CC info at all
> b) save CC info in tokenized form (whatever that means)
> And since I never save CC info on websites (only in the phone wallet feature) I've always rejected these "tokenized" prompts. But it seems I need to research this thing more next time.
Tokenization means that the payment processor saves your cc information for "easier" use when you make purchases/pay bills in the future. The seller/service provider can of course use that token to charge you anytime they want. I hope this helps with understanding how it works(and why I am hesitant to allow tokenization of my cards).
In the old, default browser UI, buttons had black labels when enabled, and grey ones when disabled.
Then web designers started making button widgets that looked "cooler" than button elements. Then they realized that they could use the new "buttons" to make indicators as well; so they repurposed the enabled/disabled idiom to mean instead "on/off" or "yes/no". So now the idiom is ambiguous.
If you want a dual-purpose button/indicator, emulate those old keyboards that had an on/off neon in the CAPS-lock key. I prefer a separate indicator, but at least those old CAPS-locks were ergonomically unambiguous.
Or conveniently defaulted the way you want them, but with wording and other visual clues twisted in such a way to make you question that and maybe accidentally opt in.
[ ] fnurbification
[x] fnurbification
[*enabled* | disabled] fnurbification
[enabled | *disabled*] fnurbification
[X] perform deconbinaturation
[X] disable fnurbification
[X] enable entrapollation
Aiming for all options to be "on" or "off" is some pedantic nightmare that makes settings harder to navigate
This probably stems from config files or in-app defaults where a feature is default-on and so the existence of a value means something is disabled. And then some dev comes along and mindlessly transcribes a bunch of boolean flags into a settings menu and here we are.
( ) enable fnurbification
(o) disable fnurbificationThere is no way of knowing for certain what position is on and what is off without assuming that the first displayed state is on.
I believe recently I setup a nest with this issue. There is no way of knowing what is specifically selected unless there are three options. With three exclusive options you can compare to determine what the current state is because two of them will look the same thus must be off.
Ti-89 93... calculator settings can have this issue but some of the options have 3+ states and once you see the schema it's quite easy to deal with.
On Fallout 76's "PIP Boy" UI, button tips for things that toggle or rotate settings like "(X) Allow Friends Only" arbitrarily mix states and actions, in the same UI!
That particular option is on the Private World creator and the only way to figure out which it is is to create a world and see who can join. There are many such examples with several buttons/action/states listed where some work one way and others the other. It's so bananas it's almost endearing.
The tape recorders, vcr and dvd players I've seen mostly have them on two different buttons: pause which stops the current recording or playback and separate play and record buttons. There is nothing confusing to PLAY / RECORD / STOP.
Although I guess sometimes you have a joint pause play button especially on tv remotes and those ARE confusing.
ETA: apparently HN doesn't like the pause button emoji so i had to use text.
HN doesn't like ANY emojis.
Here's a smiling face, crying face, and elephant:
You'll have to take my word for it that I actually put them in my comment.
fnurbification [X]
For example:
vSync ==> [On]
vSync [Off] <==
For the negative labeling, it’s of course unfortunate. But it’s in general the case for all negation. Thus, I try to avoid using negation when ever possible.
3) You see a toggle switch. It is labeled “Fnurbification”. It is set to “off”.
You want fnurbification. Do you flip the switch?
As we’ve established in 1 & 2 if you know that flipping the switch won’t change the label then clearly the label describes the thing so you should flip it.
If on the other hand flipping the switch is going to change the label then we’ve established that the label probably describes the current state. Flipping it would probably change the label to something like “Disable Fnurbification” and turn it off. So you should leave it off so fnurbification remains on.
But this is your first time using this app. How do you know whether or not the label is going to change? You could toggle the switch, but what happens if the action of toggling the switch is expensive or safety-critical?
4) Let’s raise the stakes. You see a switch. It is set to off. It says “Nuclear reactor safety protocol”. You want a safe nuclear reactor don’t you? Do you switch on or leave it off?
Fnurbification [ON|off]
Fnurbification [X]
Checkbox is fine, toggle switch is also fine as meaning is clear in both cases.
Every other solution should lead to whoever responsible for it being fired
if disable_foo:
...
if not enable_foo:
...Actually, that should be:
[x] Fnurbification[x] bla
[ ] this is a very long label
[ ] lorem ipsum
For RTL languages, everything is simply mirrored though: https://learn.microsoft.com/en-us/globalization/localizabili... It doesn’t change the general argument.
The fixed-width nature of these elements is more of an afterthought that emerges because neat grids make information easier to parse and are generally considered to be visually pleasing. In RTL languages, the movement of the eye is mirrored, so the natural position of these elements also gets mirrored to the right-hand side. Of course, the fixed-width nature does not change because the instinct to craft neat grids exists regardless of directionality.
Recently, however, we have begun to see certain touch-based interfaces adopt right-aligned controls specifically, even in LTR configurations. This evolved to compensate for the fact that most people are right-handed and generally cannot reach across the width of a modern touchscreen one-handed. It's effectively a concession to accessibility and is best implemented as a toggleable feature to avoid disadvantaging left-handed users.
Buttons and toggles along the right margin and text on the left works for me. I prefer to read first what I'm turning on or off.
A designer that I once worked with came up with a terrific toggle switch, really the only one that works as well as the simple checkbox in my opinion:
https://ux.stackexchange.com/questions/1318/should-a-toggle-...
You are supposed to design your UI as if it was made in ten minutes by a lazy high schooler making a powerpoint with all the defaults and just bulleted text on a blank background.
Knowing how it ended is killing me, quick question, at the end did you got fnurbificated or not?
In the settings drop down was a greyed out button with a volume icon and the text "Mute". Does clicking that enable the mute setting?
Turns out that just means it is muted. Checking the button made it update the text to "Sound". Such an awful design IMO.
It wouldn't be so bad if it was
Mute <slider> Sound
But that takes up far too much UI space in the settings dropdown intended for quick actions
The problem is that a lot of websites have started using them and only implement the click/tap event, not the mouse press and move event, or the slide event. So they end up being quite misleading.
https://i5.walmartimages.com/asr/5cd445f6-b24c-4e39-8c10-0a0...
Consumer electronics had dip switches behind precisely the graphical design Apple introduced for these toggles.
Some of the early skeuomorphic designs (this is not Apple, nor early, just illustrative) made this more obvious:
https://cdn.dribbble.com/users/291697/screenshots/1027928/on...
Another common implementation looks like a two or more position slider, but still not a latch:
https://alphauniverse.media.zestyio.com/gmaster-sel85f14gm-l...
https://octopart.com/electronic-parts/electromechanical/swit...
You can buy single DIP switches in parts catalogs:
https://i.imgur.com/isfVR18.jpg
https://www.mouser.com/ProductDetail/CUI-Devices/DS01-254-L-...
I thought 'everybodyknows' that. ;-)
Huh? On the iPhone you've always been able to slide it.
I blame this on all the other implementation which copied the switch design, but didn't bother to implement sliding…
Absence of verb in label makes it clear what it is.
Meanwhile, on Kindle, it shows a black airplane in a white circle labeled "Off" and a white airplane in a black circle labeled "On". This is a recent update from before where the first was an airplane with a slash through it for Off. In both cases, Cell/WiFi is on when labeled Off, network+radios are on when icon was airplane with a slash through it labeled off.
It's likely a strange bug, but I think it's relevant since you can't _always_ slide it.
Airplane mode used to take a a couple seconds to enable so the toggle felt “stickier” to toggle. When you tapped on the toggle, the round button elongated and stayed in the middle for a split second before hitting the right side boundary of the toggle.
Also, the sliding only works correctly if you press and hold and then start sliding. If you swipe, it toggles regardless of which direction you swipe.
Maybe this is the relevant line of the crash log: Object Gio.DBusProxy (0x55e4d0f30a90), has been already deallocated
I think this is true, since I get Gnome crashes in the bluetooth settings and nowhere else.
The real annoyance, though, is that pressing cancel/off does absolutely nothing if the microwave is being used as a timer (without the microwave itself running). When the timer beeps, my first thought is to press cancel/off. Then press it again a few times, because it's still beeping. Then I remember that there's a dedicated button (somewhere in the middle of the panel, labeled with small text) to cancel the timer.
Something about desktops that never get complaints vs desktops that people actually use.
After a few years of Windows, this week I installed Ubuntu again, and it's full of crazy bugs. Though no crashes yet! So at least they improved on that a lot.
Applied to a client/server web application, I would expect a toggle to immediately cause a request to the backend. I’d expect a checkbox to be used in a form which is sent as a whole on submit.
It's cultural but this has nothing to do with Windows, Linux, and iOS. You flip a switch, the light comes on immediately. This is about the immediacy of switches, not iOS devices.
Historically (90's, early 00's) in Windows, which had 95% of market share, almost any settings screen would only apply the settings you changed after you pressed the "Apply" button (apply the settings and stay in the screen) or "Save" (apply the settings and close the screen).
I'm not sure how Mac OS X fared in that regard. But, for some older people, "click an option and it's immediately active" is not how it was in the past.
Almost no macOS screens have ever worked like that. Their interface guidelines have always recommended against it.
> ...all changes that a user enters in a dialog box should appear to take effect immediately whenever possible. — macOS 9 guidelines: http://interface.free.fr/Archives/Apple_HIGuidelines.pdf
Following Apple’s sensibilities will get you both toggle switches and instant changes, though I’m not sure there's a connection within any single interface.
you may not like it but this is what peak UX looks like
Control Panel was unique in settings applying immediately. Pretty much every app's preferences (or other settings) were a modal dialog with OK/Cancel, however.
So it was a step forwards when iOS's Settings app changed from checkboxes to toggles, because this reflected the immediate change. And now with Ventura, macOS has finally caught up as well.
Timing may also be a problem. Settings might affect each other, or you may want to change a bunch of settings so that they all happen at once. You can also run into problems where you want to flip setting A from on to off and flip setting B from off to on, but they can't both be off or both be on at the same time.
My biggest annoyance though is that I have decades of doing it one way, and now it's flipped. Automatic saving on Microsoft Word when you're editing a file on OneDrive still annoys me. No longer can I take an older copy of something, change a few things, and save it as a new document. I've just managed to mangle the original document through sheer muscle memory (from five minutes ago when I did the same thing in the same copy of word to a document on my disk drive).
https://www.allelectronics.com/item/pb-173/spdt-on/off-pushb...
But it's taken some time for UX paradigms to coalesce around this -- simply because checkboxes used to be used for both, until Apple "invented" toggles for instantly-applied settings in iOS.
Now that Apple finally implemented toggles in System Settings in macOS Ventura, the paradigm is largely consistent in desktop software on Macs. Toggles apply a setting instantly, while checkboxes are used within an "OK/Cancel" dialog.
But I think because it's taken so long for toggles to "spread", a lot of users and developers have an instinctual understanding that toggle = instant, but haven't always been able to articulate it.
Broadly, these could be divided in implementations that offered a loading state (switch goes transparent until persisted, overlaid spinner etc.) and implementations that flicked the switch back when the request failed and provided a very noticeable status update (hint, animation, growl).
My preference for systems that work with unreliable persistence is the former, albeit that is purely personal and not founded in a deeper rationale.
I don't think there's much of a difference between a checkbox and a toggle if you size them right. Toggles are easier to size up to touch screen size so on touch screens they make sense. On desktop, in non-touch mode, the oversized control kind of irks me, though.
"On" versus "off" is always clear, but the question "did I set it correctly" depends on the phrasing of the checkbox labels. What does "FizzBuzz enabled when widgeting" being on or checked mean?
Design wise, I think generally the toggles are reserved for cases when you turn on a feature or service, and checkboxes just modify that feature's/service's behaviour. "VPN" is a toggle, but "auto-connect VPN" is a checkbox. "Accessibility" is a toggle, but "always overlay mouse cursor" is a checkbox.
On touch screens the bigger toggle buttons make more sense so I think on Android/iOS you'll always see them in the place of a checkbox.
Oh wow. I've never thought about this before but that is very intuitive.
Toggles have a physical, analog equivalent, like a switch or lever. Checkboxes don't really map to meatspace; they're strictly a logical construct.
Makes sense that toggles do big changes and checkboxes tweak.
Admittedly not as physical as buttons, but they were designed as a copy of an existing thing.
On the other hand, a toggle switch (like a light switch) has an immediate effect.
Apple ones also light up green (or dark background) when "on" and grey (or light background) when "off" - which seems pretty clear to me.
Green is fine now, because I'm fortunately not red-green colourblind.
I still believe that checkboxes are the better control, because they can be toggled with a single click/tap without having the conceptual disconnect that a physical sliding toggle implies that you would need to drag it across, and because the checkbox state is visually unambiguous regardless of coloring (and 1/0 labelling).
With checkboxes, there is also the general convention that clicking on the label (and anywhere between the checkbox and the label) toggles the checkbox, meaning a larger click target (this is one thing that <label for=…> achieves in HTML, by the way), whereas for sliding toggles this is not a common convention, making them less convenient to use with a pointing device.
Another benefit of checkboxes is that the label is always directly adjacent to the checkbox, meaning you don’t need any extra visual aids (horizontal lines, more vertical whitespace) to prevent confusion about which control goes with which label, which can be an issue when there’s a lot of horizontal whitespace between label and control in a list of controls.
Does it though? What about a checkbox makes it NEED to be on the left?
Also compare with todo lists (todo apps), or selecting items from a listing. The check control is always on the left. For example in iOS Mail: https://support.apple.com/en-us/HT208661 Or checklists in iOS Notes: https://support.apple.com/en-us/HT209365
Furthermore, checkboxes can have subordinate controls, like in this example: https://learn.microsoft.com/en-us/windows/win32/uxguide/imag...
Having the checkbox at the beginning of what is enabled/disabled just makes sense, similar to how in an `if` statement you have the condition at the beginning instead of at the end.
If checkboxes are on the right, they are either far away from the text or (I shudder to imagine) horizontally misaligned.
As someone else in this thread mentioned, checkboxes are more of yes or no, and usually have a save button to confirm the setting. Whereas toggles are meant to be on or off with immediate effect.
It's so frustrating to have to spend so much time and energy arguing this. I've even worked at a place where an entire feature of yes/no settings to which the user must agree was named "toggles" because of all the toggles in that flow, even though they're supposed to be checkboxes.
The old adage of no one ever got fired for buying IBM could be replaced by no one ever got fired for copying Apple. It's hard pushing back against that kind of momentum
They don't, though.
This is an incredible source of frustration - and one that comes up often. As a native speaker of multiple languages, I always pause and do a double-take in order to actually "see" the language, given that I usually don't notice.
Worse is the labeling. When something says "On" it's not clear whether you mean it is on, or the button turns it on. As far as I'm concerned there is no correct choice, because it's not fully unambiguous.
The aesthetics, however, are pretty great, there's a reason designers don't seem to like checkboxes. Checkboxes feel kinda odd. On paper they are used to denote membership in a set more than general boolean status.
When the question is a boolean, like "Did you feel sad today?" there's usually one box for yes and one for no.
The aesthetics are good enough I'd say it's even worth adding an unambiguous state indicator like (Disabled) to clear the doubt.
But, radio buttons with separate on/off boxes can also be very familiar and aesthetic, and I'd probably go with those more often.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.
Douglas Adams
Which is to say, Douglas Adams might need to adjust the time window in #2 a bit.
Like when car manufacturers decided that knobs are bad and on top of people hating it it was proved to cause more distractions to the drivers
https://www.vibilagare.se/english/physical-buttons-outperfor...
Part of that is trying to have "one size fits all", why waste time perfecting design for multiple cases where you can just shove touch screen oriented design to desktop OS and "just" waste some space ?
It reminds me of when I see old photos and everyone is dressed up so much more nicely than today. And people either respond with "akshually hoodies are just as nice as pin stripe suits" (come on, you know they're not) or "oh what you want to go back to leaded petrol and no personal computers and smoking everywhere and drink driving?" (no, just the clothes).
Nuance people, jeez. You can pick and choose things in the past that were better or weren't.
Toggles, switches and checkboxes are all components used to switch between states, often on or off, but not always (in toggles you can also have multiple states)
UI and UX studies suggest how they would be best used to aid readability
A toggle switch is best used for actions or options that have an immediate effect on the user interface and do not have to be confirmed or reviewed. A checkbox is more suitable when there are further changes, are within a form or need to be revised before continuing.
When designing forms, it is important to focus on the context of use rather than the function of the controls...
I recommend watching this video https://www.youtube.com/watch?v=wFWbdxicvK0 This research shows six different ways of using the mobile phone screen to control devices with only two states (on/off). There are buttons, sliders and rockers. The ways that require sliding are safer because they avoid problems caused by accidental touches. For this reason, the iPhone uses a slider to unlock the phone
Really, the only thing I can think of that clearly indicates the state of these buttons is the ⏽ vs ⭘ distinction because those glyphs have been made specifically for this purpose.
Off ( ▢) On
(⏽▢)
(⭘▢)Checkbox's in the real world are used more in confirmation, or a yes/no pattern. In the real world you can check a checkbox if it applies, but you don't uncheck a checkbox when something doesn't apply. You also don't expect some state change to occur from merely checking a checkbox.
Checkboxes are still used everywhere they make sense. "I accept these T&Cs" for example would almost certainly use a checkbox, not a slider for the reasons I mentioned.
For on / off patterns though checkboxes are less intuitive. When you slide a physical toggle switch in the real world you're typically switching a device from one state to another state - and you typically have the ability to switch back and forth. Checkboxes are not used in this way in the real world so it's less intuitive to use them like this in digital UIs.
I don't think the issue you have with sliders is universal. If you design a slider well it should be very clear what the state is. For on / off patterns changing the colour of the slider from green to red can provide a clear visual hint about the active state.
One downside is as you mentioned the confusion whether it is on or off (although nowadays most UIs make it double clear with color and some with additional text). But also because the switch is on the right hand side, it is further away from the text, and is visually inconsistent with radio boxes. And it is part of this "iOS settings" design language which itself is problematic, because it doesn't try to have specialized panes for each setting but crams everything into lists. (This is not the fault of the toggle, but how it is used.)
One point in defense of the toggle is maybe that it is not clear to everybody that you can usually click the text on a checkbox, making the click target rather small. But you generally can't click the text on a toggle, so it is moot.
[ ] Add sauces to my food
[ ] Mayonnaise
[ ] Ketchup
[ ] XO Sauce
[v] Add sauces to my food
[v] Mayonnaise
[v] Ketchup
[v] XO Sauce
[-] Add sauces to my food
[ ] Mayonnaise
[v] Ketchup
[ ] XO Sauce Extra sauces (1 selected):
[ ] Mayonnaise
[v] Ketchup
[ ] XO Sauce
It does not matter with 3 options and 1 selected, but its nice if its 20 options and 7 random ones selected.
Toggles came along with iOS when the UI was skeumorphic ca. 2008. Don’t know whether it has to do with tech, but that’s when we first got those.
As far as actual evidence, I do UX testing of a touchscreen/cursor application and we have both scattered throughout. I haven’t ever seen anyone have any difficulty understanding, using or differentiating between either. In our results this simply isn’t a problem with investigating.
I'm not sure if this was meant as reassuring, but for me it only reinforces my view that UI/UX folks don't have a clue what they're doing.
I'm not saying that's a good reason, but it is a reason besides being newer.
There seems to be some logic behind it though: Toggles are often used alone to switch things on/off (for instance Wifi or Bluetooth), while checkboxes are often used in groups for "less important things". But maybe I'm just imagining that there's an actual reason behind it ;)
Switches
--------
Avoid using a switch to control a single detail or a minor setting. A switch has more visual weight than a checkbox, so it looks better when it controls more functionality than a checkbox typically does. For example, you might use a switch to let people turn on or off a group of settings, instead of just one setting.
In general, don't replace a checkbox with a switch. If you're already using a checkbox in your interface, it's probably best to keep using it.
Checkboxes
----------
A checkbox is a small square button that’s empty when the button is off, contains a checkmark when the button is on, and can contain a dash when the button’s state is mixed. Unless a checkbox appears in a checklist, a descriptive label follows the button.
Use a checkbox instead of a switch if you need to present a hierarchy of settings. The visual style of checkboxes helps them align well and communicate grouping. By using alignment — generally along the leading edge of the checkboxes — and indentation, you can show dependencies, such as when the state of a checkbox governs the state of subordinate checkboxes.
Someone tell Apple's Settings team
Red Dwarf - The Cat - That be mine!
https://www.youtube.com/watch?v=Q54lVO7elt0
How Apple Is Giving Design A Bad Name (2015)
https://www.fastcompany.com/3053406/how-apple-is-giving-desi...
A history of Apple HIG table of contents – the philosophy and principles
https://modelessdesign.com/backdrop/401
Rediscovering Apple’s Human Interface Guidelines from 1987: UX Lessons from the Dawn of the Personal Computer
https://blog.prototypr.io/rediscovering-apples-human-interfa...
(Narrator: it never does)
When a toggle switch is 'off', it still looks like a toggle switch.
When a checkbox is 'off', it's a square.
Choose language [English]
Run in background X
Development mode v
Nested menus (like ingredient lists) have a third state, yellow "~", which indicates some sub-items are ticked and some are not.
It ticks all my boxes (pun intended) for good UX: unambiguous what the current state is, indicates state in multiple modalities, the label key/value reads left to right, keys are values are all justified nicely.
The only slightly bad thing is red/green color blindness and non-universal association of color semantics. But since it's symbol plus color, it's still unambiguous.
This is called "indeterminate" state [0] and is part of the HTML checkbox spec
[0] https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl...
For example:
The label [ *] On
I cannot recall seeing any of them with such an extra text.
Is the disappearance of the additional "On/Off" label perhaps another trend layered on top of the toggle switch trend?
Enable the label [O @]
Light [* ] Dark
But most implementations don’t do that. And I can understand why, because the following…
Show Notifications Yes [* ] No
they have much less usability
what stinks about them is you can never quite figure out or remember if you're supposed to just tap, only tap on the "other end", or actually slide the slider.
There are physical things that are difficult to operate irl, and there's no reason to skeuomorph difficult things to use.
but even better, what's wrong with letting me choose what I want? You can have whatever UI you like, it doesn't need to affect me. That's the whole idea behind a personal computer, it's my slave, it's my servant, it does what I want, to make my life the way I want it. Software is the first human technology to offer this promise, it's only the weak of mind, ego and will who see it as a way to impose their stunted vision on other people.
You don't have to "grab" slider controls; if you just click anywhere in their display area to toggle them.
E.g. try an example here: https://www.w3schools.com/howto/howto_css_switch.asp
The sliding is just an animation sequence which replaces the appearance/disappearance of the checkbox with alternative images. In the above example, you in fact cannot grab anything and slide it left to right. All you can do is click.
If you're confronted with some UI in which you have to actually pull a slider left or right and cannot just click on it, complain to the vendor.
A device with a proprietary OS is now not really yours. It's something that you depend on for access to essential services and which you got for a deeply discounted price in exchange for giving up control, personal information, privacy and access to your eyes and ears by advertisers.
I like the "positive description: [ ]" pattern.
Ghosts can breathe fire [ ]
Radians are better [X]
There's no doubt what the state is.
- which way means "on" (because the UI element isn't clear)
- whether "on" means "no cookies" or "actually I would like the cookies after all" (because the label is poorly worded)
Checkboxes were primarily designed for questions where a user wants to choose a subset of related options for the same topic. (e.g. Which colors are acceptable to you? Red yes/no, Blue yes/no, Green yes/no)
The toggle switch connotes an A/B answer to a single question. (e.g. Dark theme? yes/no)
Going back to toggle switches, the look of the switch when it's on is symmetrical and nearly identical to when it's off, barring a rotational transformation and sometimes a subtle color difference. Checkboxes on the other hand look very different when on or off. I think one guiding principle for UI should be that different states of the UI should look significantly different from each other. In the case of toggle switches, the difference is just not significant enough.
Is it possible it's really all just what we're used to?
The controller has ○ and × buttons, and in Japan "×" can mean no/incorrect and "○" can mean yes/correct, so in the menus you press ○ to confirm and × to deny.
When they localized it for the west, they flipped the meaning so that × means yes as in "check the box" and ○ means no as in "zero" (like on a power switch with 1 and 0)
So when you play games from another region, what controls you use in menus changes.
As a native US citizen I wouldn't have even considered that to be nonstandard.
Your "know right side is on" made me think of it.
I don't debate your point as a whole, but not everything may be the same way worldwide you think it is.
They're antiskeumorphic. The design actively sabotages user understanding.
But then you also have the designers that like to make things pretty, rather than give you any hint that some text is in fact clickable.
Younger people are less familiar with check boxes, so the best real world analogy is light switches. They are also expecting changes to happen instantly.
The only analogy I can think of is the physical slider built into some smartphones for sound on/off. I don't think toggle sliders are common at all these days.
I get that people fill out paper forms less than they used to, but give the younger generation some credit here. It's not like we live in a Star Trek future world where paper is an antique curiosity. It's still alive and well in schools, for example, lockdowns notwithstanding. I'm 100% sure they still know how to tick a box, be it by pen or by mouseclick or tapping a touchscreen.
For my part, I only recently learned that "radio buttons" were named after an actual kind of button that existed on old fashioned radios. I never encountered such radios as a kid, but I had no trouble at all using radio buttons in computer UIs.
There are only so many ways to make a button.
When enabled, created nurbs are automatically converted into fluffy nurbs.
Like, if it's used to expose an additional menu option, for example. That stutter of waiting breaks the flow.
(I only get paid for [marketing] cool; not coding correctly [that's a client support problem])
do users not intuit checkbox button? is this some problem being solved or more of fad?
Probably a button that stays depressed and "lights up" when touched would be more similar to a checkbox. Touch again to uncheck and it will go undepressed.
It allows sites to reap the benefits of some confused incorrect settings while being in full compliance with EU regulations.
https://www.youtube.com/watch?v=wFWbdxicvK0
This early research at the Human-Computer Interaction Lab shows six different touchscreen based toggle switches allowing the control of two state devices. The user interfaces, ranging from button to sliders and rocker. The designs that require a sliding motion are safer to use when inadvertent change cause problems (which explains why devices such as the iPhone use a slider to unlock the phone). For more information see http://www.cs.umd.edu/hcil/touchscreens
Don Hopkins and pie menus in ~ Spring 1989 on a Sun Workstation, running the NEWS operating system.
https://www.youtube.com/watch?v=8Fne3j7cWzg
After an 1991 intro by Ben Shneiderman we see the older 1989 demo by Don Hopkins showing many examples of pie menus on a Sun Workstation, running the NEWS operating system. This is work done at the Human-Computer Interaction Lab at the University of Maryland.
A pie menu is a menu technique where the items are placed along the circumference of a circle at equal radial distance from the center. Several examples are demonstrated on a Sun running NeWS window system, including the use of pie menus and gestures for window management, the simultaneous entry of 2 arguments (by using angle and distance from the center), scrollable pie menus, precision pie menus, etc. We can see that gestures were possible (with what Don call "mouse ahead" ) so you could make menu selections without even displaying the menu. Don uses an artifact he calls "mousee" so we can see what he is doing but that extra display was only used for the video, i.e. as a user you could make selections with gestures without the menu ever appearing, but the description of those more advanced features was never published.
Pretty advance for 1989... i.e. life before the Web, when mice were just starting to spread, and you could graduate from the CS department without ever even using one.
This video was published in the 1991 HCIL video but the demo itself - and recording of the video - dates back to 1989 at least, as pictures appear in the handout of the May 1989 HCIL annual Open House.
The original Pie Menu paper is Callahan, J., Hopkins, D., Weiser, M., Shneiderman, B., An empirical comparison of pie vs. linear menus Proc. ACM CHI '88 (Washington, DC) 95-100. Also Sparks of Innovation in Human-Computer Interaction, Shneiderman, B., Ed., Ablex (June 1993) 79-88. A later paper mentions some of the more advanced features in an history of the HyperTies system: Shneiderman, B., Plaisant, C., Botafogo, R., Hopkins, D., Weiland, W., Designing to facilitate browsing: a look back at the Hyperties work station browser Hypermedia, vol. 3, 2 (1991)101-117.
PS: For another fun historic video showing very early embedded graphical links (may be the 1st such link) + revealing all the links/menu items + gestures for page navigation
HCIL Demo - HyperTIES Browsing
https://www.youtube.com/watch?v=fZi4gUjaGAM
Demo of NeWS based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab.