Displaying to the user a radio button before it has been selected

Question

I've always had this problem but never cared to much until now.

Let's say, you want the user to say if the lights were on or off using a simple click. So it's on with the first click, a second click will turn it off.

The problem I see is by default it should neither be on nor off. So nothing is recorded into the db. But as soon as the user clicks the off/on button there will be a record of the lights being on or off.

How should you display that until the user has interacted with the 'switch' nothing will be recorded, then once they have, they can now set the lights to off. But not until they have turned them on first.

Answer 1

I think they should be switched off by default, even if just for display.

If a user must first switch on a light, which will be the first user interaction, to store the value in the DB, it should be turned off by default for display, even if the DB stores a null. This avoids any user confusion as well and works well with the real world scenario where you must switch on the lights for the first time before you can switch it on.

Answer 2

I agree with Divi's answer, and it applies for almost all common use cases.

However I have seen a use case where a parameter being set (in the strange and wonderful world of trading software) needed to have 3 states (unset, off, and on). This was activated with the first click, gaining the "off" state by default, and then switched on by the second click.

The control was a checkbox with 3 states:

• checkbox empty => unset
• checkbox background colour set inside the box => set but off
• checkbox with tick => on

Here is more info on a tri-state checkbox implementation

Answer 3

I'm a unsure whether you talk about a checkbox or a radio box. The title talks about a radio box, but the text (and the answers so far) talk about checkboxes. What these mean to me is below, but let's first turn to the undead state:

Unset State

I wonder why you need an "unset" state. Logically, there can never be an "unset bit". Either the bit is on, or it is off. The database cannot record "nothing", except when you designate a certain bit pattern (like 0x00) to mean "nothing". But what is the meaning of "nothing" in your business context? Does it mean "illegal" (then, validation should not have let it through to the database), or does it mean "undecided" (then, what is the meaning of it in the business process)?

On the UI, you might use a radio box group without a selection together with a validation routine to force the user to make a conscious choice. That's the "illegal" case above. That's appropriate if the choice is very important, and you don't want to rely on a default value which might have bad consequences.

If your program allows to save the nothing-selected state, you'll have to process the "undecided" value later in your business logic. You are adding another legal value, namely "undecided". If you need this, I would replace a two-item radio box group without a selection (o), such as

Preferred Delivery Option: 
o  air
o  ground

with a three-item radio box group

Preferred Delivery Option: 
*  don't care
o  air
o  ground

and select (*) the first one initially.

I'd use the first alternative sparingly, and go for the second one if you have a real "undecided" state. I'd never use a checkbox with meaning UNSET - because the only third state usage I've seen so far is MAYBE:

Checkbox

A single control, usually a rectangular box with a label. The simple one has nothing in it (OFF), or a check mark in it (ON). There are tri-state ones as well, which often indicate the third state using an asterisk, but the meaning is usually MAYBE, and not UNSET. They're used when selecting items in a hierarchy: A higher-level item has state MAYBE when some of its children are ON and some others are OFF.

(The iPhone uses a different metaphor - it uses a slider; no third state possible.)

Radio Box (Group)

Must be a group of controls (grouped by background, frame, or whitespace), each usually visualized as a circle with a label. The circle is filled (ON) or empty (OFF), and in the entire group at most one control is ON, all others are OFF.

Answer 4

MFC/Visual C++ has Pushbutton like radio buttons. I think this could be the right answer for you. Imagine the MS Word buttons for

• Align to left
• Align to centre
• Align to right
• Justified

all not pressed and you have the unset state you are talking about.

Answer 5

As an enterprise UX designer, I have come across this many times. The short answer is preset the radio button by default if null is equivalent to one of the choosable states and the default application state matches the choice. If not, you will have to dig deeper to make a decision. Here is how I would approach the decision.

I would ask these questions:

• Does the null state represent one of the two choices?
• Is there a definitive default choice for your users or the system?
• Do users NEED to make a choice or can they ignore the empty state?
• Do users ever want to go back to the empty state?

If the null state is the equivalent to one of the radio choices and the corresponding application state is set, the decision is easy. Set the radio button to that state by default. This makes the most sense heuristically and is one less decision for the user. This is an even better decision when question two has an answer.

It also, matches your stated example of the light switch. If the user hasn't made a choice, but the lights are off in the room (application state), then the null state equals off. The switch should be set to off when the user first enters the room. Think how confusing it would be otherwise. There is no middle state of the switch.

keep in mind... a switch is different from a radio button set.

So let's keep going. If the null state is different from any radio choice and the null state can persist without adverse consequence AND the choice is not important to the user... keep the radio buttons unselected. It follows the same notion that the user doesn't need to think or decide to proceed. Just make sure the application state is clear (to the programming and the user).

Then ask the final question. Does the user want to go back to the null state? If this is the case, the choice seems important to the user and the radio button UI likely needs support from other UI elements.

This matches the interface that radio buttons got their name from: Car radios.

The radio buttons in cars are part of a more complex interface all with the intention of allowing a user to tune into a radio frequency. If this matches your UI, then try to create an interface around what the user is ultimately trying to accomplish.