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.
Having an Unsubscribe All Lists checkbox doesn't minimize that. It just adds form noise and pointless work for a dev. The minimization already happens with the preceding checkboxes to select each list to unsubscribe from, but that's just as inherent to the form as the desirable feature of being able to keep certain subscriptions while unsubscribing from others in an efficient way.
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.
I think this is about confusing AI like that offered from gmail or iCloud email that will unsubscribe for you if you click on unsubscribe from their respective inbox / application. Fastmail offers this too.
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.
The unsubscribe buttons in email clients are powered by a header that the email includes. Google and Yahoo just started requiring these for all bulk senders (they were previously a best practice only). It doesn’t rely on what the manual preferences page looks like.
This is just a standard unsubscribe header. It's added by the sender specifically for this purpose and has nothing to do with the UI you see. Not everything is AI, but it being the default assumption is funny to me.
I have to admit I've never experienced this. When I check the "all" checkbox it goes and checks all the other checkboxen for me. Maybe I've only interacted with "nice" unsubscribe pages.
I've seen both versions, and whether they check or uncheck all of the other options (behaving like a radio button), both versions are overcomplicated nonsense.
The unsubcribe-all should just be a link or button with its own submit value or URL param (like unsubscribe=all).
It makes no sense to have a checkbox for "Unsubscribe All Lists". That should just be a link. There's no point in adding a redundant form element even if it's only conditionally redundant.
I remember when I designed a list of checkboxes this case was specifically considered. The last one needs to be updated when all of the checkboxes above are checked or one of them is unchecked.
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.
Does green (usually these are blue) mean yes? Every time I see one of these I realize I don't understand them and I'm not even sure they are consistent in behavior. I usually use a context cue to infer what they mean. The dumbest part is there is plenty of room to just write "on" and "off" right on them.
I think it is no coincidence these are the preferred control for all manner of dark pattern setting screens.
Most of us cope just fine, so long as the contrast between the states is clearly different. My colour blindness is anomalous trichromacy, with a perception difference for red-green. Because the examples shared are a bright blue for on and black for off, I can see it just fine, however, I'd suggest making the switches off state back ground the same as the main background in this case. Aesthetically, it looks better.
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.
Not to mention that half the time tooltips don't show up until you wiggle the mouse over them a bunch, and tooltip delays are arbitrarily timed and usually far, far too delayed (often on the order of hundreds of milliseconds when they should be like 10-50ms at most). And my biggest pet peeve about them is that, at least in Chromium-based browsers, they really don't like to go away once they finally show up, to the extent that I can often scroll the page until they're offscreen and they still don't disappear. Or they leave the farm entirely and persist outside the browser window.
Also, most windows aren't eligible for tooltips if they are not the focused, active window. I remember that difference being hard to explain to people when Windows 3.x and Mac Classic used entirely different title bars between the two states and sometimes even "shadowed" the window contents. It's especially hard to explain to today in a multi-monitor world and when inactive windows respond by default to all other inputs except some hover behaviors like tooltips. (I'm a software developer and know all this too well and I still tripped over it the other day wondering why tooltips wouldn't show up in a window and only realizing belatedly that the window wasn't active.)
>> Hover isn’t really acceptable UX since the touchscreen era
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.
I have an older Android (Samsung S5) with a physical hover feature - you literally hover your finger close to the screen and it triggers hover actions like previewing a message or opening a magnifier over text. It is called "Air View"[1] in Samsung lingo, and was coupled with other features ("Air Gesture"[2]) involving moving your hand over your phone to do things like scrolling or waking the screen.
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.
Long-tap to see tooltips is a convention that has been proposed in various incarnations of the Android UI guidelines. The convention was present in very early Android UI guidelines (e.g. Android 4.x); I'm not sure if it still is.
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.
At least that’s how you get tooltips on Android. Of course, tooltips were designed to be discovered by a user hesitating with their mouse over an UI element (sometimes works, sometimes doesn’t), while tap-and-hold on buttons you have to know about, and it’s still scary when the button looks like it could do something potentially destructive and you want to find out.
Depends on who your target audience is. Many applications can still safely assume they are for office workers using a desktop or laptop computer with a keyboard and a mouse.
It is ok; you just have to offer a different UX for each medium. And not every application is done on every medium. I don't code or write long-form on my phone.
Some laptops fold so the mouse/trackpad is inaccessible and/or disabled.
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
And (as a european) i'm reminded of the confusing american light switches which show a light when they are off. Oh, and they toggle in the wrong direction (up is on?).
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).
I'd say in a residential setting our switches make a lot of sense.
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.
> And (as a european) i'm reminded of the confusing american light switches which show a light when they are off.
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?
This reminds me of when i was studying electronics and we had to design a circuit with some purpose. I made a “Light indicator” with an LED a photoresistor and some other stuff.
I guess such interactive elements always show the current state of the system, and when they are interacted with, it changes the state it was in, examples:
1. Social media buttons for upvotes/likes/dislikes
2. on/off toggle switches for features
3. microphone/speaker buttons on desktop OSes
I miss the old convention of showing a button with shadows indicating it's been pushed in vs. showing it with just a flat plane when it's not pushed in. A button that shows that it's been pushed in with a triangle icon means it's playing, clicking or touching it will stop it from playing. A button that doesn't indicate it's been pushed in with a triangle icon is not playing, clicking or touching it will start it playing. Bonus points if there is a small virtual led that turns on when it's pushed in.
Fewer and fewer devices we have access to these days have physical switches on them, though.
As someone who has built media players, the established convention seems to be that the play/pause button shows what the button will do. It hurts me to do "button shows what it will do" every time. But all the other media players I'm familiar with do it this way.
Does anyone know of a major media player where the play/pause button shows what the state is, rather than what the button does?
Not if it's buffering because you know that you have a bad internet connection. Around here, I often see people skip to an earlier portion of the video to check if it is playing or not.
And that is anyway besides the point of consistent UIs' toggle switches describing their state, not their action.
I've been in moving vehicles where opening the door would have been unsafe more than I've been in car fires. I often lock my car when leaving as well which usually unlocked is a bad state to leave it in, that normally happens more often than being in a burning car.
Honestly, if I’m in the car and we’re driving then I want to see a red light for same reason: red means stop and green means go. Or from outside after parking it: will this door open or will it stop somebody.
Red also often means "danger, caution" not just "stop". A red stop sign means "pay extreme attention here, there's danger, please stop and evaluate". A red DO NOT ENTER sign isn't just saying to stop, its saying there's danger heading that direction. If you just stop there its probably not going to end well, So clearly they're signaling more than just "stop".
I'm still unsure, have you been in many burning cars before? More than just moving vehicles?
If you’re inside a car and the car is on fire, you’re not determining the state of the door lock by its position visually.
For people inside the car unlocked is the unsafe position in most cases (leaving, driving.)
(Do car still come doors that don’t automatically unlock when the handle is pulled, if the child safety switch is disabled?)
Yeah my CZ pistol is like that and it’s fucking terrifying because in my mind red means stop or locked. I actually feel more secure with my Glock because it doesn’t have a safety so it’s unambiguous. If I point my Glock and squeeze, I know it’s going to fire.
The red of a stop light makes a lot more sense in relation to the red of a fire mode on a gun when you think of red being "caution, unsafe" instead of just "stop". Just like the red of a STOP sign is to caution you into paying attention of the danger of the cross traffic, not necessarily just stopping.
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.
Or like at a railway crossing. The flashing lights indicate danger, and the barriers drop. According to GP, the lights should flash when the barrier is not dropped, because now it's unsafe, FFS.
At my current workplace (particle accelerator) one control panel in particular has red for "good" as in "this is red, so don't go in here, because everything's fine and you have no reason to". Always amuses me.
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.
With a light switch you can immediately verify that the switch is in the correct position by looking at the light you want to control. Text/labels/positions don't add anything of value. Also, it's usually safe to experiment with the toggle until you get the desired state.
That's generally a rocker switches work on devices in America, e.g. guitar amps: the side that is pressed is "on" or selected/enabled.
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.
Until you encounter a switch that's part of a three-way switch arrangement where up can be on or off depending on the position of the other switch in the circuit.
I've lived with these my whole life, in every place I've lived, plus with one or two switches that were sideways, so the first time I'd ever heard "up is on" was in a comment thread like this a few months ago. I didn't think there was any sort of standard, it's just always been "flip the switch if it's not currently what you want".
> 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.
I’ve seen it a few times on the web with cookie preferences pop-ups, to set your tracking and personalization preferences. Dark patterns to confuse and trick website visitors into enabling all tracking settings.
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.
>> A switch brings in a bunch of double negatives that can be avoided in most cases.
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.
It's rare to see physical switches like mobile toggles. Most switches show both labels with the switch pointing to the label. It's clear what the status of the switch is and what changing the switch will do.
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.
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.
As someone who has no experience with this version of iTunes:
- 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).
> 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.
This can be changed by going to "about:settings" page and setting the option "browser.tabs.inTitlebar" to 0.
That about:config setting is a halfway okay solution for a single app, it loses vertical space however, which is my premium. Optimally I would like a way to (in all applications which has this problem) to _simply show me_ what is a UI widget/button and what part is "inert" draggable window chrome, like this older screen shot where the distinction is unambiguous and clear:
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°).
>> 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.
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.
I think, bizarrely, the control pattern for mute "flows" the opposite way to the control for pause/play. If there's a play icon, and you click it, you expect it to play the video. If there's a pause button, you expect it to pause the video. Going against this pattern, if I see a speaker icon, and I click it, I expect it to transition to a crossed-speaker, and mute the video, and vise versa. That is: the current button state in play/pause reflects the action of the button, while the current button state in volume reflects the state of 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'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.
I think these conventions come from actual players like VHS and walkmans. The play, pause, stop,… where actual buttons and mute was an icon on the status display. Buttons are actions while icons are state. The rare case where there was a mute button, it was toggleable (or have a led on it) and these always reflect the state.
The correct pattern is to use the platform’s native video player because the user is already familiar with how it operates instead of reinventing the wheel with web jank.
It's actually a C++ app related to music visualization and the video player is one for a preview. I agree in principle though, if there were the equivalent of a <video /> tag in ImGui and OpenFrameworks I'd happily use that :)
They probably have a reason why their product is not just a video. They need integration. Going with what the platform thinks should happen, if it even offers such a control, will probably be a UI disaster in its own right.
If you have one button, I think it has to match what people are familiar with, and the major players all show the current state. If you have a volume slider or buttons, the mute button is adjacent to the silent end (bottom or left for me; I don't know whether RTL languages flip volume controls).
For muted audio I think a muted speaker icon on a button displayed in clicked/active state would be the most intuitive version.
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.
This solution is far from compact though, right? If you show it at all times, it takes space and adds clutter. If you hide it behind a menu, it adds extra clicks.
If this was meant (semi)ironically and mainly as a reference to the OP link, then sorry for the earnest response!
For a one-button option, I think I'd like something like a knob pointing to the current state (like a label saying ON), which when clicked would point to the other state (OFF). Both labels should be visible at all times. I think people may understand knobs. I'm an absolute fan of skeuomorphism but you may be able to design something more abstract (but that's a slippery slope so hopefully not).
Not as unambiguous as it sounds. My keyboard has an led that lights up when the speaker or microphone is muted. But the camera only lights up when it is on. Do we want to show when the function is active, or when the device being controlled is active? I would say the latter is generally better, since it indicates a potential vulnerability / exposure. But then we have to deal with security devices!
The LED should be on when the function is on. The function is whatever the icon depicts.
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.
Then we need to standardize how we name functions. For example, never talk about a mute function, but just sound on. All function names should indicating turning something on, and never off, or vice-versa.
I absolutely agree with this. Especially with buttons that toggle state, you need to be careful to use the right terminology. But I think we can say “Mute on” and be understood: TVs would often display text like “Mute on” while silencing the volume and the status would disappear when the mute button was pressed again. Likewise, adjusting the volume should turn off mute, and doing so would hide the “Mute on” text. It bothers me when a website tells me a video’s sound is off or “click the tiny mute button to unmute and listen to this,” I’d often instead prefer that the video start playing without sound to get my attention but then stop and wait for me to interact with it. And if I interact, just throw up a countdown timer that says “Video starting (with audio) in 10 seconds…” and toss in a cancel button. Alternatively, forget the unmute toggle and show a giant volume slider. Let me drag the volume to the level I want it to be at and I won’t be surprised if it’s suddenly unmuted and too loud. We really need to work on these conventions a bit more…
words take up precious real estate and makes the UI look congested/cluttered and is exactly the opposite of the desired clean look. if things are more ambiguous, it is just something for the user to come to terms with. --Jony Ive in some unwritten extract of thoughts
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.
I think this is because the English concept doesn't map into Japanese. I've seen plenty of times where shops would have signs/labels saying OPEN and… CLOSE.
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.
> That was true in the 90’s when you’d post a whole page
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.
lstamour talked about two things, the proliferation of toggles, and the unclear toggle buttons.
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.
> Likewise I thought the article’s punchline was going to be the increasing use of on-off toggles instead of checkboxes.
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.
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.
That's true, but I just can't live in a world where mute goes the opposite way. I'm not aware of a major media player that doesn't cross out the mute when audio is muted (assuming it uses a crossed out icon at all).
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.
> 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.
Fair, but I think there's a middle ground here, obviously an entire screen of buttons on top of a video occludes the content that you want to watch. Even if our visual cortex can handle it, I don't think its desirable if it can be avoided.
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.
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.
Traditionally, the play / pause button is labeled with both icons. It has no need to display state, because the state of playing or being paused is obvious to the user. That button would be telling you the same thing you see by watching your video.
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.
> 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.
> 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.
Huh, that's odd that it got changed. I can't think of any valid case where [no option] checked is part of a set of radio buttons. The user must be presented by a default, their entire reason for existing as is that one of them is checked all of the time.
Surveys are a valid use case for radio buttons that come unchecked by default.
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.
Why would you not use radio buttons? And what pattern would you use instead? I don’t get it …
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.
Because voting is a multi-step process often involving more than one action. I have experienced all the below votes at governmental level, they are not hypothetical to me:
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.
That is such a weird perspective not at all relevant to this discussion.
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!
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.
I think UI in general is changed so often for no reason other than because it's like art to the UI staff. And then others follow thinking that there is a good reason for those changes made by Apple or whomever. And some FOMO in there too.
I don't understand why some people feel the need to attack the only person in this thread who provided context about the change being discussed. You may agree with Apple's decision, or you may not. You might believe that it will have far-reaching negative consequences for the entire industry. Regardless, al_borland sharing the reasoning behind the decision (and linking to the source) is valuable and is the opposite of 'living under a rock'.
I'm not disputing the logical reasoning behind circular checkboxes, I'm saying that if Apple does something then everyone else will follow suit regardless of any reasons.
Apple is the fashion leader and trend setter of the IT industry, everyone else will follow them. It's appropriate to ring the death bell for square checkboxes, given that track record.
You could have posted that opinion as a top-level comment and/or skipped the 'living under a rock' snipe in your initial reply, given they weren't talking about that so they focused on the thing they -were- talking about and no rock needed to've been involved.
Implying the other person is a fool for not already agreeing with you before making your actual point doesn't generally tend to strengthen said point.
Of course, you can have your view and express it in this thread. I just don't get why that needs to come with being rude and confrontational towards the person who simply provided important context.
He did more than that. He also assured everyone that this was an isolated phenomenon:
>>> 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.
Dalewyn's response makes perfect sense in this context.
Exactly. Apple's influence with regards to design and aesthetics is unparalleled, to downplay it is either straight ignorance or naivety.
Everything from naming schemes (iPhone -> Core i3/5/7/9, Macbook -> ASUS Zenbook, et al.), to desktop interfaces (MacOS -> Windows 11 Explorer, GNOME), to phone interfaces (iOS -> Android), to connectivity (rather the lack thereof), to form factor (Macbook Air -> Intel ultrabooks and EVO), to entire markets (smartphones, tablets, portable music players) and more have all been defined or redefined and led by Apple.
To suggest anything Apple does concerning design would be an isolated incident is ridiculous. If Apple says "jump", the IT industry asks "how high?".
This is a factual statement. As it stands, the change isn't part of a larger trend even within Apple itself. It's isolated to a single niche platform that has specific UI constraints where the change actually makes sense. Apple hasn't applied this change to its other platforms, where it could become widespread and influence other vendors. Of course, it's entirely valid to argue that this might change in the future. But again, why resort to personal attacks against someone who's simply bringing important context to the discussion?
> But again, why resort to personal attacks against someone who's simply bringing important context to the discussion?
Because that is an intentionally dishonest way to describe what he's doing? He's bringing context, and he's providing some low-quality opinions. What's being attacked are the opinions. They are not factual.
A change made to a single OS, which was designed around a fundamentally different way of interaction than any other OS they have, that hasn’t been used anywhere else, is not a trend. If they start moving this to other operating systems, then it becomes a trend and I’d agree with you. It is currently a one-off on a niche device, which has UI requirements that differ from the requirements of the past 4 decades, as explained in the HIG.
You’re attacking opinions based on your own opinions and assumptions about the future and how all other companies might react, but that hasn’t happened yet and everyone doesn’t follow Apple blindly.
Apple still doesn’t have touch screens on laptops, a human interface decision based on how a person will interact with the device, and the industry at large has decided to go their own way on this and not follow Apple’s lead.
Apple has been making a mouse with a touch surface and a trackpad for desktops for many years, this is a decision based on how a human will interact with the system, that the industry has also not followed.
There are also UI elements in iOS, especial early iOS [1], that were changed to better work on a small touch screen that were never brought to macOS, or adopted by the whole industry. They have been used less and less as screens have gotten larger and better able to use more standard conventions. The select dropdown is alive and well, despite Apple changing its implementation in 2007, for similar reasons to the stated reason for changing the checkbox implementation on VisionOS.
Apple has, for very specific reasons for a very specific (and niche) OS, started using rounded checkboxes. They have not (so far) started using them in any of their other, major OSes.
The claim that this is the death of checkboxes is at best too broad and too early. The death of checkboxes in AR/VR? POTENTIALLY. That's about as authoritative as I think anyone can claim to be at this point.
I liked this article a whole lot more when I thought it was tongue-in-cheek, but these comments, whoo boy.
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?)
Other eyetracking software solves this and all related problems by simply showing you a pip of some sort where it senses you "looking". It's stupidly intuitive, low intrusiveness (and can go away when it senses you don't need to "look" at anything like when you are looking at a movie screen with no controls on it) and works just fine. Only Apple decides the solution to their broken UI is to break more of the UI.
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.
If someone spends over an hour writing a blog post than the normal expectation is that they at least spend a few minutes confirming the point based on information, or lack of, in publicly available resources, such as Apple design documents.
Well i wasn't defending apple as if they wouldn't make mistakes or couldn't be led by people who don't know what they're doing. My point had nothing to do with the design choices themselves. But if the point isn't obvious, there is no point to be explained.
Apple & elon musk make people on HN act so weird. Sad.
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.
You get downvoted because you argue that Apple definitely has a great idea behind the change. Why do you think that? And what are they doing about the fact that checkboxes now look like radio buttons? All you're doing is paying homage to Apple without contributing anything meaningful.
> You get downvoted because you argue that Apple definitely has a great idea behind the change. [...] All you're doing is paying homage to Apple without contributing anything meaningful.
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.
"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.
When you put it that way, it kind of undermines the snark towards web developers. Of course things are inconsistent, no one is in charge to say “this is the way the platform does it.”
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.
I'm a little confused by your question. The discussion is about which button should be ok, and which should be cancel. The browser will not lay that out for you, you have to pick a layout.
There are some things where the browser will apply platform conventions, but nothing resembling the consistency you'd expect from (well-designed) native apps.
The HTML input element without any styling applied is usually rendered by the browser using the UI conventions of the operating system. But nobody uses bare input elements these days.
<input> has never affected the button order. It also has no concept of primary / secondary button and for the better or the worst, has by default the styling the browser wants it to have, which might look like the native buttons of the current OS, or the native styling of one of toolkits anyway. System colors are not supported consistently too (although I'm discovering CSS4 a has interesting features [1], neat, but Chrome is lagging behind)
Is it? What if you run a foreign app, a half-assed port, or an Electron thing whose developers didn’t check for the OS?
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).
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.
You guys seem to be pinning this on developers, but 90% of this comes from ux designers and sometimes product. Devs are usually "just tell me what to do"
You can if you do it with an A/B test where you can argue about the percentage of treatment, the duration of the test (is the difference persistent?), and do precise time tracking to log how long the user takes to take an action. That'll bury the actual change in a mountain of configuration, documentation, rollout plans, etc.
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.
The first time I heard it was on "trailer park boys" as a "Rickyism" so I suspect it would sneak into more people's vocabulary that way. No idea which came first.
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.
I have heard it referred that way, I didn't use zoomer as a slur.
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.
Ah, that is what that design is called? Heh. I've seen it, among other names, also been referred to as "chalkboard design". It also reminds me quite a bit of the style you use when drawing on flipcharts, and actually of 90s web design; the good parts of it, that is. I like the ideas behind it and the clarity, but I think everything tends to be hideously oversized on it.
Commonly called neo-brutalist ui, iirc. The only issue I have (well not only, but main), is that many have really really large text and it's hard to read. For example: gumroad
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.
I hope not for my sake! Whatever it is I hope it is more reliable and HELPful. I expect it will be more seamless authentication with more general accessibility. Meaning I hope I feel safer proving who I am to the nurse at the desk without having to open a gadget I can barely focus my eyes on, and that the nurse will have the most up to date info. That’s really all that is missing, sounds easy but it’s a cluster fuck of record management. Note that digitally it is better today than it was 30 years ago.
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.
My grandchildren will be begging me to join the hivemind, but my crotchety old brain will complain back at them about how a keyboard and mouse are just fine.
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.
> Extra little borders defining window box corners from horizontal and vertical borders - a distinction that surely didn't need highlighting.
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.
What kills me about macOS is that the window border is now pixel thin, but macOS simultaneously lacks the keyboard shortcuts that exist in Linux for easily resizing.
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.
> Inconsistent pixelly fonts. Black selection border doesn't have consistent widths.
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.
"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
Since ~2013 Apple designers have been throwing over board lots of conventions the company had been itself establishing for decades.
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.
For a few years in the last decade, it seemed that UX design was getting recognized as a serious discipline rooted in user research. Then, somehow, it devolved into fashion. When/why did that happen?
I'm sure there are many exceptions but a decent amount I've seen is portfolio-driven design, where the goal is more to have something eye-catching, unique and interesting that will look good in a portfolio and to show other designers, more than building something well considered and reliable/predictable. There can be a sense, especially amongst more junior designers, that the job of design is to add some style, and that design should be fun and much more like creating abstract art than making sure door handles are in a reasonable place and turn in the expected direction. The end result is, as you say, more fashion than function.
Does anyone have a design inspiration site that isn't this useless portfolio garbage?
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.
If you find out the answer, I've also been looking for that everywhere to no avail. Sometimes I go to websites like https://dribbble.com/ and search "Rich UI" but results are really hit or miss (mostly miss)
Honestly? Install classic software and use it! I needed exactly those sort of references to design a project and knowing I wouldn’t find them on the web, I booted a win95 vm and studied it. My designs improved dramatically.
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.
Maybe a bit cynical and hyperbolic, but the point is good.
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.
> There's no money in making a thing that works well, only in making things that look good.
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.
> There's no money in making a thing that works well, only in making things that look good
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.
1. 99.99999% of management have zero understanding of UX. So their view of UX is basically some designer making it "pretty".
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.
Electron-based applications seem like a hugo factor. When native applications were abandoned in favor of Electron, designers stopped trying to match their designs to established operating system standards and began designing from scratch, with much poorer results, because they didn't have the resources and experience of teams that had worked on major OSes.
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 give my perspective as a designer turned developer. People have always conflated design with “desenho” (drawing). But design is supposed to be more about information architecture. It just so happens that what’s usually trusted to be architected by designers is materialized graphically. But when the whole ecosystem of training and employment robs designers of their impact by not integrating them in both higher and lower level industrial processes, they’re hopelessly left at their corner, with a lot of energy to spend on what they actually have a stake on: visuals.
> Then, somehow, it devolved into fashion. When/why did that happen?
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?
> Since ~2013 Apple designers have been throwing over board lots of conventions the company had been itself establishing for decades.
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.)
I believe these rules should be changed rarely, consciously and very carefully. Perhaps it would be worth it for them to explain their thought process behind revising them in some developer session.
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.
I am quite positive, that (despite this and countless others fun examples to the contrary) the average the UX floor has risen by a lot.
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.
I think your point 2 is absolutely on the nose here. It fits in with broader industry trends in testing and operations.
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.
Mind you, I know this has probably never been the case looking for example at Apple, Google or other shops that worked in similar spirit, but as a mainstream phenomena you have to not look further than the late 90s or early 2000s to find that average programmers in mid tier companies harboured a mix of non-empathy, non-sympathy and user frustration over a complicated interface and a designers call to do something about it, was regularly met with arrogance, a sigh or a frown.
Of course, this can also be credited to the fact that ui design for software was at a much different place in general.
>Since ~2013 Apple designers have been throwing over board lots of conventions the company had been itself establishing for decades.
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.
I blame the human spirit. User interfaces could have been the one thing we collectively agreed to "stop innovating" on and delivered better experiences for everyone. People are unable to stop innovating. People paid to look at design can't just say, it's done, we did it. And now I fully expect for the rest of my life I will need to explore an increasingly complex labyrinth user interfaces for which I will one day be unable to figure out.
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.
Me too! I had assumed that 'radio button' was a bastardization of 'radial button', referring to the very shape which the author notes is conventionally used for them.
I bought a Macbook in 2015 because I always loved their UI design. Safe to say, whatever's going on with Apple Notes was not what I had in mind.
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.
I chuckled when switching to dark mode on this website. The result is hilarious. When clicking it the page becomes dark and your cursor becomes like a flashlight. Definitely doesn't help with reading. Feels like it's a statement against dark mode. I love opinionated blogs like this.
If it is round, it isn't a checkbox, it is a checkhole.
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.
This makes me rethink the idea of buying i-things for my grandma, thanks. That said, I see her struggle with android-based devices everyday. Both get shittier and shittier with years, we just tend to suffer less due to the boiling frog situation.
TIL radio buttons were named after the physical buttons used on older radios to select preset stations[0]. IMO they look nothing like the actual buttons on radios.
Yeah the name definitely refers more to the functionality/behavior of the buttons.
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.
That wasn't anything to do with radios though. That was just the way mutually exclusive buttons worked. I had a portable tape player where the playback controls were the same way.
We have controls that mimic the actual radio buttons in the form of toggle buttons (buttons that stay depressed after pressing them), but in many APIs the programmer needs to toggle the press state of all other buttons in the group to use them.
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.
If I think of square checkboxes I think of sharp corners. Maybe I should write an article "In Loving Memory of sharp corners" because I definitely miss them but they seem to be extinct from the modern Web and GUI in general.
If I skim the article only old screenshots contain sharp corners. None of the new once.
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.
> 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.
If I remember correctly Borland claimed compliance with some standard for the TUI toolkit provided as part of Turbo Pascal. I cannot remeber which ISO it may have been, or if details like checkboxes were covered by it.
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?
Windows 95 remains the pinnacle of clear, discoverable GUI.
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.
Lots of educational institutions and public libraries used it here in Britain. I think it was good at squeezing a few years of extra life out of the hopelessly underpowered machines that they bought, but I rather think removing the myriad copies of Java Updater and the McAfee Virus* would have been more effective.
* Officially called the McAfee Antivirus, but I've never understood why
Pretty much so, yes. It is cheaper to just get some random dude on Fiverr who has no clue about GUI design, but can whip up something pretty that impresses the manager who has no idea about UX and GUI design either.
My impression is that in modern UIs, both checkboxes and option buttons are being phased out: Checkboxes seems to be replaced with apple-style toggle buttons, which I guess are more intuitive for some people?
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.
Toggles are actually not that bad as a checkbox replacement. But I feel they convey a lot of meaning through color (in iOS, sliders turn green when selected), whereas checkboxes reimain immediate even in b/w. I wonder whether people with severe colour blindness have any issue with that?
Ahh why didn't I take interface design as a career :)
Small nit: I'm pretty certain the Mac System software from pre-1.0 up until System 7 had identical UI widgets for things like check boxes, radio buttons, buttons, etc. The screen shot in the article is from the Control Panel desktop accessory (DA) which is showing radio buttons in a compressed or stylized way because of the compact nature of the DA
> That’s why it’s common to see radio buttons containing checkmarks
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.
Not to mention the confusion arising from checkboxes in web pages used in place of checkmarks. A checkmark alone should be the correct object to use for output only, while a checkbox normally would accept an input from the user. I don't recall where, but have seen this some times around the web and found it misleading.
While the checkbox is less confusing than a lot of toggles (eg, the ones in Windows' settings are bad), relying on the unintuitive distinction between a circle and a square is just one of those bad old UI traditions that, I guess, persist until the next tech generation, little to love here.
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
For mutually-exclusive buttons with the labels inside the buttons, there exists such a convention: Group the buttons together with no space between them. Sometimes, the corners of the buttons at the far edges are rounded but the lines between them are not.
You will often see these in word processors, for aligning text ( left | centred | or right ).
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 seeminglyinactive 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.
The text alignment buttons work because you know you can't have both centered and left, otherwise relying on subtle spacing would mostly signal some connection, not mutual exclusivity (similar to how those | symbols group related buttons together)
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
I thought there was an actual difference in presentation back in the days toolbar buttons actually had borders, but no, when you look at https://winworldpc.com/res/img/screenshots/6x-a08a659bdbb00f..., Word 6, you see it’s all just simple grouping of toolbar buttons, nothing to do with mutual exclusivity at all: New|Open|Save, Print|Preview|Spellcheck, Cut|Copy|Paste|PasteFormatting (if my memory serves me correctly?), …, AlignLeft|AlignCentre|AlignRight|Justify, Numbered|Bulleted|Dedent|Indent.
I thought it was true when compared alignment group with bold/italics, in the Word Ribbon UI they do seem to have less space separating them, but then in Wordpad the paragraph button next to alignment group seems to have the visually very similar space width and the icon is very similar, so there is no way such poorly perceptible convention helps even if it does exist
> 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.
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.
Not always. I've seen plenty of forms that are like "only fill this section out if XYZ" and if you accidentally start before reading that you're screwed.
Could be a slider with the same radio circles denoting the stopping position, could be those circle volume buttons with labeled marks, could be non-circle switches like these (other/position/steer on the right) https://img1.wsimg.com/isteam/ip/b81ca6f4-730a-4561-852c-096..., etc
Re. the missing default - you can have an explicit element "none selected" with the slider positioned there
> 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
Nope, this group tells you nothing about the fact that these are mutually exclusive, you could just as well group checkboxes because they are all related to some "Icon"
Your disrespect for tradition will vanish the moment you’ll feel old and software that you were proficient with becomes inaccessible chunk of nonsense for no clear reason.
Or my disrespect for tradition will get reinforced when the old chunks of nonsense are replaced with something I can get proficient even when I feel old for the clear reason that it's so intuitive even the old folks can grasp it
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.
What we never talk about is how we could have avoided this entire mess in the first place.
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
2. The user declaring a set of future changes to your set of declarations. This shall be read as a negative:
[x] volume mute
[_] unsubscribe
Neither of these is guaranteed to be unambiguous. Neither of these is even expected to tell you which one it is!
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.
Apple seems to have been one of the main forces behind the trend of adding rounded corners everywhere in UIs, which frankly is a style I don't like at all.
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"?
That's a matter of preference. I like the sharper iPhone forms more (4, 5, the first SE, 12 and onwards). I also love the sharp look of Mini and iMacs (especially the 2007 - 2015 ones).
I think maybe the concept of () vs [] for radio buttons and checkboxes respectively is in part due to the mathematical concept of a bounded number range where the numbers at the end of the range are included inclusively or exclusively. I'm not saying they're the same concept, but that it might have inspired their usage. Just a theory.
Around 2015, I authored my résumé in LibreOffice, and I sprinkled in an assortment of bullet points. Some were indented. I used open squares, filled squares, open and filled circles, right-arrows, stars, etc.
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...
Checkboxes looking like radio buttons is a clear sign of things getting stupid. People defending this aesthetic is a sign of stupidity being trivialized. People being ignorant to the problems the stupidity causes is a sign of a subconscious desire to self-destruct.
I also think the visual idiom doesn't hold up, especially since implementers don't use radio buttons correctly half the time. To help people get the idea that they are possible choices for the same attribute, I like to wrap them in a <fieldset> with a <legend> that explains what their [name] attribute is associated with. I think this is how Win95 did it back in the day too
The only place I've noticed this is Telegram UI, and this really throws me off every time. There's absolutely no way to tell if it's a multiple-choice and since you usually cannot just un-vote in Telegram, it is very confusing.
Good grief Sonoma looks like garbage. Hadn’t looked at side by side comps before. Going to adopt a “don’t hire designers from Apple” policy like the old “don’t hire product people from yahoo” policy.
This sort of thing has been an "issue" forever. I remember reading a similar thing last century about WYSIWYG systems vs. layout systems a la TeX/LaTeX.
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.
Years ago, when Apple made all the icons in the Finder sidebar grey and then thin outlines, it became obvious the focus is about just changing things to set trends and ignoring the basic rules of usability. I still can't find what I'm looking for as quickly without the colors and strong shapes instead of monochrome outlines.
Though I have seen a few instances of it happening, I don't see a widespread lack of square checkboxes. I think he's cherry-picking. But then I spend more time on the web than in mobile.
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.
they are replaced by those slider-switch that came from mobile and are supposed to resemble lightbulb switches. A specific type of switch that seems to be popular in america, and it s hard to immediately grasp for most others
Have you never mistaken a checkbox for a radio? I have not. At least not to the point I’ve noticed. Consistency within an app is important, but done well, I think it’s okay to break with conventions.
I'm mostly surprised Windows defaults to rounded. I know their UI is a complete shambles but they seemed to be leaning towards non-rounded user interfaces over the last few years.
This blog's neon yellow color scheme makes it unreadable. Luckily, it has a dark mode... which is unusable on mobile. Ironic this post about design is on a blog that's poorly designed.
Is there any realistic way to keep big, influential corporations from imposing their bad UI choices on the rest of us? Can we at least get the word out to everyone else that this is not a fad worth copying and making into the new standard? (I'm looking at you, toggle switches, skinny scrollbars on desktop UIs, and the white wasteland UI designs that don't put any kind of borders between different sections of the screen.)
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.
I'm missing a good reason why the distinction needs to be made visually clear. More about this at the end.
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.
If you have to “try it out” to understand the interface for each program you’re wasting everyone’s time. No loss in giving clues to those who understand either.
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.
You seem to ignore the fact that people ignore ux advices. You can ask them politely, but they'll still slap something together and call it a day. And there's no way a complex control that you described can get into popular ui libs. Or to be approved by all "designers". These default looks of type="radio" and type="checkbox" are the last stand. If you break it, you'll complain even more but nobody would listen still. Cause defaults and easy ways rule the world. Accessibility is a rough battle already even without ideas that definitely won't work.
>It's really just a property of a list of checkboxes, how many you can select, not an entirely different class of UI component.
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.
> 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).
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.
I remember reading a book about UX years ago, and one of the fundamental principles there was the discoverability and the intuitive use, which boiled down to sticking to conventions that are rooted in everyone's experience. Stuff like using check boxes and radio buttons properly, having the "OK" and "Cancel" buttons in their regular places (and not a "Maybe later"), using unambiguous confirmations (unlike the "Are you sure you do not want to not unsubscribe?"), sticking to the same navigation patterns users see in most other apps.
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 nothing wrong with innovation, of course. A lot of controls needed to change to work well on touch interfaces, like the sliding toggles iOS use(d), and the large, connected touch areas that have replaced the small labels and click targets that computers used to have.
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.
I like the checkboxes and loath the toggle. But after surveying people outside of the tech scene, for anyone with processing issues like ADHD, they report check boxes as easy to misinterpret. Something about the physical movement of the toggle helps them. So I relent and implement toggles.
But yeah, fuck round checkboxes. Shows the people driving now are more business oriented and have no love for the culture.
There is a significant difference between checkboxes and toggles. Checkboxes expect a secondary submit step, whereas toggles have instant effect. https://blog.uxtweak.com/checkbox-vs-toggle-switch/ explains this better. Especially the pizza toppings example, that obviously make no sense with toggles.
Checkboxes can also have an indeterminate state (usually with a "-" in place of the checkmark), like the ones you can see at the below link (and which your link also mentions).
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).
You can...but it will be unexpected for most users and for most use cases. Look at the pizza toppings example in the link above again, it’s a clear semantic difference.
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.
> saw one cookie consent form with red meaning "on", and green meaning "off".
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.
The first time my mother encountered a toggle she tried to actually slide it. I also once saw a website which replaced in a redesign checkboxes with toggles where the cursor changes to a "grab hand" but of cause you cannot grab and slide them need to click it.
Imo it is not intuitive that you have to click toggles and they magically start sliding but you cannot slide them.
I've encountered many toggle switches where you can grab the knob and drag it, but just clicking it will toggle it too.
Sometimes the cursor has changed to a pointing hand.
My particular cultivar of ADHD doesn't have a problem with check boxes, and in fact I dislike toggles for some reason I can't quite identify. That alone is not a very useful anecdatum, but I'm having trouble figuring out what it is that would cause different adhdemons to favour the toggles.
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.
> in fact I dislike toggles for some reason I can't quite identify.
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.
Toggles are better than checkboxes imo, but checkboxes are a lot harder to mess up design-wise. It's really easy to make a toggle that makes it completely impossible to tell if it's on or off.
Much as I love a good rant like this, I have to wonder if this is just the world moving on.
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.
Eclipse is a hardcore masochism tool, try IntelliJ IDEA for Java or just about anything else.
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.
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.
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
It is similar to the introduction of borderless buttons by iOS and Google. User interfaces have gotten so bad that they are hardly useable anymore.
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"
What the fuck is wrong with accepting well established intuitive conventions? How does such an braindead anti-feature ever get past a second person in reviews?
I think the difference with the square checkbox is that it is for desktop UIs and clicking with a mouse. The circle checkbox is for mobile UIs where you are tapping with your finger.
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…