Forms are effective for allowing users to enter information, such as that used in e-commerce transactions, because they provide experiences that are similar to real-world processes in many ways.

Forms facilitate entry of information in three ways:

• Through controls appropriate to the types of information to be entered.
• By providing structure, which allows the user to easily identify what information is needed.
• By supporting navigation, which allows users to move through and between forms easily and efficiently -- and ultimately to submit the form.

Forms are extremely important for e-business and e-commerce. They allow customers to place orders, buy products, register their purchases, receive support, and give feedback.

Creating effective and efficient forms is nevertheless challenging. Why? Because form entry requires time that users would typically rather spend doing something else. In many cases, the users have already decided what they want and they view the form simply as another obstacle. Forms entry also exposes users to the potential for errors and dreaded cryptic error messages.

Meeting this challenge is crucial, because the easier forms are to complete, the more satisfied customers will be. This article offers some guidelines to help you meet the challenge of picking the most appropriate control for each element on a form. Future articles will provide similar guidelines for forms layout and navigation.

Forms and controls

A form is an arrangement of controls that enables users to enter information. A control, such as a traditional text field or list box, is simply a representation of some information element, like a person's name, with which the user can interact. The control provides both visualization for the information and some interaction mechanisms through which the user interacts with the information. Those familiar with the model-view paradigm will recognize controls as simply views of the information elements they represent. Keep in mind that the term view doesn't necessarily imply visual. Views can present information in any way that can be perceived by users. Speech, sounds, and music can also be used in views. So why are controls special? They are special only in the sense that they are pre-defined views of well-known and frequently-used information types. They are typically provided as components in development toolkits to help standardize the user interface of a platform and to facilitate development.

The controls described below are a collection of those typically available in traditional GUI toolkits, HTML forms, and Java Swing. Even though the names may vary, their functions are similar, so a general set of guidelines can be used for all.

As a quick reference, some of the guidelines have been incorporated into tables at the end of this article. The tables and these guidelines should be used in conjunction with the UI design guidelines for the platforms for which you are developing. The intent of this article is to provide you with an appreciation of the user's view and how it can be affected by the decisions you make in using controls.

Back to top

Guidelines

Use controls consistently

Throughout a Web site or an application, use the same type of control for specific kinds of information. Providing this consistency allows users to transfer their knowledge from one form to another and minimizes errors. Users will recognize information being requested more quickly, and they will already know how to interact with the control to provide the information. For example, when a spin button control is used to enter the state in an address, users in Texas might quickly learn that typing "t" twice selects "Texas" (the first "t" skips to "Tennessee," the second to "Texas"). If the spin button is used consistently for state fields throughout a site, then this user shortcut will work every time.

In general, you should:

• Use the same type of control for common types of input.
• Ensure that each type of control looks and behaves the same everywhere it is used.
• Provide the same messages and error recovery techniques for incorrect/incomplete data.

For example, always use two radio buttons for "Male/Female," as opposed to using radio buttons in some forms and a two-value spin button in others. When space and layout considerations override the use of the optimum control, substitute a similar control that uses less space. For example, substitute a drop-down list for a list box. Most of the interactions, such as cursoring and selecting, are identical, so users should have little difficulty with either form of list.

Provide a prompt for each control or group of related controls

Clearly identify each control so users know exactly what it represents and what they can enter or select. Use a prompt (or label), typically in the form of text, located near each control. If the control is part of a group, such as a group of radio buttons, provide a label for the group as well.

A prompt near each control is preferred over a prompt within the control for several reasons.

  

When a prompt is used within a control, you can't supply a default value. Default values help users avoid unnecessary input and potential errors. Placing prompts within controls also complicates visual scanning for fields that need input. If most, but not all, fields have prompts near the controls, then users might miss those controls that have prompts contained within them, causing errors. Even though it is not always possible to assign a default value for a field, it's not a good idea to have some prompts outside and others inside. A useful prompt tells users something about the entry they can make or the choices they can pick. For example, a prompt might tell users to enter a phone number using all 10 digits and without punctuation. When the prompt is in the control, users must type over or replace it and this useful information is lost. Finally, if a user returns to a form where previously entered user data is preserved, the prompt is no longer present to identify the contents or the instructions for the control.

Use controls that allow users to choose rather than type

If some or all of the possible values for a field are known within the system, use a control that presents options, such as a list, rather than one that requires users to type. Selecting an option is typically easier than typing a response, and is much less error prone.

Avoid using selection controls for actions

Use selection controls -- such as radio buttons, checkboxes, and lists -- for general information, settings, and parameters as opposed to actions. Actions should be consistently represented using push buttons. When selection controls are used for actions it's not clear when the action is actually performed, whether immediately when the action is selected, or when some subsequent push button (such as OK) is selected.

Choose the correct control for the situation

Use the control that works best for the situation. Choosing the right control can mean the difference between a satisfying user experience and one that results in frustration. Following are some guidelines for choosing the most appropriate control for a variety of information needs. These guidelines are also summarized at the end of this article.

Spin button
Use a spin button to allow the user to select one choice from a small number of choices when space is at a premium. A spin button presents a list of choices, but it is not the ideal way to present a list because the user can only see one choice at a time. The primary reason for using a spin button rather than one of the other list controls is to conserve space, but the drop-down list box might be a better choice. When you use a spin button you are making a tradeoff of space versus ease of recognition and selection.

Avoid using spin buttons for frequently used selection lists, choosing instead a list box or other control that shows all or several choices at the same time. Use spin buttons for less frequently used selections that don't warrant the expense of the extra space. Keep the number of choices small -- fewer than 20, for example, otherwise users will find scrolling the spin button to be tedious and error prone. Limit the length of each choice to about 20 characters so users can quickly recognize choices as they scroll through the list. The choices can be any alphanumeric text but it is important that the choices represent consecutive values in an ordered list. Since users can only see one choice at a time, the sequence of choices should be well-known by users so they can anticipate the next choice in the sequence as well as how many choices the list contains. If users understand the sequence, they will be much less likely to inadvertently scroll past the desired choice. For example, you might use a spin button to allow users to specify how frequently an alarm is to sound, as shown below:

In this example, however, the range of possible values isn't obvious. Is the maximum 7 days, 99 days, or 365 days? Additional prompt text can help users anticipate the maximum.

If users are allowed to enter their own text in addition to picking from the list of choices, make the spin button editable following normal text selection and editing rules for entry fields. For example, allow users to double-click to select a word, or use the mouse to swipe-select characters, then overtype them with their own text.

Check box
Use a group of check boxes for a small number of choices when a multiple-choice response is allowed. Limit the number of check boxes in a group to a relatively small number, such as five to seven, to facilitate visual scanning and selection. The choices should be static, that is, not changing each time the user sees them. If the choices need to vary, use one of the list controls instead. The label associated with each check box can be textual or graphic, but it should be relatively short. Check boxes in a group should be aligned in neat rows and columns to facilitate visual scanning. Since a group of check boxes uses a fixed amount of space proportional to the number and size of choices, keep the number of choices small and the labels short to minimize the space required -- but not so short that they become cryptic.

In the following example the user can choose both visual and audio notifications when e-mail arrives. When checked, the "Audio notification" checkbox activates, or makes available, a file name entry field and "Browse" dialog. As shown here, it's a good idea to indent other dependent controls as a visual representation of this relationship.

You can use one checkbox by itself for a single-choice selection of opposite choices, such as those that can be answered with "yes/no," "true/false," or the "not" of the indicated choice. In this example the implied unchecked value is "Disable Press-to-Select.'

Since the label of a single checkbox will only identify one of the two choices, make sure your users understand what the unchecked choice means. It would probably be inappropriate to use a single checkbox for the choice "A4 Paper" for example, because the paper size represented by the unchecked state would be ambiguous to most users. If there is any doubt whether users will understand both choices from a single label, use two radio buttons instead. Then both choices will be explicitly labeled.

Radio button (option button)
Use a group of radio buttons when only a single choice is allowed, and when one choice must be selected. Limit the number of radio buttons in a group to a relatively small number, such as five to seven, to facilitate visual scanning and selection. The choices should be static; they shouldn't change each time the user sees them. If the choices need to vary, use one of the list controls instead. The label associated with each radio button can be textual or graphic, but it should be relatively short. If available, use a value set for graphical choices to provide a more pleasing visual presentation. Radio buttons in a group should be aligned in neat rows and columns to facilitate visual scanning. The following example shows four radio buttons surrounded by a group box that provides the prompt for the group. Avoid using too many group boxes because they contribute significantly to visual noise that distracts users from seeing the choices. In densely populated dialogs, windows, and forms, the judicious use of white space surrounding labeled groups can be much more effective.

Since a group of radio buttons uses a fixed amount of space proportional to the number and size of choices, keep the number of choices small and the labels short to minimize the space required -- but not so short that they become cryptic. Also, since one, and only one, of the choices must be selected, preselect a choice that is likely to satisfy the needs of many users. This avoids an error condition and will speed selection for some users. If there are situations in which the user is not required to select a choice you might still use a radio button group by adding a choice such as "None of the above."

Value set (choice table)
You can use a value set as a more attractive alternative to radio buttons for small groups of choices (under 20, for example) depending on the type and size of the choices. A value set resembles a table in which each cell contains a choice. The choices can be textual, graphical, color swatches, and so on. In a few cases, where the choices are very similar and their representations can be very small, a few hundred choices can be displayed in a single value set. Color pickers, such as the one shown below, are an excellent use of the value set.

Pick a color for the background:

A value set behaves like a group of radio buttons but provides a more attractive appearance by eliminating the radio button graphics. The recommended technique for visually representing the selected option is to show the cell as "pushed in" in a 3-D sense, similar to the way in which push buttons typically show their "pushed in" state.

List box
Use a list box to display a list of choices, especially if the user will see varying content over multiple uses. List boxes are useful for a widely varying number of choices from a few to hundreds, or even thousands. The choices can be textual, graphic, or a combination, with a few caveats. For text choices, use words that help the user distinguish one choice from the next as they scan or scroll throught the list. For example, avoid listing several choices that start with the same two or three words.

Lists should provide cursor movement and scrolling shortcuts, such as moving the cursor to the first choice that starts with a letter the user has typed. This cursor-movement technique is most useful when the choices are unique and distinctive. If the choices are graphical without text, keep the number of choices relatively small, and preferably nonscrolling because users will have to visually scan to find the choices they want.

The list can be either single-choice or multiple-choice. It might also require at least one selection, or may allow none to be chosen. For example, some versions of list controls provide a visual distinction of single-choice versus multiple-choice by showing small versions of radio buttons and checkboxes within the list box itself. If the list controls you use do not provide such an indication, be sure to provide a prompt or label for the list that tells users explicitly how many choices they are allowed to select, or must select, and how to select more than one.

Pick the fruit you like most:         Pick all of the fruits you like:

The size of a list box should be proportional to the size of the window in which it is displayed so that at least a useful minimum number of choices is always displayed (six to eight, for example), and more choices are displayed as the user devotes more screen space to the window.

Drop-down list (drop-down box)
Use a drop-down list for single-choice selections only, when space is at a premium. Because drop-down lists immediately close upon selection they are undesirable for multiple-choice selections. They should also be avoided when it is likely that users may want to compare the choices in one list with those in another.

Pick the fruit you like most:

For example, it would not be good design to use a drop-down list to display a list of wool sweaters and another drop-down list to display a list of cotton-blend sweaters on the same Web page, as some users are likely to want to compare the sweaters available between categories. Be aware that you are making a tradeoff for space versus ease of recognition and selection every time you use a drop-down list.

Combo box
Use a combination entry field and list box (combo box) for lists that are relatively long, or for which users are allowed to enter choices not in the list. If the list is long (hundreds or thousands of choices, for example), help the user close in on a desired choice by moving the cursor to the closest match in the list as the user types characters in the entry field. If users are allowed to enter choices not in the list, accept what they have typed in the entry field as the desired choice when they press Enter or leave the field. An alternative is to use a simple list box including a choice such as "Pick a choice not listed". This choice could then lead to a dialog with the user in which the new choice is specified. The new choice can be added to the list or not, as appropriate for the application.

Pick the fruit you like most (type it if not in the list):

A combo box requires the same space as a list box plus its associated entry field. In situations where space is at a premium, use combo boxes for tasks that users perform most frequently. Consider using drop-down lists or spin buttons for less frequently-used tasks.

Drop-down combo
Use a drop-down combo box when the situation calls for the functions of a combination box, but the trade-off between space utilization and ease of use favors conservation of space. This is a good trade-off when you need more space to make another more important control easier to use.

Pick the fruit you like most (type it if not in the list):

To best understand such trade-off decisions, you should have a good understanding of your users and their tasks. You can then make decisions as to how various controls are presented based on the larger picture, knowing how much and what kind of information users typically need.

Entry field
Use an entry field by itself when the system does not already know or contain a list of valid values. Supply the most meaningful and useful default value possible. The default need not be a constant. Sometimes the best default is dependent on prior user input and varies with the situation. The goal of providing default values is to anticipate and therefore avoid requiring user entry, thus raising productivity and satisfaction.

It is often very important that users understand how many characters they can enter. There are several good techniques for doing this, but they are not always supported by the control set used. One useful technique is the use of placeholders -- one for each enterable character position -- that are replaced as the user types. For example, you could use the underscore character to mark each enterable position. This convention is often used in paper forms, so it has the additional benefit of being easily recognized. Unfortunately, if you are using one of the commonly available sets of controls, ease of use aspects such as this probably won't be supported.

For fields that have commonly-used formats, such as 123-45-6789 for U.S. Social Security numbers, it's useful to show the separator characters. Make sure that, as the user types, the cursor automatically advances over the punctuation characters. In these fields users should not be required to enter, nor be allowed to delete, punctuation characters. If this isn't possible, use separate entry fields for each sub-field. In any case, the goal is to make entry easy and to avoid possibilities for errors. If no in-field techniques are available at least ensure that the field prompt clearly indicates the number of characters that can or must be entered, and whether punctuation should be typed or not.

You should also indicate which entry fields require a user entry. One useful convention is the use of very light background shading inside required fields. There doesn't seem to be an industry-wide standard, but a commonly used convention is the use of an asterisk ("*") character near the field, along with a note indicating that these fields require an entry. Whichever convention you adopt, use it consistently throughout the site and make sure the form clearly indicates the meaning of your convention.

Multiline entry field
Use a multiline entry field to allow users to enter more than a single phrase. Users may expect some keys that are used at the form level to also work in multiline entry fields. For example, users might expect to be able to use Tab, or press Enter to begin a new line. In some cases these keys need not be supported in multiline entry fields. In this case, the Tab key should move to the next control. However, this is probably the best reason never to assign the Enter key to the button that submits the form while the user is typing in an entry field.

If the Tab or Enter key is supported within the field, make Ctrl+Tab and Ctrl+Enter work at the form level. Again, make sure the form instructions and field prompts clearly tell users about these keys so they know what to expect.

Push button
Use a push button to make an action available. The action should be triggered on the release of the mouse button used to select the option. This allows users to change their minds and avoid doing the action by moving the mouse pointer off the push button before they release the mouse button. Push buttons act as triggers for actions and should not be used to represent state. Therefore they should be "spring loaded" or automatically rebound when the mouse button is released. They should not latch in the "pushed-in" state. Even though most of the control sets available support latching or two-state push buttons, users are sometimes confused by push buttons used in this manner. A single checkbox or two radio buttons will provide a more obvious, simple, and reliable alternative.

Be sure to adhere to platform conventions for the order and location of push buttons. In general, the push button that submits a dialog of settings or properties should be labeled "OK." A push button that submits a dialog that starts an action should be labeled with the name of the action, such as "Send" or "Print."

Back to top

Summary

Designers and developers who create user interfaces for applications or Web-based forms must master the intricacies of controls. Controls are a major element in creating the user experience. While a variety of control sets are available for various platforms, there are some common aspects that can lead to a set of good practices in their usage. Many of the common controls have been in use for more than a decade, providing us with a wealth of experience from real users in real day-to-day use. In this article, I have attempted to establish an initial level of focus on choosing controls carefully so as to make the user's interactions easy, efficient, and error-free. Many additional considerations are involved in the crafting of truly usable forms and dialogs. Techniques for cursoring and selecting within controls can be very involved and non-intuitive. Navigation, or cursoring between controls, can also be tricky. The layout of forms and dialogs can play a significant role in determining how easily users recognize what they need to do, and how efficiently they can accomplish their tasks. Both of these topics will be addressed in a future article.

Back to top

Recommended uses of non-text-entry controls

Back to top

Recommended uses of text-entry controls

Notes:

1. Text within the entry field is selectable.
2. Text within the entry field is selectable.
3. Either a list of related objects or the settings for a property.

Resources

• For additional reference (forms and controls) see: HTML 4.0, Java Swing, and GUI.
  
  
• Dick's previous article compares GUI and Web environments, and reveals effective approaches for each that can enable the best possible user experience.
  
  

About the author

Dick Berry is a Distinguished Engineer with the IBM Ease of Use Architecture and Design team in Austin, Texas. His focus since 1980 has been the design of human-computer interfaces, user object models, and methodologies for ease of use design and development. He was the lead architect for several generations of IBM's Common User Access (CUA), a user interface style initially published in 1987. Dick has also been an innovator in designs for visual programming, and the use of virtual-reality techniques to create a productive 3D user environment for office tasks (IBM RealPlaces). Dick has 45 US patents in the field of user interface design. He is an elected member of the IBM Academy of Technology and an author of IBM's Ease of Use Web site. You can contact him at reberry@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Forms and controls
• Guidelines
• Summary
• Recommended uses of non-text-entry controls
• Recommended uses of text-entry controls
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into Web development on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers