touch-packages team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in
Ubuntu.
https://bugs.launchpad.net/bugs/1211866

Title:
  [sdk] Radio button component

Status in Ubuntu UX bugs:
  Won't Fix
Status in ubuntu-ui-toolkit package in Ubuntu:
  Confirmed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-ux/+bug/1211866/+subscriptions