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