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.
I’m blind in one eye and it doesn’t bother to point in a consistent direction. I’m curious to see if Apple Vision would work for me or if it would get confused.
Good question. They have alternative input methods in case the vision method doesn’t work for a user, but I don’t know whether the vision method strictly requires a steady gaze with two eyes.
What, you never had to look steadily at a checkbox for a good 3-4 minutes? :-D
Edit: sorry, I had a long enough day that I read the link above sideways and I thought it was a link to the old macOS HIG, not the visionOS HIG. I misread Apple’s reference to their new input system for one of the latest canc ad industry fads.
A more cynical reading: IIRC there is some literature that suggests round corners are less likely to “draw” the eyes towards the corners of structures, that’s one reason why rounded buttons saw some push in the early ‘00s – i.e. it was thought that they were easier to read, as your eyes would focus more easily on the label. For some reason, it seems that in some circles heavily-rounded corners on windows and other containers are now thought to make content-scanning sufficiently more difficult (i.e. by discouraging sequential scanning starting from whatever corner is natural in your part of the world) that it facilitates attention-grabbing via specific window contents. I don’t know exactly how this fad started but Apple’s is like the twentieth euphemism for “rounded corners make it easier for us to steer people’s eyes directly towards our/our partners’ attention grab anchor/ad/allow all permissions button/whatever” I’ve heard in the last two years or so. So heavy container frames see a lot of internal drive now.
Trouble is, sufficiently different corner radii among widgets in the same hierarchy tend to clash visually. You can see that in the screenshots on the linked page, too: OS X Leopard checkboxes are slightly rounded, and so were most UI elements; Mac OS 9 or Windows 2000 were square, and hardly any of their UI elements had discernible round corners.
Few people remember why checkboxes are square anymore but lots of people now “know” that the rounder the corners the better the numbers, so as the window and frame border corners grew, so did those of buttons and checkboxes.
FWIW I find visionOS’ widgets absolutely infuriating (I tried to wireframe some interfaces for a pipe dream project of mine and eww). Apple’s vision (heh) for it seems to have gone no further than uh, we’ll make, like, a phone, but we’re going to project it on a VR canvas. It’s the kind of thinking that Microsoft got laughed at for back in the day. They nailed the hardware, but the software’s form factor is poorly thought out: it is to VR software as the Microsoft Tablet PC was to touch computing, a step forward in technical terms, but not an evolutionary leap, a remarkable technical design that’s being held back by lack of product design vision.
Not the Vision headset itself but I got to play with the visionOS simulator and with this thing: https://github.com/zhuowei/VisionOSStereoScreenshots/tree/alvr to try and wireframe the UI for one of my pipe dreams, a debugger with a spatial interface. The information density you can get with the current widget set is basically at Mac 128K levels except more headachey. The sheer extent of widgets makes any substantial amount of information visually overwhelming and difficult to navigate. As soon as you need to display more than e.g. a video and a handful of sliders or anything of that sort, you either run out of visual field space or have to start splitting things. E.g. there’s just no way to comfortably display a navigable stack trace, a set of locals for one stack level, and a page of code. You can kind of fit them but it seems like it would be very tiring to use.
You can sort of see that in some of the existing apps, and in Apple’s demos as well. All of them show things like a full-screen chat or browser windows, slideshows, several office meetings video streams – basically a bunch of phone screens multiplexed on a canvas.
I don’t think that’s a bad thing in general. This may well be the most advanced model that we can implement well with current technology, and visionOS does it really well. It may well be the thing that’s going to turn virtual meetings from a cool gimmick into something real people doing real work can get real benefits from in an actual professional setting. It’s just… I’d hoped Apple would’ve been able to come up with something more ability-augmenting.
Edit: needless to say, the “I’m holding it wrong” argument may well apply, I poked at this for all of two hours or so. Also, poor information density in modern UIs is one of my pet peeves so I may be more disappointed with visionOS than I should be simply because, while it does a lot of things very well, it doesn’t do one thing I care about as well as I’d hoped. This is an opinion, not an analysis :-).
Oh that’s really interesting. I think I had misunderstood the comment chain. It sounds like the widgets in the Vision are really large, because they’re designed for ocular selection. So they probably work well when there’s only a few controls needed, like on a video player, but not so well for things that are more complex - such as productivity or creative tools. Lightroom, for example, has a lot of sliders.
poor information density in modern UIs is one of my pet peeves
Yep, that’s been my impression so far. I may be projecting my long-postponed hopes for an immersive UI that can replace the stone age point’n’click development tools we’re stuck with that I’ve been fantasizing about for as long as I can remember. But for me, this has been kind of a disappointing ride. The Vision Pro has everything I wish other devices would have – high-resolution display that might actually be capable of showing high-density content, a nice SDK with good UI primitives and good integration with the underlying OS – it’s the first mass-marketed device of this kind that I think you could build a wide range of professional interfaces for. Unfortunately, it looks like it’s limited to Zoom clones. I hope I’m wrong.
Shame about the shape, but I’m just happy that there’s still an empty box that can be filled out with a checkmark. The on/off (or is it off/on?) sliders that are popular nowadays are really hard to understand at a glance; I never seem to know whether they are turned on or off without switching them on/off.
They always reminds me of the Stroop test, where researchers measure incongruity by seeing how fast you can identify color words that are/aren’t displayed in the same color as the word itself.
“The text says On, but it’s also faded, so is it on NOW, or does that mean it toggling will TURN it on?”
Still less than ideal. If you remove color there’s no clear meaning to a “left” or “right” switch orientation. The claim of providing a larger click target is also dubious; many UI toolkits regard the entire label text of a checkbox as a click target, making the hitbox for both controls equivalent. For these reasons I think switches are strictly inferior to checkboxes.
It depends on colour scheme, levels of saturation etc.
It doesn’t understand or respect the fundamental point of the essay here, which is that [_] versus (_)mean different things. The round-vs-square thing is a cornerstone of the original classic MacOS and the Apple HIG, which was also picked up by IBM CUA. The GNOME team, as far as I can see, is ignorant of the real underlying problem here.
The real question is not “how to make ON vs OFF clear?”
The real question is:
“Some choices are exclusive: only one selection at a time is meaningful. Some are inclusive: multiple simultaneous selections are meaningful. How do we visually show that?”
The answer is: checkboxes for things where multiple choices are valid: tick the boxes for things you want. Radio buttons for things where only one choice at a time is meaningful, like buttons on a car radio or an old analogue TV set.
Tick boxes: “I would like eggs, beans, mushrooms, and toast, please. I do not want bacon or sausages.”
Radio buttons: “I want to listen to channel 2 or channel 6. I cannot listen to both at once, so choosing No. 6 automatically deselects No. 2.”
Round boxes meant “just one of these options”. Square boxes mean “tick the ones you want”.
It is literally nothing to do with graphical design trying to make it visually obvious whether something is set or not. This is a wholly different and almost entirely unrelated question.
Round radio buttons date from the original 1984 Mac, or perhaps from the 1982 Lisa. The article says they were roundrects, but really that’s just the best approximation of a circle at that resolution.
Ironically, real-life radio buttons were rectangular (at least in all the car radios I saw them in.)
Ironically, real-life radio buttons were rectangular (at least in all the car radios I saw them in.)
The oldest bit of technology on my desk is a NAD 3020A amplifier. It has radio buttons for controlling the inputs and they are rounded squares. Apparently using squares for them then (1979) was modern and futuristic and made them look modern and futuristic, older designs (’50s - ’70s) mostly used round buttons.
I believe the push towards square buttons came with the adoption of transistors and the accompanying miniaturisation of radios. With valves, the size of the device was limited by the need to cool things and so the interfaces were large to fill up the available space. With transistors, you could make them very small and so needed to fit buttons in that tessellated, which meant that the radio buttons became square. The UIs also became more complex around this time, with saved preset stations and so on.
Early car radios had a dial for tuning and a dial for volume. Buttons for presets and controlling tape recorders came later.
Am I misremembering it, or was this really a common-ish nitpick/complaint against radio buttons at the time? I distinctly recall at least two contexts in which someone told me they thought the name was stupid because they looked nothing like radio buttons (other than their one-active-at-a-time behaviour which only some buttons on some radios had), but I don’t remember if it was a common complaint.
I thought exactly the same thing. I do actually remember some elderly relatives owning a radio set with these buttons, where pressing one popped up the other, but hell if I know what they did (change frequency range?) It seems like one of those vestigial skeuomorphic idioms, like denoting the save icon as a floppy disk.
The one-thing-at-a-time was a common feature for mutually-exclusive functions. For instance, most cassette tape players would have buttons like these for play, pause, and the two rewind directions. Only one of these could be active at a given time, so only one of the buttons could be down at any time.
However, for a whole bunch of reasons, these were rarely round on radios. Mutually-exclusive buttons were associated with a lot of things (my mom’s old washing machine had them, for example), not specifically with radios. When you told someone about radio buttons they expected them to be square or rectangular, not round.
To be fair it always sounded like some pointless pedantry to me. I had no idea what radio buttons were supposed to look like (by the time I’d seen my first GUI radios were so common, and so varied, that there was no single feature or shape I associated with radios or their buttons). I just saw them called that way in a screenshot in a book about Windows for Workgroups or something (OFF MY LAWN I SAID!!), said huh, okay, that’s what they call radio buttons in computer land, and proceeded to never actually think about it ever.
My first car had them :-) Yes, they changed frequency, eg: what station you were listening to.
And yes, that car stereo had a complex arrangement of cams and clutches which meant that not only could you push a button to jump to a preset radio station, you could manually change the frequency with a knob and then pull a button to set that preset to that frequency. All mechanical! The output shaft of this fiendish mechanism drove a variable capacitor to set the frequency.
Also, the windscreen squirter was an actual physical pump. Fifty years is a long time :-)
I actually used to just think they said “radio” but meant “radial” buttons due to the round shape lol. But interestingly, I actually had a radio (well, I do still have it, and it still works!) that has round buttons for its memory recall thing… digital though, so not the ones the internet says gave the name.
But my old house did have light switches kinda like that: a round thing that sticks out. You push it in, the other side comes out and the light turns on. Push the other side back in and the light turns off. But those aren’t related to a “radio”… and today’s “toggle” switches are different.
I kinda wish it was just called a “radial” button tho.
Does “to the right” mean that the switch itself—the part you would be touching if it were a physical control—is on the right? Or that you move the switch to the left so that the piece to the right of that is visible?
This kind of ambiguity is maybe not the worst thing about switch controls, but I think it’s perfectly indicative of how unclear they are.
And that’s before you get to designs where it’s ambiguous which half is which, a style that has become weirdly popular with the advent of cookie popups.
A lot of that is a bit in flux. There used to be a recommendation that the left option meant back and the right option meant proceed in LTR languages and the converse in RTL, but more recent research suggests that humans associated left with backwards and right with forwards independent of their reading direction.
Even if Apple is content to focus on the high end of the VR market for several more years, and end users themselves are not really getting direct exposure to visionOS, I don’t think it’s unreasonable to think that UI conventions from visionOS might “trickle down” to their other platforms. I imagine that Apple employees are much more hyped about the Vision Pro than the average person, and they might (consciously or unconsciously) start to see its UX as the hot new thing they should copy. Of course it would mostly not make sense to do this, but that hardly stopped them from making recent versions of macOS look like iOS. (Consider the rightly-maligned switch control, or the narrow dialog boxes that display all of their text centered.)
It also includes all of the desktop systems: seven versions of Windows and five of MacOS. I’m glad the history of checkboxes has been so exhaustively covered.
(Correction: To be fair, it also gives MS-DOS examples. With that, the history is complete.)
Another way to say this is, iOS doesn’t have radio buttons or checkboxes except in the browser. It has selection state indicators on collection items like photos and table rows—I say indicator because it’s not a control in its own right. You touch anywhere in the collection item to change the selection state.
iOS separately has toggle switches, where you must hit the switch itself, not the table row it’s part of. Switches are physical objects as controls; you can drag to flip them and feel the haptic response.
I place all this is in the “rethink the UI for touch” category, in which you manipulate on-screen physical objects more and manipulate controls less. For another example, you move page content to scroll it instead of adjusting a scroll bar control.
But I do wish multiple selection cases had a square border, when there is any border. On visionOS, I really don’t see the reason for an iOS norm to carry over. Would your gaze be drawn to corners of a square if the corners weren’t sharp? I don’t think my eyes are drawn to the corners of app icons, for instance, and that case shows Apple is no stranger to the squircle curve.
The button shape guidance linked by another comment is about buttons in general; it doesn’t reference any visionOS checkboxes.
The image in the article is of a selection indicator, not a checkbox control. Apparently the appearance came from Apple’s visionOS Figma design library. In that context you could misunderstand what’s interactive and what’s decorative. Extra forgiveness is due because the frame is labeled “Checkboxes”!
In that case the continuity with iOS makes some sense. I still would prefer a square edge for the indicator.
WhatsApp has round checkboxes for polls too, but they also provide a note and an icon above each poll that tells you whether you can “select one” or “select one or more”.
What? Apple uses round checkboxes in visionOS? I am furious.
Apple used to be all about enforcing UI standards and ensuring a consistent UX. What is this fresh hell we’re now into?
This might because round UI elements are easier to select with your eyes, according to https://developer.apple.com/design/human-interface-guidelines/buttons#visionOS .
I’m blind in one eye and it doesn’t bother to point in a consistent direction. I’m curious to see if Apple Vision would work for me or if it would get confused.
Good question. They have alternative input methods in case the vision method doesn’t work for a user, but I don’t know whether the vision method strictly requires a steady gaze with two eyes.
Select with your eyes?? OMG.
Yes, that’s how the entire interaction scheme works on visionOS. Your eyes act as a mouse cursor and tapping your fingers together acts as clicking.
What, you never had to look steadily at a checkbox for a good 3-4 minutes? :-D
Edit: sorry, I had a long enough day that I read the link above sideways and I thought it was a link to the old macOS HIG, not the visionOS HIG. I misread Apple’s reference to their new input system for one of the latest
cancad industry fads.A more cynical reading: IIRC there is some literature that suggests round corners are less likely to “draw” the eyes towards the corners of structures, that’s one reason why rounded buttons saw some push in the early ‘00s – i.e. it was thought that they were easier to read, as your eyes would focus more easily on the label. For some reason, it seems that in some circles heavily-rounded corners on windows and other containers are now thought to make content-scanning sufficiently more difficult (i.e. by discouraging sequential scanning starting from whatever corner is natural in your part of the world) that it facilitates attention-grabbing via specific window contents. I don’t know exactly how this fad started but Apple’s is like the twentieth euphemism for “rounded corners make it easier for us to steer people’s eyes directly towards our/our partners’ attention grab anchor/ad/allow all permissions button/whatever” I’ve heard in the last two years or so. So heavy container frames see a lot of internal drive now.Trouble is, sufficiently different corner radii among widgets in the same hierarchy tend to clash visually. You can see that in the screenshots on the linked page, too: OS X Leopard checkboxes are slightly rounded, and so were most UI elements; Mac OS 9 or Windows 2000 were square, and hardly any of their UI elements had discernible round corners.Few people remember why checkboxes are square anymore but lots of people now “know” that the rounder the corners the better the numbers, so as the window and frame border corners grew, so did those of buttons and checkboxes.FWIW I find visionOS’ widgets absolutely infuriating (I tried to wireframe some interfaces for a pipe dream project of mine and eww). Apple’s vision (heh) for it seems to have gone no further than uh, we’ll make, like, a phone, but we’re going to project it on a VR canvas. It’s the kind of thinking that Microsoft got laughed at for back in the day. They nailed the hardware, but the software’s form factor is poorly thought out: it is to VR software as the Microsoft Tablet PC was to touch computing, a step forward in technical terms, but not an evolutionary leap, a remarkable technical design that’s being held back by lack of product design vision.
Have you used the Vision headset with a UI conforming to Apple’s guidelines? Just wondering what you’re basing your judgement of the widgets on.
Not the Vision headset itself but I got to play with the visionOS simulator and with this thing: https://github.com/zhuowei/VisionOSStereoScreenshots/tree/alvr to try and wireframe the UI for one of my pipe dreams, a debugger with a spatial interface. The information density you can get with the current widget set is basically at Mac 128K levels except more headachey. The sheer extent of widgets makes any substantial amount of information visually overwhelming and difficult to navigate. As soon as you need to display more than e.g. a video and a handful of sliders or anything of that sort, you either run out of visual field space or have to start splitting things. E.g. there’s just no way to comfortably display a navigable stack trace, a set of locals for one stack level, and a page of code. You can kind of fit them but it seems like it would be very tiring to use.
You can sort of see that in some of the existing apps, and in Apple’s demos as well. All of them show things like a full-screen chat or browser windows, slideshows, several office meetings video streams – basically a bunch of phone screens multiplexed on a canvas.
I don’t think that’s a bad thing in general. This may well be the most advanced model that we can implement well with current technology, and visionOS does it really well. It may well be the thing that’s going to turn virtual meetings from a cool gimmick into something real people doing real work can get real benefits from in an actual professional setting. It’s just… I’d hoped Apple would’ve been able to come up with something more ability-augmenting.
Edit: needless to say, the “I’m holding it wrong” argument may well apply, I poked at this for all of two hours or so. Also, poor information density in modern UIs is one of my pet peeves so I may be more disappointed with visionOS than I should be simply because, while it does a lot of things very well, it doesn’t do one thing I care about as well as I’d hoped. This is an opinion, not an analysis :-).
Oh that’s really interesting. I think I had misunderstood the comment chain. It sounds like the widgets in the Vision are really large, because they’re designed for ocular selection. So they probably work well when there’s only a few controls needed, like on a video player, but not so well for things that are more complex - such as productivity or creative tools. Lightroom, for example, has a lot of sliders.
Mine, too!
Yep, that’s been my impression so far. I may be projecting my long-postponed hopes for an immersive UI that can replace the stone age point’n’click development tools we’re stuck with that I’ve been fantasizing about for as long as I can remember. But for me, this has been kind of a disappointing ride. The Vision Pro has everything I wish other devices would have – high-resolution display that might actually be capable of showing high-density content, a nice SDK with good UI primitives and good integration with the underlying OS – it’s the first mass-marketed device of this kind that I think you could build a wide range of professional interfaces for. Unfortunately, it looks like it’s limited to Zoom clones. I hope I’m wrong.
(Fortunately that’s pretty common :-D)
Shame about the shape, but I’m just happy that there’s still an empty box that can be filled out with a checkmark. The on/off (or is it off/on?) sliders that are popular nowadays are really hard to understand at a glance; I never seem to know whether they are turned on or off without switching them on/off.
Sometimes I can’t tell even after I toggle them. Which I think is the point in using them in GDPR cookie walls.
They always reminds me of the Stroop test, where researchers measure incongruity by seeing how fast you can identify color words that are/aren’t displayed in the same color as the word itself.
“The text says On, but it’s also faded, so is it on NOW, or does that mean it toggling will TURN it on?”
GNOME does them right, with high contrast https://developer.gnome.org/hig/patterns/controls/switches.html
Still less than ideal. If you remove color there’s no clear meaning to a “left” or “right” switch orientation. The claim of providing a larger click target is also dubious; many UI toolkits regard the entire label text of a checkbox as a click target, making the hitbox for both controls equivalent. For these reasons I think switches are strictly inferior to checkboxes.
with high contrast
IorOis displayed on the switch.Unless I’m missing something, this looks exactly like iOS.
It really doesn’t, you know.
This is why.
It depends on colour scheme, levels of saturation etc.
It doesn’t understand or respect the fundamental point of the essay here, which is that
[_]versus(_)mean different things. The round-vs-square thing is a cornerstone of the original classic MacOS and the Apple HIG, which was also picked up by IBM CUA. The GNOME team, as far as I can see, is ignorant of the real underlying problem here.The real question is not “how to make ON vs OFF clear?”
The real question is:
“Some choices are exclusive: only one selection at a time is meaningful. Some are inclusive: multiple simultaneous selections are meaningful. How do we visually show that?”
The answer is: checkboxes for things where multiple choices are valid: tick the boxes for things you want. Radio buttons for things where only one choice at a time is meaningful, like buttons on a car radio or an old analogue TV set.
Tick boxes: “I would like eggs, beans, mushrooms, and toast, please. I do not want bacon or sausages.”
Radio buttons: “I want to listen to channel 2 or channel 6. I cannot listen to both at once, so choosing No. 6 automatically deselects No. 2.”
Round boxes meant “just one of these options”. Square boxes mean “tick the ones you want”.
It is literally nothing to do with graphical design trying to make it visually obvious whether something is set or not. This is a wholly different and almost entirely unrelated question.
I wasn’t commenting on the article, I was commenting on a specific comment about the state of a switch being non-obvious.
I know. I got that. The specific thing I was trying to address is what you did in your reply:
(“How does this button look?”)
(it’s not how that button looks; the more important thing is that how all buttons look convey information and that needs to inform the overall design)
(examples: “if I use colour I can make this clearer than a black and white design”, which misses that:
[a] not everyone can see colour
[b] some people see colours differently
[c] some people who can’t see colour don’t know that they can’t see colour
[d] no colour scheme works on all displays
[e] tools in your GUI may change the colour scheme according to time of day and thereby defeat the use of colour for on/off indication
Anyone slightly annoyed that there isn’t a single actual checkbox in the whole page?
Yes. I was clicking on things and they were all non-interactive pictures.
I’m glad I wasn’t the only one!
Round radio buttons date from the original 1984 Mac, or perhaps from the 1982 Lisa. The article says they were roundrects, but really that’s just the best approximation of a circle at that resolution.
Ironically, real-life radio buttons were rectangular (at least in all the car radios I saw them in.)
The oldest bit of technology on my desk is a NAD 3020A amplifier. It has radio buttons for controlling the inputs and they are rounded squares. Apparently using squares for them then (1979) was modern and futuristic and made them look modern and futuristic, older designs (’50s - ’70s) mostly used round buttons.
I believe the push towards square buttons came with the adoption of transistors and the accompanying miniaturisation of radios. With valves, the size of the device was limited by the need to cool things and so the interfaces were large to fill up the available space. With transistors, you could make them very small and so needed to fit buttons in that tessellated, which meant that the radio buttons became square. The UIs also became more complex around this time, with saved preset stations and so on.
Early car radios had a dial for tuning and a dial for volume. Buttons for presets and controlling tape recorders came later.
For what it’s worth, when I was a child my parents had a radio with actual literal round radio buttons on top.
Am I misremembering it, or was this really a common-ish nitpick/complaint against radio buttons at the time? I distinctly recall at least two contexts in which someone told me they thought the name was stupid because they looked nothing like radio buttons (other than their one-active-at-a-time behaviour which only some buttons on some radios had), but I don’t remember if it was a common complaint.
I thought exactly the same thing. I do actually remember some elderly relatives owning a radio set with these buttons, where pressing one popped up the other, but hell if I know what they did (change frequency range?) It seems like one of those vestigial skeuomorphic idioms, like denoting the save icon as a floppy disk.
The one-thing-at-a-time was a common feature for mutually-exclusive functions. For instance, most cassette tape players would have buttons like these for play, pause, and the two rewind directions. Only one of these could be active at a given time, so only one of the buttons could be down at any time.
However, for a whole bunch of reasons, these were rarely round on radios. Mutually-exclusive buttons were associated with a lot of things (my mom’s old washing machine had them, for example), not specifically with radios. When you told someone about radio buttons they expected them to be square or rectangular, not round.
To be fair it always sounded like some pointless pedantry to me. I had no idea what radio buttons were supposed to look like (by the time I’d seen my first GUI radios were so common, and so varied, that there was no single feature or shape I associated with radios or their buttons). I just saw them called that way in a screenshot in a book about Windows for Workgroups or something (OFF MY LAWN I SAID!!), said huh, okay, that’s what they call radio buttons in computer land, and proceeded to never actually think about it ever.
My first car had them :-) Yes, they changed frequency, eg: what station you were listening to.
And yes, that car stereo had a complex arrangement of cams and clutches which meant that not only could you push a button to jump to a preset radio station, you could manually change the frequency with a knob and then pull a button to set that preset to that frequency. All mechanical! The output shaft of this fiendish mechanism drove a variable capacitor to set the frequency.
Also, the windscreen squirter was an actual physical pump. Fifty years is a long time :-)
I actually used to just think they said “radio” but meant “radial” buttons due to the round shape lol. But interestingly, I actually had a radio (well, I do still have it, and it still works!) that has round buttons for its memory recall thing… digital though, so not the ones the internet says gave the name.
But my old house did have light switches kinda like that: a round thing that sticks out. You push it in, the other side comes out and the light turns on. Push the other side back in and the light turns off. But those aren’t related to a “radio”… and today’s “toggle” switches are different.
I kinda wish it was just called a “radial” button tho.
Those old-timey light switches look and act like radio buttons. I wonder if that had anything to do with it.
https://i.pinimg.com/736x/91/3a/a9/913aa96b9b60117c3aa5231048e7aca3.jpg
I hate toggles. Don’t people realize that it’s not clear if left or right is on?
Convention seems to be that on should follow the writing direction, so for English on is to the right. Examples: LTR, RTL.
Does “to the right” mean that the switch itself—the part you would be touching if it were a physical control—is on the right? Or that you move the switch to the left so that the piece to the right of that is visible?
This kind of ambiguity is maybe not the worst thing about switch controls, but I think it’s perfectly indicative of how unclear they are.
And that’s before you get to designs where it’s ambiguous which half is which, a style that has become weirdly popular with the advent of cookie popups.
I meant the handle thingy is to the right.
A lot of that is a bit in flux. There used to be a recommendation that the left option meant back and the right option meant proceed in LTR languages and the converse in RTL, but more recent research suggests that humans associated left with backwards and right with forwards independent of their reading direction.
This is an entire rant that culminates in the expressed doom of the square checkbox now that apple did a thing on an absurdly expensive new platform.
Even if Apple is content to focus on the high end of the VR market for several more years, and end users themselves are not really getting direct exposure to visionOS, I don’t think it’s unreasonable to think that UI conventions from visionOS might “trickle down” to their other platforms. I imagine that Apple employees are much more hyped about the Vision Pro than the average person, and they might (consciously or unconsciously) start to see its UX as the hot new thing they should copy. Of course it would mostly not make sense to do this, but that hardly stopped them from making recent versions of macOS look like iOS. (Consider the rightly-maligned switch control, or the narrow dialog boxes that display all of their text centered.)
It also includes all of the desktop systems: seven versions of Windows and five of MacOS. I’m glad the history of checkboxes has been so exhaustively covered.
(Correction: To be fair, it also gives MS-DOS examples. With that, the history is complete.)
“And if you gaze for long into an abyss, the abyss gazes also into you.“
I question how much it has to do with eyes-and-hands interaction. This has been the case on iPhone all along. You can find it today in Mail and Photos, for instance.
Another way to say this is, iOS doesn’t have radio buttons or checkboxes except in the browser. It has selection state indicators on collection items like photos and table rows—I say indicator because it’s not a control in its own right. You touch anywhere in the collection item to change the selection state.
iOS separately has toggle switches, where you must hit the switch itself, not the table row it’s part of. Switches are physical objects as controls; you can drag to flip them and feel the haptic response.
I place all this is in the “rethink the UI for touch” category, in which you manipulate on-screen physical objects more and manipulate controls less. For another example, you move page content to scroll it instead of adjusting a scroll bar control.
But I do wish multiple selection cases had a square border, when there is any border. On visionOS, I really don’t see the reason for an iOS norm to carry over. Would your gaze be drawn to corners of a square if the corners weren’t sharp? I don’t think my eyes are drawn to the corners of app icons, for instance, and that case shows Apple is no stranger to the squircle curve.
I can’t edit after a long delay so here’s a correction: visionOS doesn’t have checkboxes at all.
The way you make a checkbox in SwiftUI is to apply the .checkbox case of ToggleStyle to a Toggle. The symbol exists only in the macOS SDK. Compare with .switch, which exists on many of their platforms.
The button shape guidance linked by another comment is about buttons in general; it doesn’t reference any visionOS checkboxes.
The image in the article is of a selection indicator, not a checkbox control. Apparently the appearance came from Apple’s visionOS Figma design library. In that context you could misunderstand what’s interactive and what’s decorative. Extra forgiveness is due because the frame is labeled “Checkboxes”!
In that case the continuity with iOS makes some sense. I still would prefer a square edge for the indicator.
WhatsApp has round checkboxes for polls too, but they also provide a note and an icon above each poll that tells you whether you can “select one” or “select one or more”.
iOS’s message has also used round checkboxes pretty much from the start.
Can’t remember reminders (todo list) ever using square ones either.