Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.
Mobile Design Pattern: Radio Button
This design pattern is part of the Mobile Design Patterns series.
A group of two or more buttons whose behaviour is mutually inclusive i.e. each button’s state affects that of the others. Only one button can be active at a time.
Tip: The name radio button is derived from the old analog radio controls commonly found in automobiles, which enabled quick tuning of preset radio stations at the press of a button.
Figure: S60 radio buttons.
- To clearly indicate that only one choice can be made from a series of options and ensure the user cannot accidentally break this rule.
- Most useful when the list of choices is small or when specifying a persistent preference or setting. A list query is recommended for single item selection from large lists of predefined choices.
- If designed correctly, radio buttons are easily recognizable, take up minimal space and are simple to use.
- The use of radio buttons can require quite a few clicks on indirect manipulation devices, as activation of all but the first control will require two clicks (see below).
- Present two or more options paired with a radio button control. One option can be pre-activated however this is not mandatory.
- Provide a means for the user to focus and activate either of the controls. Only one can be active at a time.
- On touch devices, tapping a radio button (or its label) immediately activates the control. On indirect manipulation devices, focussing a radio button does not automatically result in activation. The user must focus, then press to activate. This prevents accidental activation while traversing a series of buttons but does result in additional clicks.
Note: Radio buttons are often used to apply persistent settings. In this particular context, there should always be one pre-activated button. This should either represent the application’s ‘default’ setting or a setting which was previously chosen by the user.
Figure: In this example, the font size has previously been set to ‘Normal’. Opening the control therefore places focus on the active setting and its radio button is also reflects this active state.
- Radio buttons are now a very well recognized control. Where possible, do not reinvent the wheel (or in this case the button)—especially if the technology or platform you are designing for already includes a native radio button component.
- If designing custom radio buttons, be sure to design the controls so that the mutually exclusive nature is clear. Grouping the radio controls within a container can be a simple, yet effective way to do this.
- When styling radio buttons, ensure there is clear contrast between the active and inactive button.
Figure: An example of an alternate style of radio button control.
Figure: A. Placing the buttons in a container creates an immediate grouping. B. In the topmost example, the ‘active’ state is far too subtle.