Selecting Types of Controls

We met the different  types of form control that are available to form designers in Chapter 1. It's important to pick the right control for the information you're trying to collect. Having already determined the information that you need to collect with the form, you can select the type of control that you'll use for each item. Once you've done this, you'll have an idea of the length and size of the form you're constructing.

If you want to allow the user to enter text:

• and it's only a single  line of text, use an <input> element whose type attribute has the value of text.
• and you want the user to enter multiple lines of text, use a <textarea> element.

If you want to limit the choices  the user can make:

• so they can select one from several options, use radio buttons, a select box, a drop-down menu, or a button.
• so they can select multiple items from a set of options, use checkboxes or a multiple select box.

Remember to give your controls  names that correspond to the information that you're collecting from the user – for example, txtFirstName for an input box where the user enters their first name – as this will make development and maintenance of the site easier than using names such as input1, input2, and so on.

It's helpful to use a prefix  for the name of the control that indicates what kind of form control the data relates to, such as:

• txtControlName for textboxes and text areas
• radControlName for radio buttons
• chkControlName for checkboxes
• selControlName for select boxes and list-boxes

In creating your form, you should consider the way in which a user would normally expect to give data and try to take advantage of those expectations. A lot of this experience might come from printed forms and, to a lesser extent, other computer-based forms (perhaps if you are translating a software application to a web application) .

If your form differs from the user's experience, they are more likely to make a mistake that they'll have to correct, or they may just fill out the form incorrectly. A common example that has been demonstrated by Jakob Nielsen (http://www.useit.com) is the use of address fields. When asking the user to enter their address, you should expect them to give the lines of an address as they would when writing a letter or filling in a printed form, perhaps using four or five input boxes. As Nielsen demonstrated, if you try to provide a drop-down menu for the type of road that the user lives in – say offering the options of road, close, street, avenue, and so on – then the user will often have to go back and delete this from the first address line, as they are so used to giving it there.

In fact, drop-down menus, checkboxes, and radio buttons are common choices for designers who want to limit the selections that users can make. However, you have to decide whether this is a natural way for the user to provide data. As we just saw in the previous example, if the form is not designed to match the way in which the user expects to see the data every day, it will take them longer to fill out the form and can potentially introduce errors. While it might increase the server-side validation and/or processing involved, you should present the menu in a way that the user will understand.

Radio Buttons and Checkboxes

As a general rule of thumb, radio buttons and checkboxes will work better than drop-downs when there are few options present – say up to three or four items. With few options, you need not be concerned about the amount of screen real estate they take up, and you have the advantage that all options can be viewed at once. However, consistency does help usability – if you already have a set of drop-downs, then another one might be a better choice than inserting one set of three radio buttons among several select boxes .

Multiple checkboxes are also a better choice than select boxes that allow users to choose multiple items. Users often find multiple select boxes difficult to operate, and most users have to learn how to add more than one item. Checkboxes, on the other hand, are simpler to use and more likely to match their experience.

Radio buttons also make it easier to explain further  information about a choice, compared with drop-down menus. A radio button with a description next to it is better than a very wide drop-down menu. For example, here the options can't fit on the screen when you use a drop-down menu; the radio buttons below it are much more user-friendly (ch02_eg1.htm):

Remember that once you've selected a radio button, you can't deselect it. If your radio buttons represent an optional question , allow the user a way of offering no answer after they have selected one – don't lock them into that option. Also bear in mind that it can be useful to provide an 'other' option if the user is presented with a selection to choose from (in Chapter 7, we'll see an example of activating a textbox when the user selects an 'other' option, so that the user can specify an alternative that you haven't listed).

The advantages of checkboxes over multiple select lists are similar to those of radio buttons over drop-down menus. Checkboxes are also ideal for Boolean selections where you assume that if the user does not check/uncheck the box they agree with your option (such as agreeing that you can mail them with further details). However, radio buttons are better than checkboxes when you want the user to select either yes or no explicitly, as they're given two mutually exclusive options and it's easier for them to see that a choice is required.

Designing the Form
Usable Forms for the Web
Drop-down Menus and Select Boxes