[sdk] Radio button component

Bug #1211866 reported by Nick Dedekind
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu UX
Won't Fix
Wishlist
Unassigned
ubuntu-ui-toolkit (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Indicator menus support radio buttons.
We should have a component designed and ready for when it's needed.

Revision history for this message
Cris Dywan (kalikiana) wrote :

Is there a design for it?

One example I can see is Wireless, which uses switches but behaves like radio buttons.

Changed in ubuntu-ui-toolkit:
status: New → Incomplete
status: Incomplete → Confirmed
importance: Undecided → Low
summary: - Radio button component
+ [sdk] Radio button component
Changed in ubuntu-ux:
assignee: nobody → Jouni Helminen (jounihelminen)
status: New → Triaged
Revision history for this message
Giorgio Venturi (giorgio-venturi-deactivatedaccount) wrote :

For radio-button type functionality, we have Option Selector and ListItem Selector in the UITK.

Checkbox should not be used for single selection, only for multiple selection

Changed in ubuntu-ux:
assignee: Jouni Helminen (jounihelminen) → Giorgio Venturi (giorgio-venturi)
importance: Undecided → Wishlist
status: Triaged → Won't Fix
Zoltan Balogh (bzoltan)
Changed in ubuntu-ui-toolkit (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Zoltan Balogh (bzoltan)
no longer affects: ubuntu-ui-toolkit
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

A *secondary control* is one that is on the same screen as another control, but is relevant only if that other control is checked or set to a particular value. For example, the various "Exceptions..." buttons in Firefox Preferences.

When they are not buttons (and even sometimes when they are), secondary controls are typically indented immediately under their primary control. For example, in "Time & Date" > "Clock" settings on Ubuntu for PC, "Include week numbers" is secondary to "Monthly calendar", so it is indented underneath.

When you need to make exactly one choice from a group of two or more, and one of those choices has secondary controls, it's generally neatest for that choice to be the last one, so that the top-level options are positioned close together. But sometimes you can't do that. When you can't, the secondary controls end up between two of the top-level options, so an ItemSelector doesn't work. And *that* is why you need radio buttons.

Sometimes the option with secondary controls can't go last because the order of the options matters. A current example is the "Location" settings, both in the first-run setup and in System Settings. The "Using GPS, anonymised Wi-Fi and mobile network info" option has a secondary control: a caption containing a hyperlink. It can't be the last option, because that would mean "Not at all" was the first option, which would wrongly suggest it was recommended. So it has to be first or second, which means that the secondary control has to be between two of the top-level options. In the first-run setup, this is currently faked with checkboxes, which is terrible because the checkboxes are unchecking each other. <http://www.nngroup.com/articles/checkboxes-vs-radio-buttons/> And System Settings currently uses an ItemSelector for the same options, which looks even worse, because the second item is distended and the part of it that isn't the hyperlink is a weird shape.

Other times, the option with secondary controls can't go last merely because there are two or more of them. A future example of this is proxy settings. The top-level choices are (A) no proxy, (B) auto-detect, (C) auto proxy configuration, and (D) manual configuration. Both C and D necessarily will have secondary controls, so at least one of them will not come last. iOS hacks around its lack of radio buttons by using a segmented control for proxy settings, and showing only the secondary controls for the currently selected proxy option immediately below it ... But even if that was a good idea, we can't do the same, because our toolkit doesn't have segmented controls either.

This is just the situation where radio buttons are absolutely necessary for coherent UI. Beyond that, though, radio items are often preferable to ItemSelectors simply because they are not list items, and therefore have a greater visual signal-to-noise ratio.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.