Web Bloopers: 60 Common Web Design Mistakes, and How to Avoid Them (Interactive Technologies)

Blooper 22: Making People Type

The text field is the most heavily used component in Web forms. In fact, it is heavily overused . The Web is full of sites that use text fields for specifying structured or constrained data values such as times of day, volume levels, dates, money amounts, and numbers of dependent children. For such data, text fields are too free form. Unless an example or pattern is provided as part of the field label, they give little or no guidance about what values are valid, so it is easy to type an invalid value. They usually check what you type only when you submit the form. If something you typed is invalid, you get an error message like the following:

! Invalid entry. Try again.

Error messages wouldn't be needed if the form allowed you to choose data values rather than typing them. Entering invalid values wouldn't be possible. Unfortunately, many web-sites don't reflect this philosophy.

Figure 4.1 is a data field from a client company's internal Web application for reporting time and expenses. This field has only two valid values: Time ( T ) and Expense ( E ). Users must type one of the two. Lower case t and e are not allowed. There is simply no excuse in this case for not providing a way to choose.

Figure 4.1: Client Web application (Apr. 2002) ”"Report Type" field requires users to type, not choose, T or E. Case matters ” typing t or e provokes an error message.

Radiobuttons are the best way to present this choice, because (1) with only two values, they wouldn't take much space; (2) they show the possible values, so the label wouldn't have to; and (3) they require only one click to set. A menu would also be possible, but (1) it wouldn't show what the possible values are, so the label would still need to show that (2) it wouldn't save much space compared with radiobuttons ; and (3) it requires two clicks to set ”one to open and one to choose.

For a more public example of forcing users to type, try the U.S. Postal Service's Web page for looking up postal zip codes (Figure 4.2). To look up a zip code, you give it the location and click the Process button.

Figure 4.2: www.USPS.gov (May 2002)-Zip code lookup form. State field requires typing, not choosing. Do you know the abbreviation for, say, Arkansas?

A crucial piece of information for determining the zip code is the state. Notice that you can't choose a state, you must type it. Worse, you have to type its standard two-letter abbreviation. Do you know the abbreviation for, say, Arkansas? Luckily, the U.S. Postal Service is here to help you: Next to the State text field is a link that pops up a window with a state abbreviation list, part of which is shown in Figure 4.3.

Figure 4.3: www.USPS.gov (Feb. 2002) ”State abbreviation list (displayed by clicking on link in Figure 4.2). Lists state abbreviations, but doesn't allow users to choose one.

On this list, we see that AK, most people's first guess for Arkansas, is actually the abbreviation for Alaska. The correct abbreviation for Arkansas is AR. However, once you've found the correct abbreviation for the state you want, you'd better memorize it, because you can't choose it from this list. You have to close the list, then type the abbreviation you just looked up into the text field in the form. How helpful!

Avoiding the Blooper

How can you let people choose rather than making them type? The prime directive is this: Spend development effort to save users' work.

Help Users Enter Data

Design forms and controls to help users as much as possible to enter their data. Consider whether it is possible to list all possible values in advance. Even when there are too many possible values for that, there is often a structured way to construct values. Here are more concrete guidelines, with examples:

• Devise data- type-specific controls. Where possible, controls for entering data into a Web service should be specific to the type of data to be entered. ^[1] For example, for specifying a date, provide a date control instead of a text field, as at United.com, the website of United Airlines (Figure 4.4).

  Figure 4.4: www.United.com (Mar. 2002) ”A structured (two-menu) date control and a simple date menu.

• Provide choice. The simplest kind of data-type-specific control is a way to choose one from an explicit set of possible values. Menus are one way to present such choices. RealEstate.com, unlike the U.S. Postal Service website, provides a menu for choosing a state in which you want to buy a house (Figure 4.5), rather than requiring typed state abbreviations. If the choices are few and fixed, radiobuttons also work.

  Figure 4.5: www.realestate.com (Sept. 2002) ”Find Agent form has State menu. Users may not know abbreviations for states they don't live in.

• Augment text fields with data choosers . If you decide to use a text field, try to provide a way to choose a value for it, such as a calendar for picking dates, as at NWA.com (Figure 4.6).

  Figure 4.6: www.NWA.com (Mar. 2002) ”A date text field with an optional pop-up date chooser.

When Type-in is Okay

Requiring data to be typed is often okay or even necessary. It is fine to let users type data if the data is

• Unstructured, such as new user names , street addresses, descriptions, and comments

• Secure, such as user names and passwords

• Internationally variable, such as telephone numbers or postal codes

• Something users know very well and have typed so often that it is in their finger memory, such as their own state or birth date

^[1] In programmers' terms: Online forms and control panels should be strongly typed, just as many popular programming languages are.