In loving memory of square checkbox
tonsky.me
tonsky.me
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…
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.
>When the icon is white, is it on? Is it off?
They reinforce this with another example of ambiguity.
The user can’t be suggested to take any actions if they can’t figure out what the default settings are.
ncruces replied clarifying the former, that the toggles proliferate because they convey immediateness. They didn't say anything about the "unclear toggle button" point.
Your comment, then, aimed to correct ncruces' comment, clarifying that lstamour was talking about unclear toggles, when ncruces was talking about the other point in lstamour's comment, and thus was already correct.
That's the second paragraph. This would be those left/right toggles that became popularized with iOS on the original iPhone (since you could physically slide them with your finger). These also do have color insanity associated, though.
The third paragraph used "toggle" in a more general sense.
To be fair, the comment has a lot going on.
I'd say that to the extent that is true, it was equally true for radio buttons in the 90s.
These days I find myself scrolling around pages to look for submit/save/apply buttons to determine whether checkboxes and radio buttons are intended to have immediate effects or have to be submitted to be applied, because there really seems to be a lack of consensus on what these elements mean in those terms.
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?
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
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.
I also can't live in a world where play/pause is opposite to the way it is now: play icon should mean the media is paused, pause icon should mean the media is playing, as you suggest.
If we constrain ourselves to only having two buttons (one play/pause, one mute/unmute), and only differentiating them by the shown icon, then I'm afraid it just has to go with the convention. They are inconsistent with each other, but intuitiveness beats consistency I guess.
> 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 don't think this is practical, especially on mobile. There is a need for these UIs to be concise, and even if there is enough space, each visual element comes at a cognitive premium to the user.
As someone who studied two years of cognitive sciences as part of my degree, this is not necessarily true. Lack of information can often lead to even more cognitive load as the user then has to imagine virtual scenarios, an cognitive process which is linear. Visual processing however is largely parallel, faster and less consuming, as we have evolved to live in a visually complex and noisy environment.
Of course, admittedly if all you have is a play button and a mute button (or some other very simple player) it probably doesn't matter much.
I think Twitch's UI is a good example of where the clutter goes too far. It's loaded with tons of distracting bits and bobs. Makes sense for their business model (most of these relate to how you can spend money on the platform), but from a user perspective it's unpleasant.
It looks like this unmuted: https://discussions.apple.com/content/attachment/e909bffc-81...
and this muted: https://discussions.apple.com/content/attachment/e3e9c230-e4...
I believe the reason it always has the slash is to distinguish it from the "change volume" button (which, when pressed, pops up a volume slider). But it's still confusing.
But a mute indicator isn't telling you how other people appear to you. (That would be "deafen".) It's telling you how you appear to other people, which you have no other way of knowing.
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.
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
- The lower row is definitely a row of buttons. Back, forward, categories in the library (?), I don't know what the last one is supposed to do.
- Are the things above that row buttons? Why don't they look like them then?
- If they are, what does fast forward and rewind do? Skip to the next track and to the beginning of the same track? Actually move quickly through the track (like fast forward and rewind used to do)? Does pressing rewind go to the beginning of the track or to the previous track? If it's to the same track, how quickly do I have to click again to go to the previous track?
- Is that slider a progress bar or volume slider?
- Where do I click and drag to move the window? If it's in that top row, why are there things cluttering up the title bar? How much space do I have left to move the window?
- I assume the coloured things are the window management controls. Does clicking the red one close the window and keep the music going, or does it stop?
It's indicating an iOS device being locally, e.g. for administration, backup, file transfer and the like.
> Are the things above that row buttons? Why don't they look like them then?
Haha yeah. That's modern Apple for you!
> what does fast forward and rewind do?
They sort of behave the way ff and fr does on a remote. Click/press fast and you skip to the next/previous song/chapter or equivalent. Hold down and you scrub at something like 4x speed.
> Is that slider a progress bar or volume slider?
A volume slider.
> Where do I click and drag to move the window? If it's in that top row, why are there things cluttering up the title bar? How much space do I have left to move the window?
I ask myself the same thing every day and have the same problem with many many apps, also in Windows. For example Firefox has the same design problem where its buttons have nor border and therefore have no clear place where draggable top space is and button is.
> I assume the coloured things are the window management controls.
Yes, these have remained mostly unchanged for over 20 years, they have gotten a bit flatter and lost some subtle small iconography.
> Does clicking the red one close the window and keep the music going
At least this part works well and in a predictable fashion. It consistently follows Apple's Human Interface Guidelines since well over 30 years: Closing a window or document of a Mac OS application should not quit the application. (there are some exceptions, but that is the default behaviour).
This can be changed by going to "about:settings" page and setting the option "browser.tabs.inTitlebar" to 0.
symbols in "traditional" media playback, the icon shown would traditionally be for fast reverse/forward. skip back/forward to the previous/next would had a vertical bar to the point of the triangle. some also go so far to differentiate skip/scanning where scanning uses two triangles while skip uses one triangle with the bar. not really sure what Apple has done to them though. i would almost expect them to be skip instead of the scan with Apple expecting you to use the playhead (in whatever format it is made available) for scanning.
the play button in Apple's use is typically action instead of state. so in this state, clicking it would start play, and then the button changes to the "pause" symbol (an = rotated 90°).
so this is a really good example of mixing usage.
I suspect a lot of the choices also have to do with saving screen space, but in the end a checkbox is one of the best ways to indicate "enabled" on a settings screen.
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?
I think these conventions are easily solved for video, anyway, because it's obvious when the video is muted or not (hopefully).
It isn’t always obvious to me. Sometimes I can’t tell if a video player is muted vs the system volume being low. There’s also the situation where a video is silent and I don’t know if I’m supposed to be hearing anything.
https://vintomatic.com/wp-content/uploads/2022/11/Vintomatic...
https://en.wikipedia.org/wiki/Dieter_Rams#/media/File:Dieter...
Although not standard, I'm thinking that a slider with a muted speaker icon to the left and a playing speaker icon to the right would be unambiguous.
Long ago, Apple's HI group had a saying: "a word is worth a thousand pictures".
In a conferencing app, for example, "mute" could mean switch audio off, or just the mic, or both.
And consider that a word, even "mute", might not have an equivalent in every languages.
If the icon is a loudspeaker, then the LED should be on when the audio is on; but if the icon is a microphone with a bar across it, the LED should be on when the mic is off.
I have a button labelled "ASR OFF" in my car. Its LED is on when ASR is off and vice versa. I don't find it confusing.
Another example: my TV has a standby LED. It's off when the TV is on, and on when the TV is sleeping. Again, I find it correct.
Microphone Status:
( ) Muted
( ) Unmuted
If this was meant (semi)ironically and mainly as a reference to the OP link, then sorry for the earnest response!
Aside from that roughly 100% of applications I've been using use the "show current state" approach in this specific case. I don't think I've seen a media player which does it differently.
(speaker emitting sound / speaker crossed over). Ie the button has two icons with a slash between them.
One of the icons is in black outline and one is in grey outline. Pressing the button switches between what is black and what is gray.
If speaker emitting sound is black, then sound is on. If crossed speaker is black, then sound is muted.
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.
> If none of the radio buttons in a radio button group are checked, then they will all be initially unchecked in the interface, until such time as one of them is checked (either by the user or by script).
That behaviour makes more sense for the Web, so that the user is required to make an explicit choice, and I'm not sure if browsers ever cared about this little part of the standard. When interacting with OS components, it makes sense that there's some default or already configured value.
https://html.spec.whatwg.org/multipage/input.html#radio-butt...
Microsoft's Windows guidelines implicitly says that one option must always be checked: https://learn.microsoft.com/en-gb/windows/win32/uxguide/ctrl...
> If none of the options is a valid choice, add another option to reflect this choice, such as None or Does not apply.
In a political vote, wouldn't that be untolerable bias?
But if hard pressed and not allowed to design a better UI I would do the following options with radio buttons:
( * ) blank vote
( ) Option A (potentially in random order vs other non-blank options)
( ) Option B (potentially in random order vs other non-blank options)
( ) Option ... n
Radio buttons are the correct metaphor for picking one option among a list of options. Why use something else? What use interface element do you think exists that works for this kind of interaction?
I’m honestly confused why you think radio buttons are the wrong type of interface element for this interaction. What‘s the reasoning as to why this seems so obvious to you? I’m honestly just trying to understand you.
Sometimes the voter has the ability to add arbitrary options to the ballot.
Sometimes multiple values are allowed.
Sometimes there are positional votings.
Sometimes there is ranked-choice.
Sometimes you do not even want to submit the vote.
Looking only at "these are the options available, choose one and only one" is not a valid strategy for reaching the conclusion on what UI idiom to use.
I protest against the default assumption that radio buttons (no matter how much I like them) should be the default go-to for voting interfaces because of the context of voting is too complex.
Obviously all the examples you named are not a good fit for radio buttons. Except maybe the last one where you can just add an “invalid vote“ radio button choice.
But that doesn’t mean that for a fairly standard “pick one” vote radio buttons aren’t a good choice! You don’t have to be consistent within the concept of voting, you just have to be consistent for the one relevant use case!
You do not want to influence people by presenting them with a default (already checked) choice. (You also typically want to randomize the order, at least when there is no inherent order to the options, e.g. when you are asking about frequency.)
Surveys are also the place where that distinction between single choice (radio buttons) and multiple choice (checkboxes) becomes most apparent because surveys tend to liberally mix the two, so any additional UI signposts you can use to help people filling out the survey are helpful. (The typical recommendation for multiple choice is to still explicitly call out in text that multiple options can be checked.)
Surveys sometimes also have the absolutely wild combined list with checkboxes and – typically as the fixed last option even if you randomize the rest of the options – a radio button (e.g. “None of the above”) that automatically unchecks all other options (and is unchecks itself if any other option is picked).
I don’t think this exists in any spec anywhere but is the most normal thing in the world in most survey software.
I‘m always very precise with whether I use checkboxes or radio buttons when designing surveys.
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.
[1] https://itsfoss.com/content/images/size/w1000/wordpress/2022...
Are you sure? I think the opposite is more common.
All earth-leakage breakers in my area are like this: https://en.m.wikipedia.org/wiki/File:Schneider_Electric_A9D3... https://i.ebayimg.com/images/g/sHYAAOSwu2ZkBk5~/s-l960.webp
Electronics industry have diverged.
And then there is this: https://en.wikipedia.org/wiki/Tally_light
> In the active (on air) mode, tally lights are typically red.
> Some cameras and video switchers are capable of additionally showing a preview tally signal (typically green) for when the camera is about to be switched to and become the main source of video signal. Once the switch happens, green changes to red.
That's daft. You want to highlight (red) the insecure state, and reassure (green)in the secure state.
Do you want a real-world example have a look at US White House:
> President Obama talks on the phone aboard Air Force One. April 10, 2014.
> The Airborne Executive Phone has the red light on, which means it's a secure call.
https://www.electrospaces.net/2017/01/the-presidential-commu...
It is further made more clear because NSA literally calls their secure network the red network.
That's why mains wiring no longer uses red to mean live and green to mean ground.
https://cdn.thisiswhyimbroke.com/images/lightswitch-identifi...
That way it's the same as a standard rocker switch (the direction of rotation is the same).
Last time I was in Europe (Portugal), I remember having a lot of difficulty making sense of the light switches, but it was one of those apartments where you have two or three light switches controlling the same fixture, which is always confusing.
Still, I think the American light switches are actually pretty good. Maybe one day we will get a Technology Connections video about light switches around the world.
This is in the US.
- 'angled towards the ground' is 'On' (https://cdn.aws.toolstation.com/images/141020-UK/800/10481.j...)
- 'angled towards the ceiling' is 'Off' (https://www.tlc-direct.co.uk/Images/Products/size_3/MKK4870....)
In aviation (and old cars) switches are usually toggle switches with "up = on".
Strangely I'm ok with both. I think of rocker switches as opposite to toggle switches automatically.
In software often none of this applies.
Checkbooks are quite self explanitory.
Accessibility guidelines usually allow them but encourage you to make it a last resort.
I have a Lenovo yoga, and its a constant nightmare of websites and apps that cannot figure out if I am a laptop or a tablet, even with tablet-mode fully off. I am usually offered whichever UI is least useful for my current configuration
The problem is that long-tap gets used for a lot of other things on Android (extended selection, particularly). The user experience is pretty unhappy if you use both conventions. And, in practice, long-tap tooltips are so rarely provided on Android apps that I doubt that ordinary users would expect them at all.
As far as I know, tap-and-hold (as distinguished from long-tap) isn't a conventional gesture on Android.
It's finicky on occasion, but when you are used to it, it's surprisingly intuitive practical! It wasn't super popular though, and I imagine it could be annoying to users who didn't want it. It appears they only did it for a few models, ending in the S5.
That phone was pretty interesting, sensor-wise. I kind of miss using it, and I wonder if it would be practical nowadays.
[1] Air View: https://www.samsung.com/hk_en/support/mobile-devices/what-is...
[2] Air Gesture: https://www.samsung.com/hk_en/support/mobile-devices/what-is...
It's an augmentation that can be used on desktops though. I agree that it shouldn't be necessary but, but it can help. Some apps aren't meant for mobile either.
At least sliders generally have right for on, as opposed to pure text toggle buttons which are just awful.
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.
“Unsafe” is contextual. If you are inside the car, and the car is on fire, then “locked” is very much the “unsafe” option.
Red lights on top of towers isn't trying to tell planes and helicopters to stop, its telling planes to exercise caution around the tower.
Red at a traffic light means there's a danger so you stop. Green means it's safe to proceed.
Red on a gun safety switch means danger because it's live.
The red wire is live and dangerous. The green wire is earth and safe. (at least true in Europe).
Are you in burning cars often?
I'm still unsure, have you been in many burning cars before? More than just moving vehicles?
(Do car still come doors that don’t automatically unlock when the handle is pulled, if the child safety switch is disabled?)
https://web.archive.org/web/20240128035720/http://www.homede...
A lot of physical play/pause buttons show both symbols. Also in a lot of cases you can tell if a video is playing.
And that is anyway besides the point of consistent UIs' toggle switches describing their state, not their action.
Fewer and fewer devices we have access to these days have physical switches on them, though.
Does anyone know of a major media player where the play/pause button shows what the state is, rather than what the button does?
By comparison, it's quite common here to have a switch with a lamp to indicate the light is on, which get used when the status of the light cannot be easily seen where the switch is located (e.g a switch for a light in the loft/outside light etc).
The light up variety are mostly to aid turning on the lights in the dark and aren't usually the default. It's nice being able to see the switch when entering a dark room.In a residential setting it's a bit more rare to have a switch control a light you're not either immediately seeing or are often imminently going to see, like a closet or looking out a window next to the switch. It's not like you're often turning on and off lights across the house, so having it light up when the room lights up is rather redundant instead of offering that dark time help. Finally, having an on light would be really redundant since you can usually easily see the switch is physically pointing up or down and they sometimes even say ON or OFF.
As for up being on and down being off, it's about being easier to toggle to the safer state. It's more likely for off to be a safer state (think changing a bulb, having it connected to a garbage disposal, etc.). It's generally easier to flip the switch down than flipping it up, so it's easier to toggle to the safe state rather than the unsafe.
I have those in Europe. The point is that you can find the light switch in the dark. Why would it need a light when it's on, if it's in the room that it lights?
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.
Unsubscribe from the following:
[X] List A
[X] List B
[X] List C
[ ] Unsubscribe All Lists
I would say a solid 80% of unsubscribe prompts have some sort of similarly confusing layout or verbiage.
A button or link in place of the 'All' checkbox makes sense and is easiest for users to understand, and has less user actions required.
Treat your customers well even when they're exiting (especially) so they remember something good next time they consider you. "Well at least they made it easy to unsubscribe" is better than "Well they made it unnecessarily complicated to unsubscribe". No need to add insult to injury.
The unsubcribe-all should just be a link or button with its own submit value or URL param (like unsubscribe=all).
I don't know why people overcomplicate things.
I noticed there are times I have to do it manually and can't take advantage of auto unsubscribe because the button layouts are like this.
That the whole world adopted these abominations, when there was absolutely nothing wrong with checkboxes, is immensely frustrating.
I think it is no coincidence these are the preferred control for all manner of dark pattern setting screens.
Now, does light-green mean "no" because it's light, or "yes" because it's green? That one you have to check on each application.
"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!
If you put the labels next to the switch: ON [xxxx] ---- OFF then it's clear that sliding the switch toward the label puts it in the on or off state. But hey, we can save some screen real estate but swapping the labels and hiding the inactive one under the switch! Yay! For on/off a chechbox is much clearer for the size.
With software however, the inconsistency comes from knucklehead design. Hipster aesthetics. "But I want ours to be different!" They introduce toggles that don't follow convention and make unclear the status and behavior, or if touching it will even do anything. It then muddies up in people's minds how the conventional ones look and behave.
Ex: https://www.chily.com/customer/chily/product/3331_350.png
(Why selling photos of those things never seem to show the label?)
https://www.istockphoto.com/plans-and-pricing
The dark patterns here are something to behold (A bit like Adobe's stuff)
> 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”
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.
https://developer.apple.com/design/human-interface-guideline...
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"
It kind of was. The last line of the article is “Kids these days will just use a toggle anyway”
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".
Most confusing is when the text changes along with the checkbox, I just go from one unknown state to another.
From the end of the article
In my mind this is a slightly different application to the classic "form" that you fill out with data and options before submitting.
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.
>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.
After seeing everybody adopt the Android flat UI (win 10), i really think that stupidity is contagious.
Honestly, I wouldn't trust any modern Apple HIGs. After the UX butchery of BigSur they retroactively updated the HIGs to justify their decisions.
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.
Apple & elon musk make people on HN act so weird. Sad.
Like i just said in another comment: apple & elon musk make people on HN act weird.
Yeah, no. Not at all. But if you still don't get that my comment has absolutely nothing todo with the design choice itself a t a l l , it's truly pointless.
( ) Radio button off
(·) Radio button on
( ) Checkbox off
(O) Checkbox onThat'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.
There are lots of other design sins this doesn’t excuse (low contrast, for instance), but expecting conventions to be as consistent as on a desktop OS feels naive.
There are some things where the browser will apply platform conventions, but nothing resembling the consistency you'd expect from (well-designed) native apps.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/system-colo...
Nothing stops Web developers from flipping the buttons if they detect a Mac, but that would make things more confusing if someone is using the same Web app on multiple platforms, or if the docs have screenshots from different platforms (to each other or to the user).
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.
What could be simpler?
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...
we're just a few reforms[1] away from having that commercialised.
Only prior use can inform what is active, and what is not.
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.
I can't think of any example off my head, but I remember mention of a striking online clothing store with bold colours, thick black borders and large fonts that's very popular in that age range.
From a quick search on google: https://thedigitalmaze.com/blog/three-awesome-ui-design-tren...
See also the design for Gumroad: https://gumroad.com/
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?
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.
I think apps will die but not by 2035, probably 2055. Apps are fucking stupid and antithetical to the web IMHO.
Oh and I hope phone trees die a horrible death especially ones that don’t immediately put you through to a human. The biggest pain due to cost savings is not being able to get help via a goddamn phone call that doesn’t go to a call center, or worse: a disconnect at the end of a long tree of number presses.
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.
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....
SGI had their own version of Motif with a look that was more like Mac and Windows of the time.
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.
This actually designates an area where you can click and drag to resize the window. I'd argue that this behavior has become a ubiquitous expectation because of this design.
Like, a 1px border isn't too back when I have a keyboard shortcut that makes a full 1/9th or so of the window's area the effective border. But when it's exactly a pixel — and combined with macOS's cursor's hotspot not being on the cursor tip … it just takes what should be simple to way harder than it need be.
And then there are the too skinny to grab scroll thumbs, which are also invisible without gratuitous scrolling. And they disappear quite quickly.
Three alternate solutions:
1) Long hover (1/4 sec?) near window edge, to make edge grabbier. Long hover (1/4 sec?) near scrolling side for scroll bar to appear.
2) Pressing one of the modifier keys to make edges and scroll bars appear and be grabbable.
3) Toggle keyboard command, that makes edges slightly thicker and holds scroll thumbs visible, vs. hiding them.
This is because the screenshot is apparently rasterized from data for print version (".eps.png") at a resolution that does not match the resolution of the two bitmap images in it.
https://news.ycombinator.com/item?id=25734498
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
I remember user interface design class at my university ca. 2005 where 20 out of the 30 best practice interaction design patterns originated at Apple!
Steve Jobs for the most part really cared and you could feel those priorities clearly: "it's how it works, not how it looks!"
Aside from some natural missteps, the "form over function" critique at the time was predominantly false. Apple is slowly getting there though, joining "ignorant web" as correctly called out here by Nikita.
The thing is that none of this is a joke or could be taken however lightly. It's 2024 and by now we've fundamentally realized the "Software is Eating the World" prophecy; living in a digitally permeated world.
Bad design is a moral issue, in worst case scenarios it has been killing people before and will increasingly kill or harm even more going forward. It always starts with the little things, especially so in design / engineering.
I desperately hope that Zoomers at least will start to realize that Millenials really fucked it up in that regard. I know, I know it also were the bosses pushing for this but we clearly should have said "no" much more often as the professionals (?) implementing this stuff.
There is much satisfaction waiting in learning; a full-grown craft with deep history.
Zoomers: Alan Cooper's "About Face" is a great start, probably super cheap these days as seemingly no one cares anymore.
There's no money in making a thing that works well, only in making things that look good. Effectively 100% of people who are using software are using it for things that fundamentally don't matter, so why should they care if the functionality is shit? Personal computers and phones are fashion statements, not useful devices. Business computers and phones exist to facilitate the bullshit jobs that employ the majority of the white-collar population. Follow the money; nobody with money cares.
I'd boil it down further and say it's a focus on short term gains over long term gains. If the pan flashes, that's a win, full stop. When the pan stops flashing and people don't want to use your software because it's confusing, that doesn't matter because they can just flash another pan.
I work in a company building vending machines and such and it's the other way around here. Most products are shipped with a pretty mediocre UI because it just isn't valued. The software has to run the machine, vend products to people and don't eat their money.
Amazon, AWS, Salesforce and anything Oracle entered the chat.
More seriously, I think it really depends. People will use and pay large amounts of cash for stuff that solves there problem and does not have a fancy looking UI.
It's incredibly annoying, and i say that with a an interest art, the abstract, cool concepts etc. but i want to see sites and interfaces with "actual messy real life content" not just one big image or whatever idiotic whitespace hell everyone's doing with way too much scrolling on Awwwards, Behance, Httpster, Gsap etc.
It's relatively easy to make a big font, a big picture and a 3d effect look cool, much harder to present 15+ items on one page and create a cool visual narrative around it that both grabs attention and lets the user go solo if he wants to without scrolling two miles.
I feel like a few newspapers were okay examples of this 5-10 years ago, but now they've also gone whitespace crazy.
We need a site like "Real life UX" or "Actual usable design" inspiration.
2. Most UX design aren't probably taught. Especially Software User Interface.
3. A lot of Design in that era came from Web. And if we read this article we already know or could guess what web design were like.
4. It is my observation that Tech, or Silicon Valley historically speaking learns very little about history of their industry. Unlike many other discipline, things comes and goes like fashion industry. Combine with Hype machine and VC money. Apart from Politics or Finance there is no other industry that contains as much noise as Tech.
5. Conservatism ( Not politics ) is generally not well accepted. Finished Software is not appreciated. And if you cant improve, or remake something, there is no way you can move up the ladder. The fundamental of not doing anything hype or large changes is against Resume Driven Development model.
Prior to that, deviations from established standards (layouts, colors, logic) were seen as unprofessional and tasteless. Things like buttons with unusual colors made software look like a shareware hobby project downloaded from Tucows, and nobody wanted their product to trigger these associations. Premium software made for Windows wanted to have the look and feel of Word and Excel.
I'll tell you what happened.
Apple.
I've been saying for years now that Apple is not a tech company, they're a fashion company. Alternatively, they make tech fashionable, which means abandoning function in favor of form.
Actual UX is unimportant. It just has to look nice.
What infuriates me is when other companies then start to copy them. I'm looking at you, Microsoft. With Windows 11, it seems you have forgotten that many of your users stick with you because you're not MacOS. So why would you want to start imitating MacOS?
Sure, things regress and move in waves, but on the whole user design has been established as the primary of software development and that really was a not the case back when.
Take something like error handling in a form. In a lot of average software, it was not at all uncommon for a form to just say "Error" when something went wrong (or just not submit). Or lose all form input after unsuccessful submission. Programmers were unironically confused about why people would not just enter correct information. People then wrote books about how to design form errors. Now, basically every web framework includes at least some form of validation and error handling by default(-ish), and most people would be seriously confused if they saw something like the above.
If you find it easy to poke holes into this one, please consider the average across all the little things that go into not fucking up a form, which is still hard to get really good, but again I am describing something of an average expectation here.
I would pin this to two major developments:
1. Designers are increasingly everywhere. If you think "duh?", this is entirely not how software was made. Programmers, commanded by business people, made software.
2. Most programmers today are also designers, and I don't mean in the sense that they always were (designing the software), but as in "thinking about people using the product".
Again, this might feel like a comical thing to even say but in most places programmers were just not expected to do anything to make the users life simple, unless explicitly told so. That was the designers job. In fact, a lot of programmers considered it a holy duty to fight any feature that was merely a convenience, and were quite adamant that, surely, the user could simply be expected to suffer a little and work a bit harder to get things done, if that meant keeping the code base pristine.
And perhaps that's where the OP's question originated from?
As we've watched the despecialization of our field in testing and ops, we've seen that things improve, as ideas are introduced more widely, while also seeing them get mimicked and cargo-culted when the ideas are diffused.
Maybe the coders who were fighting against testing mandates or devops or design thinking were just insecurely admitting to their own ignorance on these topics and asking for assistance in being able to perform their new duties effectively?
One value in specialists is the freedom that comes with specialization enables them to do their job more completely. Fred Brooks's surgical team could not be more relevant.
Of course, this can also be credited to the fact that ui design for software was at a much different place in general.
I'm not sure if I read all the way through it when I first got my copy but it -is- very good and I have it stashed for the next time I end up doing UI design.
Well worth a look.
2013 was when we first witness it in effect. It started a little earlier inside Apple. When Scot Forstall was forced out, the whole Software User Interface falls to Jony Ive and he basically ripped everything out and redesigned it with iOS 7. There is a huge different, or dare I say 95% completely unrelated field in Software UX and Hardware UX. Apple then spend the next 3-4 years walking back on all the design changes made in iOS 7.
Unfortunately a lot of UX learning was lost during that period. Including the Seniors of Human User Interface retiring during 2015 - 2020. The group has also grown rapidly in terms of numbers under Tim Cook. A lot of the Steve Jobs design requirement and "why" were diluted with more new members.
The design from Apple today may still look beautiful, but they are no longer as functional as they once were.
For decades, all the conventions had developed on desktop. By ~2013 it was clear that mobile required different conventions, and that it was important to also unify conventions to some degree across mobile and desktop.
Also, traditional desktop apps had largely limited themselves to the UX vocabulary provided by the OS's graphical widgets. But with the rise of high quality CSS and JS, websites and apps became more free to develop their own conventions, separate from anything coming out of Apple or Microsoft. Hamburger menus and pills and what have you.
So it makes perfect sense that Apple started to evolve more rapidly around that time. And good for them -- none of these rules can or should be set in stone.
(And please don't make this about generations, that's just silly. Trying to assign blame to entire generations is utterly meaningless. Generations are made of individuals who disagree with each other.)
Meanwhile, every person working on design systems should think about decisions like these deeply. Designers, engineers, accessibility specialists should all talk together and come to some common ground before doing something like this.
https://www.shutterstock.com/search/radio-buttons-old-car-ra...
There's a good explanation of how they worked here:
https://www.physicsforums.com/threads/how-do-old-timey-radio...
I believe it was this way since the introduction of iOS 7 in 2014[1] (article from 2016).
[1] https://osxdaily.com/2016/01/25/how-to-add-checklists-to-not...
The best designers in the world, keeping alive the worst UI trend of making everything flat and white without any separation, border or shading whatsoever.
People see something round, "box" isn't the first word that comes to mind.
In my previous history as a ... as a web person (I think that's both broad and vague enough to encompass the yes-I-did-that-too sense of things), I had an ever-growing disdain for the designers who were off on their own flights of fancy. Usable? Explainable? Accessible? Senior-friendly? Then, late to the party, I got this iPhone thing and I was astonished at how much the device expected me to know about how the interface worked, on a deep level. I tried to get my mother into an iPad and, frustratingly, could find no good cheat sheets on the "gestures," to the point where I made a laminated, color-coded and numbered set of sheet on gestures, screen, etc. I help out an even older senior with her computer and ... well, I think the i-UX people are frankly out in their own la-la land and their hubris is sustained only by Apple's inertia/network effect/market dominance.
In a kinder, gentler world, these UX teams would be required to make a general style sheet document, which would be applied to various real-world applications, and then they would be forced to watch a senior citizen attempt to navigate their trash to, say, get a test result from the hospital. Should this not be accomplished in under five minutes, they are thrown into a hell of leather-clad demons who beat them with sticks while patiently explaining that their design, in fact, sucks.
UX design has begun to resemble fashion in an Oscar Wilde manner, "so intolerable that we have to alter it every six months." It's getting divorced from meaning and utility, and worse yet, constancy. Nobody wants to relearn UX for your crap app just so you can be cutting edge with sliders that resemble the phases of the moon.
I fully support the proposed initiative.
You'd push one of those buttons in to select a station and it'd stay pressed. When you push another button in to choose another station, the previously pressed button would "pop" back up/depress (thereby "unselecting" itself), thereby enforcing the mutual exclusivity of a station selection.
Preset radios came in a huge variety and some of them were actually round. Car radios (the radios that have stuck around the longest) need big and bulky buttons so you can operate them without taking your eyes off the road, but some home radios had smaller, circular buttons instead.
The "radio" buttons I used as a kid were small, rectangular sticks poking out of a metal plate that you pushed in. Every brand had their own shapes and designs. Unfortunately, I can't find any pictures of older radios on the internet because every image searching site seems to have been overtaken with badly generated AI art, stock photos, and cheap, plastic "retro vintage" Amazon listings.
I have a browser where I configured "border-radius: 0 !importent" as userContent.css for fun. Was sometimes surprised how much it is used. Especially how many circles are today actually boxes with a large border radius.
HTML is all about rectangles. If you want circles, your choices are a straightforward CSS border-radius, or an SVG <circle>. And let me tell you, if you can just slap style="border-radius:50%;overflow:hidden" onto an <img>, or faff around with <svg>, <image>, <clipPath> and <circle> (or maybe you can even use clip-path="circle() fill-box" these days, can’t remember if support is there yet), I know which a sensible person will prefer.
Does the current ISO 9241 cover that topic?
The three recent main losses of clarity/usability seem to be: 1) links no longer visually identifiable, 2) changes applying instantly instead of only when pressing apply/ok and no cancel button to revert, 3) now the loss of visually identifiable checkboxes.
Shouldn't things become easier and more clearly identifiable to use with todays user base of 100% of mankind compared to limited few persons 30 years ago? Why is the opposite happening?
It's like the companies rolling out UI elements don't even bother running them past people, and are guided solely by what the design department thinks looks cool that day.
Clickable things should have some minimal skeuomorphic detail and scrollbars need to be a minimum of some thickness.
* Officially called the McAfee Antivirus, but I've never understood why
I go to Windows, terrible GUI choices.
I go to Linux, GNOME makes terrible GUI choices. (Thank God for KDE)
I hear about Mac, terrible GUI choices.
Did all the people with experience in graphical user interfaces die off or retire?
Option buttons don't have any direct replacement that I can think of, you just see them incredibly rarely. My guess is that they always were one of several possible means to have the user select from a set of choices, the other prominent ones being a plain listbox widget or a combobox/dropdown widget - or of course, just use plain buttons.
For some reason, designers seem to prefer plain buttons or a dropdown for this usecase today.
You seriously overestimate the average competency in UX circles.
The algorithm outside Apple is basically "what would Apple use here?".
The algorithm inside Apple is basically "what will make people talk about us?"
Serious studies are for boring people. Design hipsters don't want to look boring.
Ahh why didn't I take interface design as a career :)
The radio-buttons prior all included an additional inner circle to imply a selected state. You can't just have empty and filled, since filled could be off, and empty could be a filled circle over a filled circle, in other words on.
La, the prior was only good design because it was common design.
What can I say? The world (of computing) changes under our feet.
Nostalgia on Sunday morning...
The better UI would be for the circles to be visually connected somehow to illustrate that only one selection is possible like you have in physical switches with more than two positions
This is an interesting point. Radio buttons are kind of weird in terms of their initial position because unlike with checkboxes, there's no way to get back to the "empty" state where none is selected. It took me a bit to wrap my head around what you described, but the more I think about it, the more it seems like a "slider" with clearly marked stopping positions. If it's too confusing for people to have some sort of "default" option, maybe having a different color for the part of the slider that's moved based on whether it's in a valid position could help; at the top of the slider, it could be one color indicating "must be moved", and then when you slide and drop it at one of the marked options (or click the option; it could move automatically to the position like a scrollbar), it changes color to show it's valid.
Re. the missing default - you can have an explicit element "none selected" with the slider positioned there
Plenty of options to make UI more intuitive
http://hs.windows.microsoft.com/resbox/en/6.2/main/9f04b9c9-...
It's not the exact design you describe: The slider is there, but only the label of the selected option is shown, the other options are only represented as tick marks.
I think there are two problems with the design though, (which would also still be there if all labels were shown):
- The slider widget back then was normally used for selecting continuous numeric or at least interval scaled input values: That's what the mechanism of dragging it with the mouse was developed for. It could be configured with a small number of discrete values as options, but then dragging became awkward: Either the ticks were spaced very far, then you had to drag the cursor a long distance before there was any kind of visual feedback at all - or the ticks were spaced closely, like here, but then dragging the slider to one specific tick became difficult.
- It's possible to click the slider, but there is no visual indication that you can do so. In fact, the visual indicators are almost inverse to how you'd need them: The selected option has a big handle that you can not click (only drag), the unselected options have no handle though you can actually click on the empty slider bar to move the handle in that direction.
I guess that's why they never did this again after this one try - which is sort of a pity, because you could probably build a redesigned slider widget optimized for discrete input that solved those problems.
https://techcommunity.microsoft.com/t5/image/serverpage/imag...
Normally they are within a radio button group so that they are visually connected: https://i.stack.imgur.com/03p3T.jpg
Some things are swipeable with no indication, or long pressable with no indication, we've removed scroll bars almost everywhere so no indication that something is scrollable unless the content gets cut off and you have reason to try to get to the rest of it, but sometimes it aligns nicely so you assume that's the end. Links and buttons we not only removed the underlines from but now they're grey which historically meant disabled... So no, none of this is intuitive.
A related issue with radio buttons and check boxes is that in some GUIs, clicking the label next to the box/button also clicks the widget, but there was no visual indication that that is the case. Sometimes the clickable area even extends the whole width of the window. This carries the risk of users making a selection when all they wanted to do was to click the window in a seemingly inactive area to make it come to front.
I think we could solve that issue and visually connect radio buttons by placing them onto a background rectangle with rounded corners — thus adapting a visual cue from the button group widget. Then highlight the background portion that is clickable when the mouse hovers over it, and when the button/area gets clicked. Further, you could choose to make the colours consistent with those you'd use for selecting items in lists.
One solution to selectable labels would be to add the indeed missing indicator, e.g., you could have the whole label have a border when it's active (though in this case maybe you don't need radio buttons, but just have multiple lines that look like distinct lines?)
Hard to access the background group, I know it doesn't work if it includes labels like in the screenshot in another comment, but maybe only for buttons it'd be more understandable
We should have never put configuration in the same place as presentation.
Presentation is what you are telling the user. Configuration is what the user is telling you.
By mixing the two together, we have muddled the context of both. What is your configuration presentation meant to say?
1. The user has rewritten (present/past tense) your set of declarations. This shall be read as a positive:
[x] volume muted
[x] unsubscribed
[x] volume mute
[_] unsubscribe
This is why configuration files are so well-regarded. The context they exist in defines the tense of their contents. Somehow, we never invented the GUI-equivalent of a filesystem, and we are all the more confused for it.
The irony is that some of their hardware has painfully sharp corners, the one place where rounding them would greatly improve comfort --- anyone touched the edges of a MacBook or Mac Mini and thought "why did they not smooth these off"?
I brought it into an employment center for critique, and my mentor informed me that those shapes all had different meanings and functions. It was a wake-up call for me.
I am not a UX/UI designer, so my experience with the UI elements in applications had been intuitive, and moreover, disconnected from the activity of authoring a non-interactive document.
So I believe that these UI features were imitating paper-based forms. Those ovals or circles on Scantron sheets: you'd better not fill in more than one per line! And being named "radio buttons": yes, if you pressed "AM" then the "FM" button popped out. If you had six presets in a car--wait a minute, those were oblong...
I have never heard of this. It sounds dubious, like those “flower language” lists which are all different.
is it on or is it off?
erm, hard to tell
so let's put a little mark inside it to show its on. a little mark. a check mark. you know, like a check box.
ffs
WIth that, it might make sense to reevaluate if they're still a useful UI language idiom, and if the different handling is still necessary.
Radio buttons don’t have a check, they have a filled circle inside.
I tend to agree with "stick with norms" vs the "I like it how I like it" crowd, but I'm old and lived through this change; most in this industry only know the latter.
There should be no “radio buttons” only checkboxes and then use select menus for exclusive selection.
Physical push-in radio buttons have not been in new cars since the 1970s. Even digital radio preset buttons are gone now.
Select menus, the kind that popup when you click on them, are unambiguously exclusive-choice menus. Just use those.
In general, I'm not worried about this. To the extent that it is confusing to users, and to the extent that confusion causes problems, it will be corrected in time. Nobody is incentivized to have bad UI if it costs them money. People on HN seem to think designers run everything, and that they spend most of the day trying to make things harder for users (out of native malice, or because it makes them feel smart). The reality is that in most places, designers actually want things to be better, and product choices are driven exclusively by money made by users successfully using your app. "We can't fix our bad UI because it will make our designers angry" is not something I have ever heard said at any company I've worked for.
Duh, obviously it's a quantum-radio button!
UI design has had some really questionable 'improvements' over the years.
I always thought everyone was mimicking the 1984 Macintosh on this.
Or, alternatively, I could just not put up with Apples crap and use something else ;-)
I thought this article was going to be about the replacement of checkboxes by toggle switches, and was displeased to see that it was about something even worse.
Maybe a circular checkbox was more approachable in user testing than squares.
not a todo list then..
I think a lot of this design thinking is stuck in the past, and we should be able to challenge and throw off some of the shackles or crutches that made sense back then, but might not anymore today, in order to advance and give priority to different goals.
In this specific case, it should be clear that you can select multiple options from context or by text, or it should be encouraged to try it out (i.e. easy to undo). If you need to rely on the visual difference of the icon, then you've already lost more than 50% of the people who don't realise this.
My thesis is that this visual difference is only useful to a select, minority group of people who have an above average level of interest in software, who would even be aware of it. Yes, they were probably the target market decades ago, but nowadays software caters to a wider group than that, and I wonder if you would survey a group of "normies" how many would actually rely on the visual distinction in any way (even just supportive).
I'm late 30s and I remember being confused about the difference between "radio buttons" and "checkboxes" when trying to learn HTML4 when I was young - even the name "radio button" was back then already only something older folks would be able to understand, why it's called that way. The distinction, even conceptually, was more confusing than helpful. It's really just a property of a list of checkboxes, how many you can select, not an entirely different class of UI component.
To continue on from my first sentence, and conclude my argument, this whole article does not contain a single good reason why that visual distinction is important in 2024. The closest I could find, is this line which implies confusion: "There was a brief confusion up until 1986 when Apple used rounded rectangles instead of circles". Just the fact that the article has to describe the difference and show visual examples, tells me that this is just no longer a concept that's important, as it may have been 30 years ago, from when it originated.
Instead, it only makes references to "tradition", "convention", "internal training", or arguments from authority such as "art director says so".
I think that kind of supports my point - in the context of UI of 2024, the only reason that one would keep the distinction visually is for tradition, not for any actual practical reason anymore, or the practical benefits that may still be there have diminished in value so that they don't outweigh the downsides or extra constraint anymore.
Not really at all. Radio buttons are part of a group so 3 radio buttons are related and exclusive, there 3 check-boxes represent 3 different unrelated things. The typical example is selecting your gender/sex , you use a radio btn group and put 2 radio buttons or if you are less competent dev you recreate this with checkboxes, scripting and extra validation.
There’s a real productivity benefit to learning and using standardized interfaces. The rest of your post reads like an appeal to “closed mindset” theory.
If you had better points than, it doesn’t matter, idea is “old”, and/or people can’t learn, well you made them poorly.
It seems like you're saying that because there isn't anything inherent in the visual difference, it is better to remove the difference entirely and force everyone through a less efficient mechanism with higher cognitive overhead.
> If you need to rely on the visual difference of the icon, then you've already lost more than 50% of the people who don't realise this.
Agreed, but how does having a visual difference mean forcing people to rely on it? The visual difference is purely an augmentation, and one that kicks in early enough that it prevents people from forming an incorrect mental model. At least for some percentage of people—you're saying 50% here, I would hazard at least 95% (of people at least a little familiar with using graphical interfaces). And the remaining 5% aren't being left out in the cold, they can always experiment.
> It's really just a property of a list of checkboxes, how many you can select, not an entirely different class of UI component.
I completely disagree, and in fact I think this is probably the fundamental error. You are talking from an implementation point of view. From the point of view of a user, they are being asked to input very different things. They are picking from a set of options, or they are accepting/rejecting each item in a list of things. It includes a distinction between one and multiple, and I hope you don't think those are handled the same way in our brains. ("Sorry, dear, I thought she was one of my wives.... oh, right! You're the only one I have! I guess I forgot again.") The fact that they can both have a superficial manifestation as a list of options makes it more important, not less, to visually distinguish them. Radio buttons have more in common with a single-selection dropdown than they do with a list of checkboxes.
Now, I don't subscribe to it in full. There needs to be room for innovation. To my taste, it was quite boring when all software looked literally the same. Nevertheless, I agree there needs to be some reason too. Some short time ago every new app looked like a new game where you needed go through a tutorial to learn the basics. That was probably too much.
But, I don't know, as of late it feels like this iteration comes to and end, the apps start being intuitive again and reuse some patterns. The sidebars, user menus, etc. all in the same place. Mostly.
So, yay discoverability and intuitive use. But that doesn't mean we can't innovate in UX, while keeping it intuitive. Just not the "Maybe later" abusive way, please.
There's no reason to abandon the toggle button/checkbox distinction, though. They're still used distinctively, there are common practices to indicate those distinctions that go back decades, and I don't see any need to unify these controls.
But yeah, fuck round checkboxes. Shows the people driving now are more business oriented and have no love for the culture.
* red is "on" and by default already selected, black is "off";
* black is "on";
* saw one cookie consent form with red meaning "on", and green meaning "off".
It should always be grey = off, darker = on.
Cookie consent forms are specifically designed with all sorts of misleading and user-hostile patterns, so I would not take them as an example of anything. I'm sure there are consent forms out there with checkboxes where checked means no.
I have done tons of toggles that are not reactive, being a form submit
I can implement a radio button that allows multiple choices also, doesn’t mean it is the right thing to do.
Now there are of course exceptions to the rule. One case where instant reaction on checkboxes are common is filters in online stores. I think that’s a leftover design from the days you had to actively click search on each change to the filters. Those will work equally good with toggles.
https://storybook.react95.io/?path=/story/controls-checkbox-...
I think the ternary checkbox has two uses: when it's a master checkbox, showing whether all of the binary checkboxes in a group are selected, and it may also be used on its own (the UI may have different actions for the three possible states).
There is a nice visual distinction for toggles, as if you have an "On" and "Off" column for each option. Then again that idea would have a conflict where it should be a radio circle because you can't be both On and Off, but a checkbox square because more than on option (row) could be On. Maybe a shape with a flat top and rounded sides (a "stadium") would be good for following the conventions while being worse and more confusing overall.
For me it's that the "on" and "off" state are styled inconsistently and can be difficult to guess without toggling. Whether a checkbox is checked or not is never in question.
> There is a nice visual distinction for toggles, as if you have an "On" and "Off" column for each option.
Except there is no such column, so the visual distinction is not self documenting, whereas a checkbox or radio very much is.
- they don't know the difference between radio buttons and checkboxes
- they know the difference between radio and checkboxes, but don't care
I don't know which of those is worse.
I used to hate it (still do a little) when I toggle a checkbox, then go to hit "Save" and realise that the checkbox had immediate effect.
Now I observe that this is almost the norm. I guess I need to get over it.
I also hate it when people changed the scrollbar behaviour in any way. Then today I realised that one of my micro-frustrations with eclipse is that some UX genius decided to make the scrollbars fade away if there is inactivity. (Inactivity of a few seconds in an IDE is pretty normal - it represents thinking!).
But then I reflect that eclipse is a hard core programming tool, used by exactly the kind of people I would have expected to hate on this kind of thing. Instead, it seems that this highly technical audience is OK with this.
This article is absolutely on the money, and using rounded checkboxes is deliberately sabotaging one of the few strong mental models that we are able to hold about a UI.
But maybe this battle is over, and the UX enshittifiers have won.
lol. eclipse is a bucket of rusty panels held together with duct tape, but embedded companies that can't afford software devs and have never heard of UX/UI cling to it.
That said, is this behaviour actually Eclipse's, or is it following the settings of your OS? Windows 11, macOS, and probably some Linux things, decided that scrollbars are not cool and should be hidden or shrunk — but there should be an option to disable that (in Accessibility settings in Windows, in Appearance on macOS). Eclipse might also have its own setting.
It is just running in circles. It took Microsoft 3 releases to insert a background color selection in Win 10. I think that around Win 12 it will regain the option for foreground color. /s
One of my favorite mess ups is the latest redesign of Google Translate on android year ago (maybe iOS also, don't know). It is so much harder to use than the previous version. People were complaining in the reviews but nobody cares. A modern UI designer with an astronomical salary has done its job and you have to shut your mouth up and adapt... and their responses always like "we are constantly working to improve the experience"
I am DEEPLY offended by this travesty! Why can't we have nice things!? The enshittification is real...