Common usability problems and solutions
Jodi Bollaert (Jodi.Bollaert@compuware.com)
Usability Specialist, Compuware Corporation
01 Jun 2002 This article is the first in a two-part series about Web widgets -- controls that can be incorporated in Web forms, dialogs, and wizards to elicit information from users. Here in Part 1, Jodi Bollaert defines several basic HTML Web widgets, shows graphic examples, and discusses common usability problems and solutions. Next month, Jodi will cover more sophisticated Web widgets that can be developed with scripts. What is a Web widget?
A Web widget is a nifty name for a variety of controls that can be used in Web forms, dialogs, and wizards to elicit information from users. While the list of potential Web widgets grows with each new version of HTML and complimentary scripting language, this article focuses on six Web widgets that can be developed with simple HTML 4.01 -- the latest version of HTML approved by the World Wide Web Consortium (see Resources). They include text boxes, radio buttons, check boxes, dropdown menus, list boxes, and more. The beauty of using pure HTML widgets is that they are cross-browser and cross-platform compatible, although they may render somewhat differently. Which Web widget should I use?
Knowing which Web widget is appropriate for every circumstance depends on several factors including:
- User characteristics
- Content
- Technology
David Unsworth of Saga Services Ltd (see Resources)
discovered that a user's age should be a consideration when selecting Web widgets. "I can tell you one result from the many studies I have conducted with dropdowns is that mature adults (over 50) rarely use them, and their navigation behavior is dominated by the use of visible links," says Unsworth. Content will also impact your selection of Web widgets. If users can select from a set of known values, for instance, as the developer, you'll want to present those options up-front in the form of radio buttons, checkboxes, dropdowns, or list boxes, rather than leave users guessing what is acceptable with an open-ended text box. Finally, you should consider technology considerations like target platforms, browser types and versions, screen resolutions, and access speeds. Peter Picone, an independent usability expert, (see Resources) suggests considering where Web widgets are placed at different screen resolutions. List boxes and dropdowns placed too close to the fold may obscure a user's ability to see list items. Spending time up-front understanding users, content, and technology will help ensure that you use Web widgets wisely. Additional information and guidelines are discussed below. Text boxes
Text boxes are probably the most commonly used Web widget. They are embedded within a <form></form> tag, as are all of the HTML widgets discussed in this article. Text boxes are generally used when you cannot precisely predict what a user will enter (for example, first name, last name). They can be designed as single-line or multiline fields (see Figures 1 and 2). Figure 1. Single-line text box
 Figure 2. Multiline text box
 Usability problems
The following section describes and illustrates common usability problems:
Text box overkill
One common conundrum associated with text boxes is overkill -- that is, they are used for everything -- when another type of Web widget would be more usable and efficient. In the pizza order example below (see Figure 3), the user is faced with lots of keystrokes, worries about context-sensitivity, and spelling bee nightmares, as they enter each desired topping in a separate text field. In the more efficient example (see Figure 4), the user only has to enter a checkmark next to each desired topping. In his book, GUI Bloopers, Jeff Johnson also points out that another drawback of text boxes is that they do not often provide clues about what is acceptable (see Resources). Users may not realize they misspelled "anchovies" until they submit the order and get an error message. Figure 3. Text box overkill
 Figure 4. Alternative to text boxes
Disappearing text
Another usability problem sometimes observed with text boxes is disappearing text. This phenomenon occurs when the user's text entry exceeds the text box size (and not the maximum number of characters). The problem is that these text boxes are not long enough. While text box length must be reasonable, users should rarely experience disappearing text. To remedy this problem, the size of the text field (controlled by the SIZE attribute) should equal the maximum number of characters users will enter (controlled by the MAXLENGTH attribute). In some cases, the exact number of characters can be predicted and the text box sized appropriately. (For example, developers can be certain that a text field for a U.S. social security number must allow for nine characters.) In other cases, the number of characters may be less predictable and you'll need to make a reasonable guess. Use a multiline text box if users will need to enter several lines of text. Although multiline text boxes do not support setting a maximum length, you can use the WRAP attribute to avoid disappearing text. If space is not a constraint, make the multiline text box large enough to prevent users from having to vertically scroll to view what they've entered.
Format frustration
A third usability problem observed with text boxes occurs when a user becomes frustrated when it is not clear how text should be formatted. To avoid this circumstance, one simple solution is to pre-format the text box to minimize the potential for errors. A U.S. social security number, for example, can be split into three text boxes with dashes in between (see Figure 5). This pre-formatted approach eliminates the need for users to guess what format the system will accept. Pre-formatting can be helpful for a variety of text box values including phone numbers, fax numbers, and dollar amounts (see Figure 6). Figure 5. Pre-formatted social security number text box
 Figure 6. Pre-formatted dollar amount text box
Figure 7Figure 7. Text box with example
 Radio buttons
Radio buttons are another form of Web widget that can be developed with simple HTML. Use radio buttons when users need to select one option from two or more options (see Figure 8). Radio button options should be related, but are not always opposites. One advantage of radio buttons over dropdowns and list boxes is that all values are visible and only one click is required to make a selection. Figure 8. Radio buttons example
 Usability problems
The lone radio button
One radio button all by itself violates the industry-standard definition that says radio buttons are always presented in groups of two or more. In this scenario, the single radio button is, in essence, trying to impersonate a checkbox (see Figure 9). Although the Web is constantly evolving and rules may seem old-fashioned, they are the foundation of usable Web design. Sticking close to industry standards will make your Web sites and applications more effective and successful (see Resources). Figure 9. Lone radio button
No null value
Industry-standard practice says that radio buttons should include a default selection. The default should be the option that would most likely be selected, or it can be the first option if all options are equally possible. There may be times, however, when users do not like any of the options. If this is a possibility, do not forget to include a null value option such as "None." Include an option for "Any" if any value is acceptable (for example, non-smoking/smoking/any).
Unclear labels
If the labels for the radio buttons are unclear, users will have a difficult time making a choice. While it may be tempting to go with whatever a client wants, a developer with time and a conscience should test label clarity with end-users. If you do not have access to true end-users, do the next best thing and call over the next few people that walk by your desk. Share any problems users encounter with your client and brainstorm better labels where they are needed. In general, radio button labels should be short and succinct.
Too many choices
Too many radio buttons require precious screen real estate and will have users seeing dots for several minutes afterwards. Keep the number of radio buttons to a small number. If you have more than a few options, consider another Web widget such as a dropdown or a single-select list box.
Poor alignment
Radio buttons (and checkboxes) can be laid out vertically or horizontally. Horizontal layouts will minimize vertical scrolling, however, this approach can look crowded. If you use a horizontal layout, make sure the options are spaced far enough part to tell what label goes with what radio button. Vertical layouts, although they require more vertical scrolling, are easier to scan. Checkboxes
Checkboxes are used to set options with clear opposites to "on" or "off." A checked checkbox should mean the option is "on." An unchecked checkbox should mean the option is "off." Checkboxes can be used to set one or more options to on or off (see Figures 10 and 11). Figure 10. Single checkbox option
 Figure 11. Yahoo.com multiple checkbox options
 Usability problems
Unclear opposites
Users should immediately understand the consequence of a checked or unchecked checkbox. To avoid confusion, use labels that are clear opposites (for example, Yes/No, On/Off, Subscribe/Unsubscribe). If the label doesn't have a clear opposite, use radio buttons instead where options should be related, but not necessarily opposites.
Codependent checkboxes
Each checkbox in a group of checkboxes can be turned to "on" or "off," however, changing the state of one checkbox should not change the state of other checkboxes in the group. This practice violates the principle that checkboxes are independent controls.
Long lists
Long lists of checkboxes are difficult to scan. To improve readability, subdivide long lists into smaller groups of nine or fewer options. Use subheadings to label each group. Consider using a multiselect list box if there are no logical subgroups. Dropdowns
Dropdowns are used when you want users to make a single selection from several options (see Figure 12). They are a space-saving alternative to radio buttons; however, users can only see one option until they open the dropdown. Making a selection also requires two clicks (as opposed to one click with radio buttons). If space allows, avoid scrolling dropdowns as this requires even more effort to view all options. Figure 12. Dropdown example
 Usability problems
Dropdown overkill
Although dropdowns may be a bit more interesting to develop, sometimes a simple text field is more efficient. In the article, Should I Use a Dropdown? Sarah Miller and Carolyn Jarrett point out that sometimes it is easier for the user to simply enter text than select from a dropdown (see Resources). How best to enter dates is an often-discussed topic in usability circles. The fastest and easiest method is to allow users to simply enter numbers in clearly labeled fields for month, day, and year. A more tedious approach is to have users select the month, day, and year from three dropdowns. The advantage of the latter method is that users cannot enter invalid data.
Navigation dropdowns
In Microsoft Windows, industry practice has been to use dropdowns for selection. Avoid introducing new behavior for dropdowns on the Web by using them for navigation. If you've used dropdowns for navigation because you can't fit all the navigation options in your graphical user interface (GUI), you probably need to re-think your site structure so there are fewer top-level navigation options. Do not use a dropdown to duplicate your GUI navigation. This tactic just clutters the page and offers little to no added value. If you must use dropdowns for navigation, do not script them so that making a selection automatically takes users to a new page. This unfamiliar behavior can be jolting to unsuspecting users. Make it clear that the dropdown is a navigation widget by pairing it with a Go! button (see Figure 13). Figure 13. Dropdown example
No default
Dropdowns are designed to show a default option, and additional options when the dropdown is opened. Do not waste the value of the default option by leaving it blank or using it arbitrarily. The default option should be the one most likely to be selected. If there's no logical default option, default to a null value such as "Select One" that prompts users to make a selection (see Figure 14). Figure 14. Consumer Reports dropdown with default
No logical order
Finally, interview users to learn how they would expect dropdown options to be listed. The most logical order might be sequential, alphabetical, from most-common to least-common, or some other organization scheme. When deciding on the order, keep in mind that advanced users may use keyboard short cuts to jump down the list. For example, in an alphabetical list of the United States, users can enter "M" for Michigan. The dropdown will jump to and select Maine. The user can then continue to click "M" until Michigan is selected. List boxes
A list box is used to display many options from which one or more can be selected. A small number of options is displayed in the list box window, and a scroll bar is used to view additional options. A single select list box can save precious screen real estate when there are many options. They can also be used as an alternative to dropdowns. Using the list box MULTIPLE attribute, users can select more than one option (see Figure 15). Figure 15. Monster job search multiselect list box
 Usability problems
No instructions
Include a brief instruction at the top of list boxes to indicate whether users can select one or more options. For novice Web users, you should explain how to select more than one option (on the PC, the keyboard combination is CTRL+click; on the Macintosh it is APPLE+click).
Variable length options
As with all Web widget options, list box options should be similar in length to facilitate scanning. The goal should be to make options as short as possible while still being clear.
No logical order
List boxes are similar to dropdowns in that the order of options should be logical to users. Again, the best way to find out what's logical to users is to ask them. Like dropdowns, users can also use keyboard shortcuts to jump down the list of options.
No default
On the Monster job search multiselect list box (see Figure15), there is no default option. To save users a click, it is wise to default to the most likely choice. If the site is personalized for the user, the default could be the user's home state or the last state for which a search was conducted. If the site is not personalized, a logical default might be "Select All." Command buttons
Command buttons are used to trigger an event. Two common types of HTML command buttons are Submit and Reset. The Submit button is used to submit the contents of a form to a server-side program; the Reset button is used to clear a form. A third type of command button, called a Push button, can be scripted to execute a variety of other events (e.g. Print, Delete, Search). (Using scripted Web widgets will be discussed more thoroughly in the next article.) Usability problems
Using reset buttons
A reset button clears all values that a user has entered on a form. According to renowned usability expert Jakob Nielsen, reset buttons offer users little to no benefit and should not be used at all. In his Alertbox column (see Resources), Nielsen points out that users have another choice: To edit the erroneous fields and replace the old text with new text. In most cases, Nielsen believes this option is sufficient. He adds that not including a reset button in the interface also eliminates the risk that users might accidentally erase an entire form.
Inconsistent behavior
It is tempting to use command buttons in a variety of ways. Too many button behaviors, however, can be confusing. On the My Yahoo site, for instance, command buttons are used in the traditional sense and for navigation (see Figure 16). Even though a label like "Change Colors" sounds like a command, clicking on this button actually takes users to a new page. On the Web, standard conventions for navigation are text links, image links, and tabs. On the other hand, the "hide buttons" text link is a command and should be displayed as a command button. Figure 16. My Yahoo navigation command buttons
Inconsistent placement
If your Web site contains a variety of forms, wizards, or dialogs, do not make users relearn your layout every time they see a new screen. Place command buttons in the same general location. Submit buttons should be at the bottom of the screen. Reset buttons (if used at all) are usually close to the submit button. You may want to consider finding a less dangerous place for the reset button to prevent users from accidentally clearing a form. A word about widget labels
Every Web widget should include a label to ensure that users know its purpose. Sumanth Muthalya, a usability specialist in Compuware's Product Division, offers these guidelines when labeling Web widgets:
- End all labels with a colon. The colon tells users where a label ends and a Web widget begins. Colons also improve the ability of screen readers to interpret the label text.
- Avoid self-labeling text boxes. If the user starts to make a text entry, but stops, the label will disappear along with the context for the text field.
- Line up all fields on a left margin (for audiences that read left to right) to facilitate scanning.
- Use at least one space between the label and the Web widget. Use more space if that will help align the widgets as shown on the Detroit News online subscription form (see Figure 17).
- If your labels vary in length, choose a short label alignment point and a long label alignment point to minimize the number of unique margins, and improve scanability.
Figure 17. Detroit News subscription online form
 Other Web widget usability tips
Conclusion
Wow... for a few simple HTML-only Web widgets, there are a lot of usability guidelines to keep in mind. If you think this was heavy, wait until you read about scripted Web widgets! Resources - Saga Services Ltd at http://www.saga.co.uk is a U.K.-based Web information services company for people age 50 and over.
- Peter Picone, an independent usability expert, always has something useful to offer, and can be reached at pbpicone@attbi.com.
- Visit the World Wide Web Consortium at http://www.w3.org to read the HTML 4.01 Specification, section 17, about forms, text fields, buttons, and more.
- Read GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers by Jeff Johnson, 2000, Academic Press.
- Check out Fast Consulting at http://www.fast-consulting.com for their online GUI handbook. Their new Web Application Design Handbook is expected sometime this year.
- Read Sarah Miller and Carolyn Jarrett's paper, Should I Use a Dropdown? Four Steps to Choosing Form Elements on the Web, 2001, at http://www.formsthatwork.com.
- Visit http://www.useit.com for Jakob Nielsen's two Alertbox columns on Guerilla Usability Testing and Reset and Cancel Buttons.
- Check out these sources to learn more about industry standards for interface design:
About the author
Jodi Bollaert is a Usability Specialist (also known as Information Architect) at Compuware Corporation in Farmington Hills, Michigan. She is getting a bit wiser about Web widgets every day while designing Web pages for a large, Web-based tuition reimbursement system. Her previous articles have appeared on developerWorks, CNET and New Architect. You can contact Jodi Bollaert at Jodi.Bollaert@compuware.com.
|
| 
