Likewise I thought the article’s punchline was going to be the increasing use of on-off toggles instead of checkboxes. Like how the settings app on macOS now has more on-off toggles than ever before.
Personally though, my fav pet peeve remains the unclear toggle button. When the icon is white, is it on? Is it off? Does the line through the microphone mean it’s muted? Or that it mutes when tapped? No one knows, tap it a few more times to find out…
My "favorite" toggle button is the one where they add on/off labels[1] to it, but only one, and the slider hides the label. So the label actually tells you the state, not the state it would be when you move the slider over the label. Or at least that's how I think how they work, it breaks my brain a little whenever I look at them.
I would not be able to tell if these slider toggles were saying "yes" or "no" without them going from gray to green. How do colorblind people deal with them?
That the whole world adopted these abominations, when there was absolutely nothing wrong with checkboxes, is immensely frustrating.
An icon or text should indicate the current state while hover text should indicate what will happen if you click. At least that's what we do. It's still confusing, but I agree you should be able to infer current state by looking at it. The person who designs it thinks it's obvious but it's usually not.
Those are terrible. I think I’ve had analogs in the physical world where toggles indicated state by the color exposed (green = on, red = off) but this tries to be better by having both color indicator and text indicator) and you’re left deciphering their language a bit. Yes, it is terrible.
I don't like these. They can be mistaken to users as an indicator of what moving the "lever" to the other side of the toggle button will actuate - effectively reversing the user's intent of the button as compared to what the buttons do.
When the _state_ and _action_ are intermixed it becomes ambiguous. This is one of may things we lost in the war on skeumorphism. The skeumorphic interfaces could mix both more clearly, using shading and texture and "lights" to indicate that a play button was pressed down and active.
Canon does this everywhere in their camera UIs, e.g a button with "(eye-tracking icon) ENABLE". Gotta open up the full settings UI to remember which way it works. IIRC, they actually show the current state (ENABLE = ENABLED), not the action that will be taken when you tap the button, but I might be misremembering... again.
The real reason is that in contexts like the Settings app, where toggleable items are mixed with other items, checkboxes on the left would take too much space on mobile (especially on the early small-screen iPhones), because it would require the left margin to be increased for all items. Checkboxes on the right are awkward though, and thus were replaced by the toggle switches. The immediateness argument is just a convenient excuse. Immediately-effective checkboxes weren't uncommon on desktop before. In addition, there is "previous art" in the form of boolean-toggle menu items that are immediately effective and show a checkmark when active.
This assumption breaks if you use macOS. Windows uses (or used to use) Apply button in its settings. Macintosh OSes were reactive from the start. Which means that checkboxes have immediate-ness on Macs.
That was true in the 90’s when you’d post a whole page but these days the individual checkboxes are more likely to have event handlers that transmit state to the server immediately.
White/black "indicators" of toggles are horrid. A lot of phone and meeting apps do this and it's horrible.
As for mute, I think it's pretty objective at this point that an icon based toggle should show the current state, not the state that tapping on the icon will produce. That's because the icon is serving two jobs: Convey the state and let the user change it. When a developer gets this wrong and shows a crossed out speaker while audio is playing, that's just frustrating.
> As for mute, I think it's pretty objective at this point that an icon based toggle should show the current state,
I can't see this holding up as the primary UI rule. And exceptions only for things like mute toggles are seldom a good thing in interfaces where predictability should be the king. It breaks down on play/pause toggles. The answer in my opinion is to separate the concern of the action and the state and distinctly show both at the same time.
> I think it's pretty objective at this point that an icon based toggle should show the current state, not the state that tapping on the icon will produce.
What about a play button? On YouTube, or any music app, the button will show the Play symbol when the media is paused, and the Pause symbol when the media is playing.
I’m ashamed I never noticed this until you pointed it out. Standards can be broken insidiously, and it’s disappointing that a company that cared about consistent UI enough to put out the HIG. Having typed that, I read the HIG on toggles and realized that those items in iOS aren’t checkboxes. A checkbox turns something on or off. The “round checkboxes” used in iOS are to select multiple items for further action. I don’t know what those are, or if/where they’re covered in the HIG.
So, checking out Apple‘s first party apps it seems that checkboxes are either solid color round circles (just the outline when unchecked) with a checkmark in the middle (for multi selections in lists) or just toggles (typically in settings).
Those round checkboxes I could only find being used for list selections (even when the list is horizontal, e.g. when sharing a photo). Toggles for settings.
Radiobuttons seem to always come with one element already selected. I couldn’t find an instance of an empty list where you select one element. In those cases (e.g. when picking your WiFi network) they are just a solitary checkmark on the left without the circle.
It‘s internally consistent (as I assume visionOS is, too) and the checkbox design in visionOS is actually closer to iOS than macOS. I assume that‘s the origin with quite some history behind it. Nearly two decades.
I think the more exact statement would be that as far as iOS is concerned the checkbox already was dead for nearly two decades.
As far as UI conventions go I‘m not too worried. What worries me a bit more that this much more clearly frames visionOS (as well as running iPad apps) as a iOS descendant when this might be the platform with the space to be more clearly in the tradition of the Mac.
> Radiobuttons seem to always come with one element already selected.
This Apple behaviour follows the HTML spec:
> At all times, exactly one of the radio buttons in a set is checked. If none of the <INPUT> elements of a set of radio buttons specifies `CHECKED', then the user agent must check the first radio button of the set initially.
but iOS hasn't been around forever. In the spirit of TFA, iOS marks the start of the Vandals climbing over the gates and sacking what had been to melt it all down and make a soup of melty things.
I also absolutely hate switches in almost all contexts. In some applications it can make sense, like the UI that controls your WiFi or something.
The reason why a light switch is so effective is because we can see an immediate response/impact on our action, the direction that the toggle points in is actually irrelevant, because either the lights are on or off, and toggling the switch changes that state, and I can verify with my eyes. Usually it's safe to toggle the switch back and forth until the desired state is achieved.
In software that's not always possible, and often changing the state has destructive results. So you can't experiment.
And then you get the abominations that bring in double negatives, and things that use switches to control something more complex than a simple boolean state.
"Disable the nuclear missile warning test = ON/OFF" - like what the hell does this even mean, and how can the user be expected to understand what the right option is without trying first.
This doesn't need to be the case, though depending on context extra design elements (colour, descriptive text, …) may be needed to make the interpretation truly unambiguous.
Sometimes (advert stalking preferences being the key example) the confusion is very deliberately not dealt with, and furthermore on occasion extra steps are actively taken to ensure the confusion.
That reminds me of how every other time I silence/unsilence my iPhone, I stare at the "Silence activated" / "Silence deactivated" and work out in my head if it means the phone will make noise or not. Despite doing it thousands of times.
I suppose "Sound on" vs "Sound off" would be better because in the moment I'm thinking of noise and sound, so silence is the inverse of that and kinda forms a double negative situation. "Not-noise mode activated / not activated".
Toggle buttons are hard! I tried making some for a game I made once but ended up just using text because half the people thought it meant the opposite of what it did
As a non iOS user, I always get thrown by the horizontal slider toggles. I can never tell by looking at one if it is on or off. And sometimes on touch screens I try to slide them sideways and it doesn't work.
Tabs in Gedit are the same. Whenever I have two text files open, I always understand the tab bar wrong: the item I read as active is inactive and vice-versa. All becuase they doing follow the traditional tab design and use some sort of pills instead.
> my fav pet peeve remains the unclear toggle button. When the icon is white, is it on? Is it off? Does the line through the microphone mean it’s muted? Or that it mutes when tapped? No one knows, tap it a few more times to find out…
There’s no UX consideration just design by committee, looking at static renders of the “design language”
On iOS the toggles are off left, and shown as dim grey. They turn green when you shove them to the right into the on position. That's about as much as my brain can process.
In many other environments these clues are more subtle or completely absent and I never know which is which.
I don't necessarily wish my check-box back, because I think a slider is easier to handle on touch devices[1], but it should be done in a way that indicates the status clearly. Apple's use of color is also not perfect, but at least they did not fall into the trap of using red and green. Light grey and vibrant green should be distinguishable for most people with color deficiencies even.
[1] At least when implemented properly. I am looking at you Ninebot. Your huge on/off slider only let's me turn off my scooter when the stars are aligned right. I don't even bother anymore and just use the button on the scooter.
The must microphone is a great example.
I'm often finding it hard to find out whether that type of input means "change state to this" or "this is the state".
Most confusing is when the text changes along with the checkbox, I just go from one unknown state to another.
Yes, but it took awhile. :) Also, I feel like the era when checkboxes were actually filled squares or Xs within square braces were less “checkboxy” in that they filled a box but were not “checkmark” shaped. It’s arguable they were toggles already, just data-constrained design variations of them.
An app I use regularly and have introduced numerous people to uses a small toggle slider next to text that reads "Yes, [enable this feature]". Both I and literally every person I have introduced the app to have made the mistake of assuming that the "Yes" text described the current state. What's worse is that the "on" state of the toggle is just slightly more activated-looking than the "off" state. You could hardly design it worse on purpose.
>>>"...increasing use of on-off toggles instead of checkboxes"
One of the most egregiously angering thing to me is toggles that self un-toggle:
"Disconnecting Bluetooth Until Tomorrow"
WHAT?
I literally just commanded the device to turn something off which required me to pick it up, unlock it with a biometric identification, navigate to the settings containing the option I want to control with my physical hands, look at the screen, read the results for the object I want. Make the decision to turn a thing off. Do so by physically touching the device and adjusting the setting - not the Device says
"Oh you want that off? More than for just a little bit? Well, I'll have you know that we use your Bluetooth radio for a lot of our data tracking systems, so its important to us that its on - so we've coded your device's operating system to only allow you to turn off your Bluetooth radio temporarily so you feel like you're in control of it. Why? Because Fuck You Thats Why. Now go back to browsing reddit"
I find that kind of "feature" frustrating as well, but I'm pretty certain that the reason it's there is that otherwise they get a constant deluge of support requests from people who forgot they turned it off.
I've only seen round checkboxes used in the context of selecting multiple things in a list of indeterminate size, like emails in your inbox, photos in your gallery, etc.
In my mind this is a slightly different application to the classic "form" that you fill out with data and options before submitting.
I was using punchline to actually mean “point”, as in: I assumed the article would show some examples of toggle buttons, but the _point_ of the article was whether the checkboxes were round or square in shape.
Yes, literally, at the very end there is a punchline on toggles. But it’s more for the laughs - a literal punchline - it doesn’t change the focus of the article.
It sounds like this may be done in an effort to improve the reliability of eye tracking in VisionOS when dealing with checkbox, not Apple just throwing the design book out the window for no reason.
>In general, prefer circular or capsule-shape buttons. People’s eyes tend to be drawn toward the corners in a shape, making it difficult to keep looking at the shape’s center. The more rounded a button’s shape, the easier it is for people to look steadily at it. When you need to display a button by itself, prefer a capsule-shape button.
Even a rounded rectangle would be more distinguishable than a circle. This is a poor excuse that decreases usability masquerading as an increase to usability.
Well, the checkmark itself is pretty angular and hard to look at. I think we should take a page out of East Asian visual language and adopt the circle as the "yes" mark. That is, radio buttons and check boxes should look like this:
( ) Radio button off
(·) Radio button on
( ) Checkbox off
(O) Checkbox on
I may be missing a fundamental point of your comment or from the linked content, but given the minuscule number of users who’d be concerned with this in practical presentation, I sincerely hope that the UXers involved didn’t optimize for this use case.
>Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round checkboxes.
So the death of the square checkbox they are predicting is only in the context of VisionOS. Apple’s HIG explain why this decision was made (my link), so I don’t think it is part of a larger trend and we shouldn’t expect it to impact anyone not using VisionOS, or other such headsets with eye tracking. It was done for technical reasons relating how the person will interact with the device, not style reasons.
It's not a "minuscule number" because visionOS is controlled by looking at things and pinching your fingers. If people subconsciously stare at the edges of a square button, can you imagine how often they'll misclick? (mispinch?)
Great point. Very disappointing to read an critique that tries to appear thoroughly thought through, but not even considers that the company that has been very consistent in UX design choices, might have thought about what they're doing in a system, that probably requires fundamentally different approaches to UX.
I mean:
> Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round checkboxes.
And yet the author is too lazy to think about that this might have a reason other than "they're stupid, look at all my screenshots, i know better than them".
Btw: not saying i agree with this decision. But why even take the time to write when not trying to actually think about what you're criticising?
Dad must know better, surely! It's absolutely impossible that almighty Apple is now full of subpar UX wannabes.
Apple design has been on a downright trajectory for a long time now, basically since Ive was promoted to the very top (yes he left now, but the damage was done). The Peter Principle doesn't make exceptions.
Totally agree. I'm surprised that a post making a big claim with little research and shallow content like this got to the frontpage with over 800 upvotes. Sad you're being downvoted too.
"people on the Web think conventions are boring. That regular controls need to be reinvented and redesigned. They don’t believe there are any norms."
That's why we have the accept button in dialogs (e.g. OK) on the left, or on the right, or in the window's title bar, depending on the intensity of mental disorder of the one designing the website theme.
You don't need the Web for that. Windows puts the positive button on the left, macOS has it on the right, and Windows CE (for embedded stuff and palmtops with small screens) had OK buttons in the title bar.
These are three different languages which are (ought to be) internally consistent though. Humans are pretty good at switching contexts when there's a clear difference between these, like using their PC, their Mac or holding their phone. What they suck at is learning something that isn't consistent at all.
But at the least the decision is the same across the OS. If you spend several hours using the system you will know the "right" way. But in the web you're on nowhere's land.
At least in windows you can pretty consistently hit ENTER in a dialog box to close it with the default action, though. That's something that has always annoyed me on Mac.
It’s not necessarily mental disorder. In some companies, when management runs out of ideas what to do, they start changing UI and pull revenue fluctuations as consequences of those “improvements”.
It would be a real tragedy if they discovered you could write a webapp such that all such "pushing around the plate" activity could be done via CSS. But of course that is insufficient "drag" to dissipate managements excess energy, so this activity requires backend work as well.
Note that this only applies to management at cash cow businesses - startups have plenty of real work to do. This sets up an interesting dimension in the tension between the needs of Enterprise ("make small changes labor intensive") and startups ("make large changes quickly"): too much developer productivity would eliminate 80% of a huge set of bullshit jobs.
Isn't another reason they constantly change up UIs is for the sake of novelty? Doesn't novel design signal "newness" to a prospect, which gives a desirable air of greater relevancy and trendiness? And does not this "newness" convert into more sales?
Oh, come on. It's easy enough to figure out! It's always the other button, as in not the one labeled Cancel. Or No. Rarely, Reject/Fail/Abort. Except when there's only one button, then you use the X in the corner. If it's there.
macOS had this right: dialog buttons read in ascending order of intent, with allowances for changing the default button to the one that's least destructive without changing the button order. Simply by reading, you were shown all available options and ended with the one you likely want to click.
Arguably, iOS compensated much (and even added) in the original skeuomorphic / Forstall-era designs. (Famously, toddlers were able to operate these interfaces.) The crucial failure was not reconsidering this from the basics for flat UI. At this point, it became unavoidably a mix of what had been learned by users, but was not indicated anymore, because you don't want to break traditions, and what was actually in the UI language. As a result, instead of a clear language, there is now a diffuse aura of how things may work.
(Also, reportedly – I have no way to corroborate this –, in the Ive-era, designs were evaluated in print-outs, which is simply how not to do interaction design.)
That argument can easily be switched around. I likely want to do what I'm asked (It's likely I initiated it). So having "Ok whatever whatever whatever" is good.
I'm assuming now of course that I'm optimizing not for least risk but for least reading.
You don't need the Web for that. Windows puts the positive button on the left, macOS has it on the right, and Windows CE (for embedded stuff and palmtops with small screens) had OK buttons in the title bar.
Forgive me for reflexively jumping to one of my favorite critiques of the universe:
Flat design weeds out a myriad of built in affordances of our visual system:
- Color to help us more quickly distinguish between things, what the things are, and their roles.
- Borders, to demark edges of active usable elements, communicate roles, encapsulate closely related things.
- Translucence as a way to combine subtle elements into a single form in a way our visual system can quickly interpret.
- Texture as another means of quickly communicating topic separation and indicating roles. Especially useful for areas containing other elements.
- Shading that our native visual system naturally interprets as rich 3D information. For processing separation, function, including the state of dynamic function.
- Smooth motions to draw attention to, and indicate changes of state.
I am NOT suggesting graphical interfaces should:
- Resemble a rainbow Christmas tree of "look-at-me!" ornaments.
- Organize hierarchical information in n-level nested Mondrian boxes.
- Be performatively stylish: overly glassy, shiny, lickable.
- Have unsubtle textures, or painstakingly recreate leather, felt, marble, or (dear baby Zeus) grass.
- Spray shading and shadows onto everything in an attempt to recreate VR on a flat screen.
- Sparkle, blink, bob and weave, and otherwise snow and distract us with motion.
I am suggesting that it is madness not to sparingly use large dimensions of our visual processing system, to communicate visual information.
These extra dimensions not only provide richer information for our visual fovea, but to our peripheral vision. Our brain is constantly processing peripheral vision to create context.
A classic case of form over function.
A classic case of "simple" as in "less design work, trivial brand language consistency", not "simple" as in "easy to discover, understand and use".
(As with the check/radio/button/selector, I cannot process that Apple fell for flat design. Such corporate amnesia. From design leader to lowest common denominator follower.)
Good points, but just to be picky - there are a few good "flat + color" combinations out there, flat and colorless don't necessarily come as a package. After all, who doesn't want the default button to be in their brand's accent color?
Pressing a button would be optional. No need to give Apple's customers a confusing choice - just transfer all their money to Apple who can prioritise Apple's needs appropriately.
I suspect that phrase may be a oblique reference to the absolutely lovely UI testing book "Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems" by Steve Krug.
In a similar vein, try explaining to a senior with fading skills that under material design literally nothing is a clue that a region on your screen is a button you can press.
Only prior use can inform what is active, and what is not.
Don't forget to explain that some buttons are inside faint pill shaped shading (or it could be a search field in which they could tap without consequence) and that chips (to show options for a specific context, so they could tap without consequence) are rounded rectangles.
Except if the site is still on Material Design 2, then it is the reverse in which some buttons are inside rounded rectangles and that chips are inside pill shaped shading.
Android's own Gmail app is a prime example of shitty use of checkboxes in Material Design (or Material You or Material 3 or whatever the hell it's called now):
There's a list of emails with a checkbox for each email on the left.
If you want to quickly select a bunch of emails---for instance, to label or sort them---you quickly press all the checkboxes.
If you just barely miss a checkbox, you will open the email because you press the larger selectable region (which is, btw, invisible until selected---a nod toward your "prior use" statement) for one email where a checkbox happens to be fully enclosed.
Now, if you are trying to label or sort some messages that have been opened and also some that are unread, you now have one extra task of going back after labeling/sorting and marking the one that you accidentally opened as unread---if you actually noticed in the first place whether it was already opened before you opened it!
On my phone, Gmail checkboxes are about 3 by 3 millimeters. If I dip my finger in coffee and lightly tap the paper on my desk, it creates a circle about 5 to 6 mm in diameter. I've opened countless emails just trying to do routine sorting and labeling via checkbox. I know there are larger fingertips, smaller screens, and people with less stable coordination than mine.
Google's nested, tiny checkboxes are a waste of time and a needless security flaw, as emails often contain info you'd like protected, and cameras are commonplace and usually legal, so it doesn't matter if you are quick to close the message you suddenly opened outside of your home.
The alternative? Hold each message until the checkbox populates, which is noticeably slower but lowers the likelihood you accidentally open a message.
I don't understand why the Gmail "open this message" region isn't a full 5+ mm right of the checkboxes (except maybe at smartwatch resolutions). They shouldn't be enclosed or nested AT ALL! Nobody reasonable is opening messages by clicking the little blank space to the left or top of the checkboxes. (...at least they weren't until they saw my statement and decided to do it from now on out of spite or curiosity.)
I also don't know why Android Studio shouldn't/doesn't harass developers with "Attention! You are committing BAD DESIGN!" alert messages when they try to put small selectable elements on top of other selectable elements that perform an unrelated task.
I don't blame the kids: the brutalist yet colorful zoomer UI design is much easier to parse for 30 year old seniors than the flat UI/material crap our generation created.
I have no way to defend this argument but my eyes, but I can say that Google's Material design is the most bland, insipid of them all, and I would rather see Bootstrap again than another Material-inspired with its white cards on white background and tap animations. Just kidding, Bootstrap was as bland.
It’s definitely not just seniors. If you watch young kids use apps, they tap all over the screen to figure out which elements are actually interactive.
Recently had to help an aging parent use their phone to obtain medical care: an app was required to access their MyChart to get a message from their case manager. Having to explain what is "clickable" is infuriating. The race for UX/UI novelty is leaving seniors behind, which is tragic since hospitals are pushing them online.
Exactly this. I hate it. Impossible to distinguish a button from a label. I don't understand how someone could come up with such ideas and get them approved for such wide-spread UI.
There was a definite shift in User Interfaces that we can associate with the huge influx of people from the advertising and media space in the ad-supported web.
Early web sites were mostly programmer affairs, with the ocasional designer to build a few assets here and there. UX people were mostly psychologists or even computer scientists that were more interested in arcane issues like accessibility and semantics, they didn't even call themselves UX, they were usability specialists.
Now UX is mostly a territory of designers forged intellectually in the media and advertising space. And this has spread even outside the web.
Yeah, UIs now look gorgeous, but a lot of times, the beauty comes at the expense of functionality and usability.
In any culture that is dominated by advertisers, form dominates function. Appearance trumps content.
BTW. Motif (on X11) used small bevelled squares for check boxes and a bevelled diamond shape for radio buttons.
There was no checkmark, cross or coloured circle. Bevelled in was active. Bevelled out was not.
"X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly." -Steve Strassman, Unix-Haters Handbook
Readit News
Likewise I thought the article’s punchline was going to be the increasing use of on-off toggles instead of checkboxes. Like how the settings app on macOS now has more on-off toggles than ever before.
Personally though, my fav pet peeve remains the unclear toggle button. When the icon is white, is it on? Is it off? Does the line through the microphone mean it’s muted? Or that it mutes when tapped? No one knows, tap it a few more times to find out…
[1] https://itsfoss.com/content/images/size/w1000/wordpress/2022...
I would say a solid 80% of unsubscribe prompts have some sort of similarly confusing layout or verbiage.
That the whole world adopted these abominations, when there was absolutely nothing wrong with checkboxes, is immensely frustrating.
Checkbooks are quite self explanitory.
https://www.homedepot.com/p/Leviton-15-Amp-Single-Pole-Switc...
Or car door locks which show red (unsafe) when unlocked. It's showing the current state, not the state that will be when toggled.
https://www.istockphoto.com/plans-and-pricing
The dark patterns here are something to behold (A bit like Adobe's stuff)
Does OFF there mean
-the setting is off
Or
-Slide this thing over to turn it off
I’ve seen it both ways. It’s confusing and not clear.
"Disable all extensions" = OFF.
Does this mean all extensions are currently on, or off? Does toggling the switch to on /enable/ the disable-all-extensions subroutine?
A switch brings in a bunch of double negatives that can be avoided in most cases.
Hella confusing!
Deleted Comment
When the _state_ and _action_ are intermixed it becomes ambiguous. This is one of may things we lost in the war on skeumorphism. The skeumorphic interfaces could mix both more clearly, using shading and texture and "lights" to indicate that a play button was pressed down and active.
Look at this UI, it's mix of state and action: https://discussions.apple.com/content/attachment/861693040
fast backward rewinds: Probably showing action
Play: 100% ambiguous if action or state
fast forward: Probably showing action
Volume slider: showing state
Back-forward buttons: showing action
Select drop-down: Showing state
We've got a video playing and an icon button which controls whether the video is muted. We've got a "playing speaker" and a "muted speaker" icon.
What's the correct pattern? Should the icon reflect the current state, or the expected state after pressing the button?
A checkbox is like filling a form, it requires submission for the action to take place.
That the user never knows if the toggle is in the on or off position.
As for mute, I think it's pretty objective at this point that an icon based toggle should show the current state, not the state that tapping on the icon will produce. That's because the icon is serving two jobs: Convey the state and let the user change it. When a developer gets this wrong and shows a crossed out speaker while audio is playing, that's just frustrating.
I can't see this holding up as the primary UI rule. And exceptions only for things like mute toggles are seldom a good thing in interfaces where predictability should be the king. It breaks down on play/pause toggles. The answer in my opinion is to separate the concern of the action and the state and distinctly show both at the same time.
What about a play button? On YouTube, or any music app, the button will show the Play symbol when the media is paused, and the Pause symbol when the media is playing.
https://developer.apple.com/design/human-interface-guideline...
So, checking out Apple‘s first party apps it seems that checkboxes are either solid color round circles (just the outline when unchecked) with a checkmark in the middle (for multi selections in lists) or just toggles (typically in settings).
Those round checkboxes I could only find being used for list selections (even when the list is horizontal, e.g. when sharing a photo). Toggles for settings.
Radiobuttons seem to always come with one element already selected. I couldn’t find an instance of an empty list where you select one element. In those cases (e.g. when picking your WiFi network) they are just a solitary checkmark on the left without the circle.
It‘s internally consistent (as I assume visionOS is, too) and the checkbox design in visionOS is actually closer to iOS than macOS. I assume that‘s the origin with quite some history behind it. Nearly two decades.
I think the more exact statement would be that as far as iOS is concerned the checkbox already was dead for nearly two decades.
As far as UI conventions go I‘m not too worried. What worries me a bit more that this much more clearly frames visionOS (as well as running iPad apps) as a iOS descendant when this might be the platform with the space to be more clearly in the tradition of the Mac.
This Apple behaviour follows the HTML spec:
> At all times, exactly one of the radio buttons in a set is checked. If none of the <INPUT> elements of a set of radio buttons specifies `CHECKED', then the user agent must check the first radio button of the set initially.
https://www.w3.org/TR/html401/interact/forms.html#radio
but iOS hasn't been around forever. In the spirit of TFA, iOS marks the start of the Vandals climbing over the gates and sacking what had been to melt it all down and make a soup of melty things.
The reason why a light switch is so effective is because we can see an immediate response/impact on our action, the direction that the toggle points in is actually irrelevant, because either the lights are on or off, and toggling the switch changes that state, and I can verify with my eyes. Usually it's safe to toggle the switch back and forth until the desired state is achieved.
In software that's not always possible, and often changing the state has destructive results. So you can't experiment.
And then you get the abominations that bring in double negatives, and things that use switches to control something more complex than a simple boolean state.
"Disable the nuclear missile warning test = ON/OFF" - like what the hell does this even mean, and how can the user be expected to understand what the right option is without trying first.
Sometimes (advert stalking preferences being the key example) the confusion is very deliberately not dealt with, and furthermore on occasion extra steps are actively taken to ensure the confusion.
unless you're on an email newsletter subscription settings page, in that case beware
I suppose "Sound on" vs "Sound off" would be better because in the moment I'm thinking of noise and sound, so silence is the inverse of that and kinda forms a double negative situation. "Not-noise mode activated / not activated".
> my fav pet peeve remains the unclear toggle button. When the icon is white, is it on? Is it off? Does the line through the microphone mean it’s muted? Or that it mutes when tapped? No one knows, tap it a few more times to find out…
There’s no UX consideration just design by committee, looking at static renders of the “design language”
In many other environments these clues are more subtle or completely absent and I never know which is which.
I don't necessarily wish my check-box back, because I think a slider is easier to handle on touch devices[1], but it should be done in a way that indicates the status clearly. Apple's use of color is also not perfect, but at least they did not fall into the trap of using red and green. Light grey and vibrant green should be distinguishable for most people with color deficiencies even.
[1] At least when implemented properly. I am looking at you Ninebot. Your huge on/off slider only let's me turn off my scooter when the stars are aligned right. I don't even bother anymore and just use the button on the scooter.
I guess because the toggle has more real estate for you to tap? If so, then couldn't you just make the checkbox bigger and get the same ergonomics?
Most confusing is when the text changes along with the checkbox, I just go from one unknown state to another.
It kind of was. The last line of the article is “Kids these days will just use a toggle anyway”
One of the most egregiously angering thing to me is toggles that self un-toggle:
"Disconnecting Bluetooth Until Tomorrow"
WHAT?
I literally just commanded the device to turn something off which required me to pick it up, unlock it with a biometric identification, navigate to the settings containing the option I want to control with my physical hands, look at the screen, read the results for the object I want. Make the decision to turn a thing off. Do so by physically touching the device and adjusting the setting - not the Device says
"Oh you want that off? More than for just a little bit? Well, I'll have you know that we use your Bluetooth radio for a lot of our data tracking systems, so its important to us that its on - so we've coded your device's operating system to only allow you to turn off your Bluetooth radio temporarily so you feel like you're in control of it. Why? Because Fuck You Thats Why. Now go back to browsing reddit"
In my mind this is a slightly different application to the classic "form" that you fill out with data and options before submitting.
Yes, literally, at the very end there is a punchline on toggles. But it’s more for the laughs - a literal punchline - it doesn’t change the focus of the article.
From the end of the article
Dead Comment
Dead Comment
>In general, prefer circular or capsule-shape buttons. People’s eyes tend to be drawn toward the corners in a shape, making it difficult to keep looking at the shape’s center. The more rounded a button’s shape, the easier it is for people to look steadily at it. When you need to display a button by itself, prefer a capsule-shape button.
https://developer.apple.com/design/human-interface-guideline...
>Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round checkboxes.
So the death of the square checkbox they are predicting is only in the context of VisionOS. Apple’s HIG explain why this decision was made (my link), so I don’t think it is part of a larger trend and we shouldn’t expect it to impact anyone not using VisionOS, or other such headsets with eye tracking. It was done for technical reasons relating how the person will interact with the device, not style reasons.
I mean: > Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round checkboxes.
And yet the author is too lazy to think about that this might have a reason other than "they're stupid, look at all my screenshots, i know better than them".
Btw: not saying i agree with this decision. But why even take the time to write when not trying to actually think about what you're criticising?
Laughable.
Apple design has been on a downright trajectory for a long time now, basically since Ive was promoted to the very top (yes he left now, but the damage was done). The Peter Principle doesn't make exceptions.
That's why we have the accept button in dialogs (e.g. OK) on the left, or on the right, or in the window's title bar, depending on the intensity of mental disorder of the one designing the website theme.
Note that this only applies to management at cash cow businesses - startups have plenty of real work to do. This sets up an interesting dimension in the tension between the needs of Enterprise ("make small changes labor intensive") and startups ("make large changes quickly"): too much developer productivity would eliminate 80% of a huge set of bullshit jobs.
What could be simpler?
Deleted Comment
Then they threw it away to match iOS.
(Also, reportedly – I have no way to corroborate this –, in the Ive-era, designs were evaluated in print-outs, which is simply how not to do interaction design.)
I'm assuming now of course that I'm optimizing not for least risk but for least reading.
Flat design weeds out a myriad of built in affordances of our visual system:
- Color to help us more quickly distinguish between things, what the things are, and their roles.
- Borders, to demark edges of active usable elements, communicate roles, encapsulate closely related things.
- Translucence as a way to combine subtle elements into a single form in a way our visual system can quickly interpret.
- Texture as another means of quickly communicating topic separation and indicating roles. Especially useful for areas containing other elements.
- Shading that our native visual system naturally interprets as rich 3D information. For processing separation, function, including the state of dynamic function.
- Smooth motions to draw attention to, and indicate changes of state.
I am NOT suggesting graphical interfaces should:
- Resemble a rainbow Christmas tree of "look-at-me!" ornaments.
- Organize hierarchical information in n-level nested Mondrian boxes.
- Be performatively stylish: overly glassy, shiny, lickable.
- Have unsubtle textures, or painstakingly recreate leather, felt, marble, or (dear baby Zeus) grass.
- Spray shading and shadows onto everything in an attempt to recreate VR on a flat screen.
- Sparkle, blink, bob and weave, and otherwise snow and distract us with motion.
I am suggesting that it is madness not to sparingly use large dimensions of our visual processing system, to communicate visual information.
These extra dimensions not only provide richer information for our visual fovea, but to our peripheral vision. Our brain is constantly processing peripheral vision to create context.
A classic case of form over function.
A classic case of "simple" as in "less design work, trivial brand language consistency", not "simple" as in "easy to discover, understand and use".
(As with the check/radio/button/selector, I cannot process that Apple fell for flat design. Such corporate amnesia. From design leader to lowest common denominator follower.)
There's actually a whole paragraph dedicated to explaining why "a myriad of" is just as correct (if not more).
It's astonishing how many web designers have no idea about the difference between inclusive and mutually exclusive options.
I see checkboxes used all the time when they should be radio buttons. It's not rocket surgery. https://www.nngroup.com/articles/checkboxes-vs-radio-buttons...
https://youtu.be/9BnLbv6QYcA?feature=shared
we're just a few reforms[1] away from having that commercialised.
[0] https://pubmed.ncbi.nlm.nih.gov/3492699/
[1] https://reason.com/2021/04/03/abolish-the-fda/
Deleted Comment
Deleted Comment
Only prior use can inform what is active, and what is not.
Except if the site is still on Material Design 2, then it is the reverse in which some buttons are inside rounded rectangles and that chips are inside pill shaped shading.
Are we confused yet?
There's a list of emails with a checkbox for each email on the left.
If you want to quickly select a bunch of emails---for instance, to label or sort them---you quickly press all the checkboxes.
If you just barely miss a checkbox, you will open the email because you press the larger selectable region (which is, btw, invisible until selected---a nod toward your "prior use" statement) for one email where a checkbox happens to be fully enclosed.
Now, if you are trying to label or sort some messages that have been opened and also some that are unread, you now have one extra task of going back after labeling/sorting and marking the one that you accidentally opened as unread---if you actually noticed in the first place whether it was already opened before you opened it!
On my phone, Gmail checkboxes are about 3 by 3 millimeters. If I dip my finger in coffee and lightly tap the paper on my desk, it creates a circle about 5 to 6 mm in diameter. I've opened countless emails just trying to do routine sorting and labeling via checkbox. I know there are larger fingertips, smaller screens, and people with less stable coordination than mine.
Google's nested, tiny checkboxes are a waste of time and a needless security flaw, as emails often contain info you'd like protected, and cameras are commonplace and usually legal, so it doesn't matter if you are quick to close the message you suddenly opened outside of your home.
The alternative? Hold each message until the checkbox populates, which is noticeably slower but lowers the likelihood you accidentally open a message.
I don't understand why the Gmail "open this message" region isn't a full 5+ mm right of the checkboxes (except maybe at smartwatch resolutions). They shouldn't be enclosed or nested AT ALL! Nobody reasonable is opening messages by clicking the little blank space to the left or top of the checkboxes. (...at least they weren't until they saw my statement and decided to do it from now on out of spite or curiosity.)
I also don't know why Android Studio shouldn't/doesn't harass developers with "Attention! You are committing BAD DESIGN!" alert messages when they try to put small selectable elements on top of other selectable elements that perform an unrelated task.
Well, maybe I am a senior. I know I spend far more time screaming at clouds nowadays and grow increasingly distant from what kids today are into.
I have no way to defend this argument but my eyes, but I can say that Google's Material design is the most bland, insipid of them all, and I would rather see Bootstrap again than another Material-inspired with its white cards on white background and tap animations. Just kidding, Bootstrap was as bland.
I miss Windows 2000 every day.
Deleted Comment
Recently had to help an aging parent use their phone to obtain medical care: an app was required to access their MyChart to get a message from their case manager. Having to explain what is "clickable" is infuriating. The race for UX/UI novelty is leaving seniors behind, which is tragic since hospitals are pushing them online.
Deleted Comment
Now UX is mostly a territory of designers forged intellectually in the media and advertising space. And this has spread even outside the web.
Yeah, UIs now look gorgeous, but a lot of times, the beauty comes at the expense of functionality and usability.
In any culture that is dominated by advertisers, form dominates function. Appearance trumps content.
Example: https://www.oreilly.com/openbook/motif/vol6a/Vol6a_html/V6a....
Very sharp-edged 3D boxy window design creates heavy cumbersome feel.
Inconsistent pixelly fonts.
Oddly aligned text in button.
Diamonds happen to be a shape that maximizes pixelation.
Indent in vs. out is cognitive heavy to process, relative to something less pure-dual.
Black selection border doesn't have consistent widths.
Separation line between big button and little buttons, despite obvious size and shape differences that already make that distinction.
Extra little borders defining window box corners from horizontal and vertical borders - a distinction that surely didn't need highlighting.
No rounding. (Granted, rounding would look pixelated.)
TLDR; It looks like an industrial lead brick you really don't want to drop onto your foot.
https://news.ycombinator.com/item?id=25734498
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
SGI had their own version of Motif with a look that was more like Mac and Windows of the time.