Drop-down Menus and Select Boxes

Drop-down menus save space on the  screen when there are more than a few options. However, you shouldn't make the options too long (the optimum length will depend on the layout of your form, but preferably no longer than around 30 characters, unless it's guaranteed to fit on the screen). If the text goes off the screen – as in the previous screenshot – it becomes hard to navigate.

It's worth noting that many users are not aware that they can select items from a drop-down list with arrow keys or using the first character of the item if alphabetically sorted. Therefore, they use a pointing device to select an item from a menu – which can require them to switch from the keyboard if the option is among text inputs.

Ordering of items in a menu should reflect a user's experience . For example, if you're using days of the week or months of the year, put them in chronological order. If there isn't a typical way of relating this information, then alphabetical lists are often the best approach. If there are a few options that are a lot more common than others, you should consider putting those at the top so that users don't have to scroll through a huge list of items; for example, many US sites put the US at the top of a list of countries.

If you have to present a lot of options, consider using hyperlinks or radio buttons instead. For example, here's a long list of countries. The list contains over 240 options, which makes for a very long and hard to navigate drop-down. The preferable option is to use links – here, countries are linked to and grouped by the letter that they begin with (ch02_eg2.htm):

While drop-down menus help you get the data in the way that you want to receive it, you should make sure that it's clear how users are supposed to enter the data. Remember that many users will prefer to enter text rather than use drop-downs , and careful use of the text input controls can be more straightforward than drop-downs. For example, which of the following is a more natural way to enter your date of birth (ch02_eg3.htm)?

While the first option using select boxes may introduce fewer errors, the second method is more likely to be familiar to users. Dates notoriously introduce problems, as Americans are more used to using the format MM/DD/YYYY while European users are more familiar with DD/MM/YYYY. Indeed, both groups also have a tendency just to enter two digits for the year .

You should also be careful when using context-dependent  drop-down menus, where options change based on a selection already made by the user. While they can be helpful, users won't tend to notice that the options change based on other events, and this can introduce errors. We look at context-dependent menus in Chapter 7 .

Some sites make use of the onchange event with drop-down menus, to call a JavaScript that navigates between pages and sections of a site depending on what the user selects from the menu. You should be wary of using these as they can cause problems for screen readers, which will automatically jump to the first option. A solution to this is to use a Go button after the drop-down menu, with the onclick event of the button causing navigation rather than the onchange event of the select box.

Textboxes

Textboxes  are often a more natural way for users to provide information – unless there is a clear and limited choice of options for them to choose from. We just saw a demonstration of this with the date of birth example. Users tend to prefer textboxes as long as they make sense.

Following on from that, generally speaking, text areas should be large enough for users to enter what they need to without having scroll bars appear. The only exception to this is when the user has to enter large amounts of data, such as e-mails or articles.

The use of textboxes might require extra processing on the server, although it's often worthwhile. You may, however, choose to provide users with options when the answer is easily mistyped or when you need to get data in a specific format.

An Aside on Reset Buttons

You should be particularly  careful about your use of reset buttons. If you use one, it should be clearly differentiated and preferably positioned away from the submit button. If the user wants to change a detail, they can often do so by going back and changing the relevant control. Generally, reset buttons are unnecessary unless a user is likely to want to start completely over again on a form.

For example, you could use reset buttons on forms where the same user will have to use the form several times and where the data will be different each time they use the form.

Selecting Types of Controls – Summary

• Where possible , your choice of form control should reflect the experience of users in dealing with that type of information.
• Textboxes are often the most natural way for users to supply information, although it might be preferable to supply specific choices if you need to control the format of the data.
• If you only have three or four choices for the user to select from, use radio buttons or checkboxes over select boxes.
• Multiple checkboxes are better than select lists that allow users to select multiple items.
• Checkboxes are good for Boolean selections where you assume one option, although radio buttons are better for giving mutually exclusive options.
• Do not make items in select boxes too long (over approximately 30 characters wide). Radio buttons are more user-friendly than wide drop-down menus, so they're useful if, for example, you want to provide explanatory text.
• Do not include too many items in your select box, so that it scrolls off the screen: use hyperlinks or radio buttons instead.

Selecting Types of Controls
Usable Forms for the Web
Grouping Controls