Leaving dependent controls enabled

In certain types of UI such as wizards and forms, it's common to see UI like this:

Here the text box is said to be a "dependent control", because its enabled state depends upon the current selected state of the radio buttons.

In situations like the one above, I personally prefer a design that leaves the text box enabled at all times. Instead of using the state of the radio buttons to drive the state of the text box, the design goes the other way: the state of the text box drives the state of the radio buttons.

• The text box is always enabled but is empty by default.
• If the user clicks in the text box and enters any text, the second radio button becomes selected to let the user know that they have now implicitly chosen the second option.
• Clearing the text box implicitly selects the first radio button (but leaves the focus in the text box so the user can enter something new).
• If the user types something in the text box and then changes their mind to explictly select the first radio button, the (non-empty) contents of the text box are left as is. If the user goes back and changes the contents of the text box, the second radio button is again implicitly selected (as long as the text box is non-empty).

This lets the user who wants to enter something in the text box do so directly, without having to first select the second radio button. In my experience, this technique makes the UI feel faster, avoids frustration ("Why can't I type in the box?"), and doesn't suffer any practical downside.

Comments

[Gareth Jones]

I'm in agreement with this.
One supplementary question: What if this was part of a flow-ui - Would you expect that the text was preserved if "Back" was used even if the answer was "No"?

[Paul Farnell]

I completely agree. Amazon get this completely wrong on their sign in page. It would improve every visitor's experience if they selected the "Yes" radio button when you start typing in your password. It frustrates me every time!

[Corey Peterson]

I do see a downside, but it's (hopefully) not a common case: If the user enters something in the field and then selects the other radio button, at that point there's information on the page that isn't getting submitted to the form. At a quick glance it looks like they are submitting that information, since the text field is much bigger than the radio button. This could be a problem if they accidentally clicked the other radio button, or if they did it on purpose but later come back to edit the information, expecting it to be submitted.

[Ishmaeel]

I think the proposed mechanism is the best possible solution for *this* UI design, but I would prefer a complete refactoring of the presentation. When I see a design like this, angry female warriors with bows (wink wink, Paul) flash across my mind for a second and I click the radio button *first*, shuddering with the fear that I might forget afterwards. (I really do forget - must be connected to the perception of text flow direction.)

In the cases I do not see the radio buttons and type away, I would be pleasantly surprised to see that the radio buttons automagically do my work for you - but if I saw the first one activated when I cleared the box, I would be disconcerted for a moment - yes it did anticipate what I would do the first time, but can/will it really do it again? Silly I know.

I would much prefer a single text box with a submit button and a hyperlink below them that says "I don't have a username".

I hope waking up an age-old post with a lengthy comment is not a major no-no here. Sorry if it is.

[Alan71]

The last case (when I thought I had already signed up, but it appears I have not) keeps bugging me.

If I say 'no', it's 'NO', not 'No, but Yes if I click on [Previous]'. This kind of behavior makes me click [Previous] [Next], [Previous] [Next], [Previous] [Next], ... until the dialog also says that 'no, I don't have a user name (maybe I have a user name but no account)' or until I can see angry female warriors with bows.

Maybe a semi-disabled state can do the job... (gray text,... )