What is the best way to gather optional data using radio button groups and drop-downs?

Question

I'm ultimately asking a theoretical question: what is the best experience, in general, for gathering optional responses using controls with mandatory input?

Consider specifically radio button groups. An initial selection from the group is not required, but as soon as the user makes a choice, the user cannot go back to that initial state -- there is no way to "unselect" a radio if he changes his mind. (Eg, an optional question has Yes, No, or Maybe answers -- none of those are chosen initially -- I choose Yes, but decide I want to go back to "no answer" -- I cannot, because radio buttons do not work that way.)

Now consider single-choice drop-downs. They require an initial selection, so designers end up inserting a synthetic blank value to mean "optional". Unlike radio, the user can change his mind and go back to the optional state via the synthetic blank.

This state of affairs unsettles me. Radio should be uncheckable to go back to the optional state, and drop-down shouldn't need a synthetic value to indicate optionality. But such as it is, so I see these common implementations:

1. an optional radio button group with no default (there is no _common_ way to go back to the default state once you choose one, so this is a flawed approach)

   Optional: The question is...
   ( ) Choice A
   ( ) Choice B
   ( ) Choice C
   ( ) N/A
   

2. a required radio button group with the 5th "optional" choice selected

   Required: The question is...
   ( ) Choice A
   ( ) Choice B
   ( ) Choice C
   ( ) N/A
   (*) Don't know, or I will come back later and answer
   

3. a required drop-down with all listed options plus a blank one indicating the "optional" choice

   Required: The question is...
   [___________ v]
   |             |
   | Choice A    |
   | ........    |
   | Choice Z    |
   | N/A         |
   +-------------+
   

All that said, here are some specific questions:

1. Considering the disadvantage to 1 (there is no common UX to un-toggle the radio back to the "non answer" state if you change your mind after toggling one of the listed states), is there any advantage to implementation 1?
2. Are there other implementations than these that afford better usability? Eg this one, where the user is required to stipulate whether he wants to answer now or later, and if now, then is required to choose one of the values:

   The question is...
   ----------------------------------------+
   (*) My answer is          ( ) Choice A  |
   ------------------------+ ( ) Choice B  |
   ( ) I will answer later | ( ) Choice C  |
                           | ( ) N/A       |
                           +---------------+
   

3. Is it more usable for implementation 3 to explicitly list the "optional" choice and select by default, or leave as a blank entry (as is common experience)?

Answer 1

I have just taken a screenshot from a dialog in Microsoft Powerpoint, where you can edit headers and footers. If you select the checkbox "Datum und Uhrzeit" (date and time), then the radio button group with the options "Automatisch aktualisieren" (update automatically) and "Fest" (fixed) becomes active - with the initially selected radio button. If you don't select the checkbox, the radio buttons are greyed out and have no effect.

I think this is better than adding a third radio button with the caption "I don't want to insert date and time", as you would need a whole sentence to explain what this option means. The checkbox doesn't need a complex description - checking and unchecking immediately triggers the options to appear or to be greyed out, making clear what it means. Simultaneously, it leads to a meaningful division of the dialog.

Answer 2

I totally agree.

I like optional radios, i think the best way is just to implement optional radios!

Even though they are non standard, Its better for some use cases because it makes it easier to skip things (leave everything blank) and deselect things especially if there are a lot of radios and all you know is you want to undo your choice.

Also having every radio unselected by default is important sometimes if you don't want to bias people's decisions (people are more inclined to just leave a form as is if they don't care).

Unfortunately you're right in that they are non standard and browsers have undefined behaviour for radio groups left initially unselected (sometimes they select the first) http://www.w3.org/TR/html401/interact/forms.html#form-controls

Answer 3

I'm struggling with the "N/A", but I may have missed something about it's intended purpose.

If it acts as a trigger to move to a next question then consider lifting the "next" script and placing it on a "Next >" type button. On clicking Next, you could interrogate if an answer has been attempted and message accordingly to prompt a "Skip". Of course, it would be more elegant to place a "Skip" button on the UI, which would remove the irritation of constant messaging/alerts while browsing through the questions. That then leaves a mechanism required to skip back; a "< Back" button.

It depends on whether you believe the same freedoms afforded in paper tests apply to the on-screen paradigm of MCQs and general information gathering forms: that people are trained to read through a paper before attempting the questions so might reasonably expect to be able to do so on a screen?

I may have misunderstood here - but give the user the control. I hope this helps in any case. Good luck. I know these projects can be both exciting and frustrating - don't forget to test your UI with living people, too! They're darned unpredictable and inconvenient at times, but help to distill winning solutions over time :)