|< Day Day Up >|
Sometimes it isn't possible to let people point and click to choose what they want. Sometimes you need to have them type text into a field: search terms, addresses, phone numbers , names , passwords, or comments.
If your website contains text or number type-in fields, your Web software must of course check what people type to make sure it is valid. But to be friendly and helpful, you have to tolerate reasonable variations in what people type. Unfortunately, text fields on many websites are intolerant. Users of such sites often see error messages like the one from Microsoft.com (Figure 4.7).
The same client company internal Web application mentioned in the previous blooper provides a good example of a very intolerant text field (Figure 4.8).
The Week Ending Date field wants dates in the form DD-MON-YYYY. Notice that the Month part of the pattern is "MON," not "MMM." That, and the character length of the field, suggests that "14-1-2000" would be a valid date. "
It isn't. The date must be typed with a two-character day (with a leading zero if the day is nine or less), a hyphen, a three-letter month abbreviation, a hyphen, and a four-digit year. To specify January 4, 2003, you'd have to type "04-jan-2003." Any other form of date provokes a stern error message.
Especially bad is the fact that "valid" dates won't really fit into the date field; they scroll it sideways . This would actually discourage people from using the form's only allowed format for dates.
United.com often commits the sin of not accepting data in familiar formats. In Figure 4.9, we see that Frequent Flier numbers are rejected if entered in the format that United itself uses on Frequent Flier cards and printed mileage statements. Another form at this site rejects credit card numbers that include spaces. Those spaces are in those numbers for a reason. They make it easier to scan and check the numbers. Let us type them!
A friend pointed out a frustrating intolerant form at the California state website where citizens apply for unemployment benefits. The application form requires users to name their most recent employers but won't accept characters other than letters and digits. This makes it impossible to specify employer names that include nonalphanumeric characters, such as AT&T and Excite@Home. My friend had to type in her former employers as "ATandT" and "ExciteAtHome," which probably caused other problems in the processing of her application (Figure 4.10).
An amazing example of form intolerance comes from Sony.com. Assume you've bought a Sony product and want to register it. You go to the Product Registration page (Figure 4.11) and type the product number exactly as it is shown on the packaging and in the owner's manual: CCDTRV58 NTSC. You fill out the rest of the form and click Submit. Up pops an error message "Please remove spaces from the model number."
At this point, you might wonder , Why can't they remove the @%&# spaces and go on? But they don't do that, so you remove the space from the model number (Figure 4.12) and click Submit again. Another message appears: "The model number you entered was invalid."  The message doesn't explain what is wrong with the model number now, but a menu is provided, allowing you to choose a model number. You might wonder why this menu wasn't provided to start with.
You click open the menu, and there is your model number (Figure 4.13), free not only of spaces, but also of hyphens, which neither error message mentioned. You choose it and sigh with relief as the form is finally accepted. Are experiences like this conducive to customer loyalty?
As comic relief from so many intolerant forms, let's look at one that's so bad it's funny . Intel.com is the website of Intel Corporation, maker of computer microchips. The Intel Developer Forum subsite has a Feedback page for sending feedback to the webmaster. The form asks for the URL of the page about which you are providing feedback (Figure 4.14). However, until recently, the URL field wouldn't accept more than 35 characters-which means it wouldn't accept URLs for most of the pages at the site. It wouldn't even fit the sample URL at the top of the page!
The irony is, to give them feedback on this blooper, you'd have to supply the URL for this feedback page, but you couldn't because the field wouldn't accept it! Fortunately, a recent site update corrected this blooper.
Why are all these websites so intolerant and uncooperative? Why are they so picky about what people type? Why can't they even accept data in common formats-even just one-or in formats that the companies themselves use elsewhere?
One common excuse is that it is hard for programmers to write software that can interpret and accept data typed in anything but a single very simple format. Perhaps, but consider how many user hours are wasted for each programmer hour saved. More to the point, consider the traffic and revenue lost because of intolerant, annoying forms. Consider the impression you give your customers when your website rejects model numbers typed exactly as they appear in your own packaging and literature. They get the impression that your company is lacking in organization and coordination.
Fortunately, the guidelines for providing user-friendly, tolerant type-in fields are not too complicated.
Match field length to data. The visible length of a field should suggest the length of the data to be typed. It needn't be exact, because that would create ragged looking forms and isn't feasible anyway because of variable-width typefaces . What is important is that fields be (1) long enough to hold their data and (2) not a lot longer than that.
Accept common formats. If the information has a common, accepted format, allow it. If there are several common formats, allow as many as is feasible. For example, a time field could accept times in any of the following formats: 12:30 am, 12:30 AM, 12:30 a, 00:30, 00:30 h.
Accept your own formats. Accept data in the formats you use elsewhere. For example, if your printed product codes look like "ZX-4563.33 QR," your Web forms should accept the codes in that exact same format.
Beware of rejecting legitimate data. Think hard about who might be using your form. Customers from Canada or the United Kingdom, where postal codes include letters, would be greatly annoyed at an order form that required a "zip code" but rejected letters.
Make letter-case irrelevant. If you expect users to type codes that include letters, and if letter case is not significant for the data, users should be able to type either uppercase or lowercase into the field. Using the previous example, users could type either "zx-45..." or "ZX-45...."
Provide a pattern. Give an example of a valid format, for example, "DD/MM/YYYY," or "Sample Serial #: QP00275-5559." Put it somewhere right next to the field: above it, below it, or on either side. See Northwest Airlines' website, NWA.com , for an example of a data field that provides a pattern (Figure 4.15).
Figure 4.15: www.NWA.com (Mar. 2002)-Date field with a pattern for valid dates.
Structure text fields. Unless you must allow different-perhaps international-formats, build the format you want into the form by structuring the text fields. For example, if you are absolutely certain that only U.S. phone numbers will be entered into the form, you can structure it into separate fields for area code and number, as at Bank of America's form (Figure 4.16). If you segment a text field into subfields, you must make it easy for users to move between fields. The Tab key should always move the insertion point from one field to the next. A form can automatically move the insertion point to the next field when the required number of characters has been typed.
Figure 4.16: www.BankOfAmerica.com (Mar. 2002)-Segments date, social security number, and phone number into subfields.
 This error message appears on the page itself instead of in a pop-up error dialog box. Why are the two error messages displayed differently? And why is the message in the past tense, as if the number entered was invalid, but no longer is?
|< Day Day Up >|