views:

125

answers:

3

I have noticed a common scenario in UI development (both Web and fat client) where there is a group of radio buttons, and clicking on a radio button means you want to "select" a certain "set" of other controls (for simplicity's sake, let's say they're all text boxes).

Just to illustrate, the asterisks represent radio buttons and the underscores represent text boxes. Each radio button should "select" the "set" of text boxes on the same line.

*   ________   ________  __________

*   ________

*   ________   ________

So translated into UI requirements, this means

  1. Whenever the user clicks a radio button, all the values in text boxes not in its "set" should be wiped out, and

  2. Whenever the user starts typing into a text box, the radio button controlling it should be automatically selected (which also implies wiping out other text box values, as above).

The problem for me is that programming this correctly is surprisingly hard. There are lots of events to handle and the handlers can cause other events to fire, etc.

Is there any "pattern" for this that can be followed?

A: 

Actually, from a usability standpoint I would recommend that you do not wipe out the values in text boxes when the radio button is unselected. When a user is switching among radio buttons, you shouldn’t destroy their work. By not clearing the text boxes, a user can go back to using Option A after Option B without having to be re-entered the text box values.

You may want to disable the text boxes when the associated radio button is unselected in order to indicate to your users that the text box values do not apply. You probably should also make selecting a radio button automatically place focus in the first associated text box to save the user an extra mouseclick or tab keypress. For most cases, this will be as efficient as the user clicking on a desired text box in your original design.

This design also simplifies your code. All you need is to set the enabling and focus in the Update event for the radio buttons.

Michael Zuschlag
A: 

There are lots of events to handle

A small hierarchy of controllers might help. Row controllers responsible for processing events from widgets in a single row and selecting/unselecting a particular row. Row set controller responsible for passing "other row selected" notifications to rows in the set.

One might call that hierarchical MVC (here you are, a pattern :-) ), although this name sounds to me too heavyweight to describe the above.

and the handlers can cause other events to fire, etc.

Looks like the job for row controllers to suppress secondary events fired while selecting/unselecting a row. A row controller knows whether selection/unselection is being executed and can thus dampen the secondary events. Not sure if this is a pattern for that. Maybe a Boolean Flag pattern to indicate that selection is taking place :-)

Rafał Dowgird
A: 

You can use the "Subform" UI pattern and its associated patterns (alternative subform, subform selection, etc.)

You can read an explanation of these patterns here.

andrepf