|< Day Day Up >|
Some forms are just plain mysterious. Three common causes are
Let's look at some examples of each of these.
Internet sites that host email discussion groups (often called "list servers" or "listservs") usually provide a way for list subscribers to change settings affecting their subscriptions. For example,
Is delivery to you active or temporarily paused , such as for a vacation?
Are postings sent to you one at a time or in daily digests?
Should you receive copies of messages you post to the list?
At some listservs, settings such as these are controlled through a website: Subscribers come to the site, log in, and view and change their subscription settings. The user interface that people encounter when they visit their listserv depends on what software the Internet site uses.
One popular listserv software package is Mailman. Mailman has a decidedly funky user interface, so any listserv that uses Mailman has a funky user interface. One of Mailman's funkier aspects is the setting for pausing delivery of postings. Put bluntly, it's backward: To stop delivery, you turn Disable Delivery on; to resume delivery, you turn Disable Delivery off (Figure 4.58). The best (and easiest ) way to improve this control would not be to switch the meanings of on and off, but to relabel the radiobuttons "Disable" and "Enable," similar to how the third setting (Get MIME) is labeled.
Another poorly labeled form is at Monterey.com. Most of the site's pages include a control for subscribing to the organization's newsletter (Figure 4.59). The problem is, the controls are so poorly labeled that most users won't know what to do. The label "Submit" under the text field should be on the button, not under the text field. The "Email" label should be above the text field and should be "Email Address" so people know what to type there. There is also a single radiobutton, which cannot be turned off (see Blooper 28: Checkboxes or Radiobuttons, in this chapter). Finally, the nonclickable "bullet" on the "Monthly Newsletter" label is needless clutter.
On the Dentist Search page of DenPlan.co.uk, a website for dental insurance in the United Kingdom, the main problem isn't poor labeling-although there is a bit of that-but poor layout of controls. To find a dentist near you, you have to tell it
Whether you want to see all dentists in the area or those for a specific dental plan (menu)
The location of interest (text field)
Whether the location you typed is a place, London street, or postcode
As the controls are laid out (Figure 4.60), "Among" looks like an independent control but in fact is closely tied to the "Near to" text field: It controls how it is interpreted. The form could be laid out to show that. Also, the menu ("All" vs. a specific dental plan) is the least important control and as such should not be first.
Poor layout is also the main problem on Earthlink.net's page for checking the status of your order for Earthlink's Digital Subscriber Line (DSL) broadband Internet service (Figure 4.61). You're supposed to use one of two sets of controls, but are the two sets left and right or upper and lower? After examining the form for a minute or two, you'll probably figure out that it must be left and right. But why do they have two separate phone number fields? Why not have one phone number field and a choice of whether to identify the order by the credit card or work-order number?
The prize for a challenging combination of poor form labeling and layout goes to Hewlett-Packard for the form it provides for changing one's subscription to its newsletter (Figure 4.62).
What is wrong with this form?
The text "making changes" and "Time to make a change" are meaningless. They just waste space and the reader's time.
The paragraph of instructions misses its chance to name the newsletter and omits a period after "Thank you."
It uses different words for the same thing: "the newsletter" and "Incoming." (See Chapter 6, Blooper 45: Variable Vocabulary: Different Words for the Same Thing.)
The label "E-mail address to unsubscribe" is nowhere near the email address text field. Instead, it's next to the radiobuttons, which are not for specifying an email address.
The radiobutton labels seem ungrammatical until you figure out that the newsletter must be named "Incoming."
The purpose of the second radiobutton, "Please continue" (the default), is unclear. Leaving it set here only "continues to send ... Incoming" if I already subscribe. If I don't currently subscribe, leaving it set here means "continue to not send me Incoming." Why would anyone ever need this middle choice?
There doesn't seem to be a way to subscribe to the newsletter, unless it's typing your email address in the text field and leaving it set to "Please continue to send me Incoming."
Sometimes websites confuse users by providing unique or unexpected controls in forms and controls panels. ITN.net tries to help users choose travel dates by providing a calendar tool (Figure 4.63). However, it's not like the pop-up calendar tools found at many other travel websites. It doesn't pop up; it's right there in the page next to the date control. But there are two date controls: Departing or Returning. You have to first indicate which date you want to set by clicking on the arrow next to it. That "connects" the calendar tool to that date. Got that? More importantly, will you remember it while using this form?
Citibank's CitibusinessOnline.com website complicates an action that should be simple-identifying yourself to the system (Figure 4.64). Imagine you arrive at this page. You see the menu and are at first not sure what it's for but, by opening it, figure out that it's for indicating what sort of user you are: New User, Guest, Subscriber, and so on. The Enter button is clear: You click it after you've set the menu. But what's that Delete button for? What could there be to delete here, on the login page? The Delete button slows people down just by being there: It's a mystery, so they waste time thinking about it and maybe trying it.
How a form is laid out and labeled strongly affects its usability. One cannot place fields and controls on a page, label them haphazardly, and expect good results. Also, websites- especially e-commerce sites-should be wary of altering standard control idioms or introducing new controls unless they have collected extensive test data showing that the new control is usable.
As an example of how more-careful labeling can improve a badly labeled form Figure 4.65(B), is my improvement of the Monterey.com newsletter subscription controls. Contrast it with the original controls (Figure 4.65[A]).
To show how the clarity of a form can be improved by thoughtful layout, Figure 4.66 shows revisions of DenPlan's "Find a Dentist" form (Figure 4.66[A]) and Earthlink's DSL status inquiry form (Figure 4.66[B]). The DenPlan form could be simplified even further by removing the radiobuttons and having the site figure out what sort of location the user typed, based on syntactic analysis and database comparisons.
ITN.net (see Figure 4.63) is to be commended for providing a way for the site's users to choose dates from a calendar, rather than typing them. However, their design has a severe usability problem: The calendar tool has to be connected to the desired date control before choosing a date. Testing would certainly show that people will have trouble with this.
There is a more straightforward-and more common-approach to providing a calendar tool for choosing dates. To see an example of it, we need look no further than the Northwest Airlines website we already examined earlier in this chapter (Figure 4.67).
The Web is still evolving. Design idioms and best practices are still emerging. There is certainly room for improvement through creative innovation.
As the Web continues to evolve , less successful design idioms such as ITN's in-panel calendar tool will disappear and more successful ones will proliferate. Successful design idioms for everything from date choosers to shopping carts will be encapsulated in high-level components and made available for easy incorporation into sites. The most successful idioms and components will be adopted into Web browsers, allowing websites to simply state which one they want-supplying details in parameters-and have the browser display it.
However, until successful design idioms are available in component libraries or are incorporated into browsers, Web designers need to be aware of the best ones and use them. You should keep in mind that innovation just for the sake of being different is bad on the Web. Finally, before inflicting a new, creative design on the general public, it is wise to test it thoroughly to see whether it really is an improvement.
|< Day Day Up >|