Why are toggle switches replacing checkboxes? Isn't on/off less obvious?

My pet peeve is the labeling of these things.

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.

This is kind of embarrassing to admit, but I couldn’t figure out how to change the state of a toggle switch for a really long time. I kept trying to slide the switch left or right. Sometimes it worked, but often it didn’t. It wasn’t until I had been using an iPhone for a couple years that I discovered you’re just supposed to press it, not slide it. What a stupid design.

To me, the semantic difference between the two is that I expect a toggle to cause an immediate effect whereas a checkbox merely holds the value to be applied later.

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.

Apple used sliding checkboxes. Then everyone copied Apple. It's an annoying industry trend but in terms of clarity I don't think it matters at all in this case. For a while people also used push buttons with "lights" indicating on/off but those have been phased out almost entirely now.

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.

I think the trend started with iPhone. Probably due to a combination of skeuomorphic design and needing a control that was easier to activate using touch. See this page for Apple’s guidance on when to use toggle vs checkbox: https://developer.apple.com/design/human-interface-guideline...

I suspect one reason why toggle switches became widespread, aside from touch interface cargo-culting, is that in contexts like the iOS Settings app, they can fit the pattern of label-on-the-left, control-on-the-right, whereas checkboxes (and radio buttons) need to be on the left of the label, unlike other controls. (Or on the right for RTL languages, I suppose.) Checkboxes can thus require a little more consideration in how to layout a dialog.

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

I'm glad that you know the right is on.. but I don't. I live in a country with a right to left language system. Things locally, done in the local language are right side is off. Things internationally behave the way you've mentioned. Checkboxes are infinitely better, because they're not language dependent.

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.

I often get left and right confused, so I'm not really a fan of using left/right as code. It takes maybe 2 seconds max to think about it, but it's annoying.

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.

Because everything just gets worse as you age. Sure, my dad said it too back then, but they just didn't get how the world moved on and improved. This time around though it's real, everything gets more stupid and dumb and I hate it.

In the 90s I used 3 different desktop OSes where the UI followed a style guide, and that style guide evolved gradually over years, allowing you to glance at a control and be familiar with its possibilities. Now even on one device, the user sees 10 kinds of different controls and new ones that are thrown at them all the time. The problem is surely that you can't rely on the user _recognising_ the control you've built. You have to design as if every user might be parsing it for the first time.

The choice of using a toggle switch or a checkbox depends on the context.

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

I don't get it either. I never know which side is on and/or which background color means on, unless they're using green/red. You say "right side is on", but I never even realized this until now.

Good UX patterns are generally those which are recognisable and intuitive to the user.

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.

Honestly, I think it is just a trend. It started with the iOS settings UI, everybody copied it and is still copying it almost 15 years later. Look at the settings in Windows, Android, macOS (Ventura), Gnome. List/Detail view, and the detail pane is itself a list of mostly switches.

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.

One thing that you lose if you replace checkboxes with toggle switches, at least on webpages, is the third 'indeterminate' state that JavaScript offers. https://css-tricks.com/indeterminate-checkboxes/

Checkboxes come from older mouse/cursor UI’s, toggles come from newer touchscreen UI’s.

I mostly agree, but just to be the devil's advocate:

When a toggle switch is 'off', it still looks like a toggle switch.

When a checkbox is 'off', it's a square.

Rimworld nails the best UX: Boolean settings are expressed like:

    Choose language      [English]
    Run in background    X
    Development mode     v

"v" indicates a check mark; HN won't render that symbol. The labels are left-justified and the toggles are left-justified in a column next to it, along with drop-downs. The X's are red and v's are green. Clicking X/v toggles state. The label is usually positive valence, but some are negative. "Disable tiny font" and "Disable game-specific cursor" are the only negatively worded toggles I could find.

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.

I'm not a fan of toggles, but they might be better because they usually have an extra text saying "On" or "Enabled" in addition to the label.

For example:

    The label  [  *] On

A checkbox with a good label [1] is fine, and it's better in the sense that it has a third state (for indeterminate).

[1] https://blog.uidrafter.com/guidelines-for-checkboxes

the left-right slidey things were an Apple affectation, no doubt introduced just to be different, after all, Apples were for the rest of us. We're different.

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.

You see them used because they are skeumorphic, and there is a general trend in user interfaces to go skeumorphic across successive generations.

The ones I hate the most is the ones that also change the label, because both description and indicator changes, it's just confuzing..

I like the "positive description: [ ]" pattern.

Ghosts can breathe fire [ ]

Radians are better [X]

There's no doubt what the state is.

Touch requires a bigger target area and big checkboxes look terrible.

You're not going crazy. I think it's revealing that these elements are common in the cookie consent forms, where if don't click the big green "I give up, give me all your cookies" button you have to try to understand:

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

I think toggle switch has a different connotation from checkboxes.

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)

As to the "why", it's probably because some influential program or OS's UI started using toggle switches and then a lot of UI designers felt a need to follow along. It's unfortunate that bad UI designs are so contagious. (Some of my own pet peeves are skinny scrollbars on desktop apps and the fixation on making whitespace-infested UI that has no borders between different sections of the UI.)

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.

I think it's because of a shift to mobile and setting screens that autosave. Using on/off switched is a common convention on mobile operating systems like iOS. When you are setting up something without hitting apply, the sense of activating a switch seems more like committing to the change compared to the checkbox.

I agree with the poster 100%. In so many UIs it is literally impossible to guess what drawing represents on and which represents off. Toggles, and even multi-toggles until there are at least 3 states are unreadable. It isn't even "just avoid skeuomorphism", it is just awfulness.

And I don't know that either really handle the null case all that well, i.e. if the value isn't set at all. In that case, does it default to on/checked? or off/unchecked? They almost need a hover-over or message that pops up to tell you the current state.

When I was much younger, I had trouble understanding checkboxes - in particular the ones with an X in them because at the time I thought X means no. So I would assume checkboxes with an X meant that you were deselecting them.

Is it possible it's really all just what we're used to?

Because UX "design" is often not about design but about cargo culting the latest trends.

Interesting; I found a youtube video yesterday of a guy doing the "things that are weird in the US as a foreigner", and one of them is that where he is from, light switches are "up is off, down is on" evidently because he found the US "up-on, down-off" behavior odd.

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.

I'm convinced they're bad UI based on how I've seen my parents try to use them on touch devices. They try to slide them horizontally, not realizing you're just meant to tap them. And the slide motion ends up doing something to the page or menu they're part of. At best it's a no-op, at worst the slide causes a transition to a different screen and they get confused.

They're antiskeumorphic. The design actively sabotages user understanding.

They are only used in places where confusion benefits the user. It has to be deliberate so people accidentally opt in. I've assumed it's a dark pattern.

One advantage is that you can have a neutral state (in the middle), forcing the user to choose one way or the other. You can't do that with a checkbox.

It provides a bigger target for your fingers to hit on mobile. So if your design calls for people using small screens it generally is an improvement.

I assume it's part of the 'make everything usable on a phone' thing, regardless of whether you are actually using a phone, so the thing that only contains a half screen of information is now spread over 4 screens.

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.

Exactly. The first time I've seen those sliding switches I didn't get how to operate them. And some are even colored in a very unintuitive way. And after years on the market, as a bonus, you CANNOT actually drag them! CLICK or TAP to SLIDE. This is ridiculous!

After ticking a checkbox, you might have to press submit button. For the toggle switch, there is no submit button.

Ask the people at YouTube who still think "outline-no outline" on a black and white theme is the best idea to indicate whether you have liked a video or not. Apparently they tested it with aliens because i, as a mere human, keep being confused and often unlike vids by mistake

Both cases are 99% a content problem. Every consent item in a form should be highly scrutinized for language and presentation, and so much of the time its just 'do what everyone else is doing' without proper ux research on how your audience will engage with it.

YES, I hate these things with vigour!

"the right side is on" – i'm afraid to bring up, is it so in RTL locales too?

People older than 30 grew up filling in paper forms for everything and know check boxes well.

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.

I recently wanted to unsubscribe from one of those corporate emails. When you click to unsub, the web site brings up "Notifications: " and a toggle next to it. It is not clear which way does what.

I think it's just because Apple did it and people got used to it. There are a lot of things I personally hate about the functional aspects of Apple's UI components, even though they look very pretty.

[ ] Fnurbication

When enabled, created nurbs are automatically converted into fluffy nurbs.

The short delay in a toggle switch turning on, as opposed to a checkbox, is also irritating.

Like, if it's used to expose an additional menu option, for example. That stutter of waiting breaks the flow.

I like sliders for a three state: NULL | On | Off. This can be useful in a search area where I want both an explicit yes/no, but also have an option for either yes or no.

I saw a cookie opt-out a couple of days ago where right was off.

In my early saas products, I just used two radio options either labeled on/off or yes/no. I know that’s “wrong”, but it’s super clear

A toggle switch is better because it has an animation.

Designers like how they look better than a checkbox.

Mobile usability that can be performed with a single hand/finger is my guess. Creating a UI that is both web & mobile friendly.

Buuuuut, toggle switches are cooool!

(I only get paid for [marketing] cool; not coding correctly [that's a client support problem])

maybe follow up question is what problem being solved.

do users not intuit checkbox button? is this some problem being solved or more of fad?

I often struggle which of the two states of a switch represents on or off, sometimes barely distinguishable...

Worst ui decision of all times. Toggling is never enough so you color it to green for true and gray for false.

They're optimizing for the website looking cool and trendy, which is an ever shifting standard.

That one is easy. See where toggle switches are most popular. It is in situations where the site gets some benefit out of you being confused and putting the switch on the opposite setting. This is usually for the privacy settings required by the EU.

It allows sites to reap the benefits of some confused incorrect settings while being in full compliance with EU regulations.

UI designers need to stop following fads. You see bad ideas spread like forest fires all the time.

Ah, so I'm not the only one...

As long as its clearly marked "Mode Execute Ready"…

The color? Green/blue is on. Gray is off.

also me, I always double check. when there is no label: On/Off is even worst.

Fashion. That's it.

1991 video of the HCIL touchscreen toggle switches (University of Maryland)

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.

I think they make sense if used correctly; the act of toggling immediately changes the state of the app to match the state of the toggle. If you're tracking a dirty state and the action doesn't occur until a Save/etc button is clicked, it should be a checkbox.