Blooper 11: Omitting Important Options

< Day Day Up >

Another way many websites and Web-based applications fail to support users' tasks is by omitting crucial options when users are asked to make choices. Although this blooper has roots in a site's front-end Web design, its roots also extend into the content and business logic embodied in a site's back-end services.

Often, choices are presented explicitly, as controls such as menus or radiobuttons . On the Web, choices are also frequently presented simply as arrays of links on Web pages. However the choices are presented, all plausible options must be present; otherwise , site visitors will feel trapped-"I have to choose, but the option I need isn't here! What now?"-and frustrated-"This %@&# website wont let me do what I want to do!" Providing all plausible options requires that designers understand and consider all the different goals that users could have at each choice point. Sadly, many Web designers don't do their homework and end up presenting choices that trap and frustrate users.

Classic ... Just Classic!

A classic example of this blooper comes from the website of the University of California at Los Angeles, UCLA.edu. The UCLA extension program's section of the site, unex.UCLA.edu, begins with a splash page that asks visitors to choose between two options: "Connecting with 28.8 or slower? Click here" and "Flash Enhanced Site Click here" (Figure 2.20). Um, where do I click if I have a 28.8-kbaud modem and the Flash browser plug-in? What if I have a fast Internet connection such as DSL but don't have or want Flash? The site asks users to choose between options that (1) are not mutually exclusive and (2) don't cover all the possibilities. Many visitors to this site will feel stymied by this choice. Perhaps the designers of this site assumed no one with a 28.8-kbaud modem would have Flash and no one with a faster connection wouldn't, but if that's what they assumed, they are simply wrong.

Figure 2.20: www.UNEX.UCLA.edu (Feb. 2002)-The two available options aren't mutually exclusive or exhaustive. Some users' circumstances don't fit either choice.

Tech Talk: "SNIFFING" THE USER 'S BROWSER

Detecting which browser a site visitor is using is called "browser sniffing." It requires that the server be running a script, such as CGI or Java script.

When a browser hits a website, it automatically sends a bunch of information to the Web server. Included in that information is a text-string labeled HTTP_USER_AGENT . An example of this type of data, for a person using Microsoft Internet Explorer 5.14 on a Macintosh, is

HTTP_USER_AGENT="Mozilla/4.0 (compatible; MSIE 5.14; Mac_PowerPC)"

A Web server that needs to know which browser a visitor is using would have a script to examine the USER AGENT string and act accordingly ; for example, send pages optimized for the visitors' browser.

Here are two websites about browser sniffing:

www.eit.ihk-edu.dk/instruct/browsersniffing.php -Explains browser sniffing, with sample scripts. Provided by the Engineering College of Copenhagen, Department of Electronics and Information Technology.
gemal.dk/browserspy/ -Shows what your browser sends to sites you visit. Provided by an individual: Henrik Gemal.

You Want to Fly WHEN?

In websites for booking air travel, the controls for specifying flight details are all pretty similar to each other.

Customers specify a departure airport, a destination, dates, preferred departure times, and maybe some other optional settings such as the number of passengers, and then click a "Find Flights " button.

One way flight-search controls differ is in the menu options for desired flight times. Although one could imagine this becoming standardized across the air-travel industry, that hasn't happened -at least not yet. Whether this is for competitive reasons or is due to each company's implementation constraints is unclear. What is clear, however, is that some travel-time menus on the Web are better than others. The travel-time menus of some airlines and travel agencies lack important options.

Table 2.1 shows travel-time menus from five air-travel web-sites. The first three menus in Table 2.1 ( columns 1 through 3) show one common flaw: providing only specific times. This makes it impossible for travelers to specify that any time of day is okay, that any time of morning is okay, or that they want a red-eye (late evening) flight. The hourly times listed by NWA, CheapTickets, and Travelocity also give users the false impression that the site's search for flights will be restricted to the indicated hour . The last two menus (columns 4 and 5), from AA.com and United.com, list both specific times and general time periods. Although this is an improvement over the previous three menus, one problem is that it makes little difference to the Search results whether a user chooses a general time like "morning" or a specific one like "8:00 AM." None of the menus in Table 2.1 provide an "any time" or "all day" option.

Table 2.1: Air-travel reservation menus that provide no way to specify "any time."

In the Avoiding the Blooper section, we examine travel-time menus that provide the time-of-day options travelers need and don't provide ones they don't need.

If You're from D.C., You're Nowhere, Man!

It's astounding how many websites provide menus for specifying a U.S. state but fail to include the District of Columbia-also known as Washington, D.C.-as a choice. If that is where you live, you have no straightforward way of ordering a product or registering with the site. You can give the address of a relative in another state, but why bother, when you can go to other sites that know D.C. exists.

Pitsco-legodacta.com's catalog order form has a menu for specifying one's state. The District of Columbia is missing. The menu's label also falsely suggests that it includes provinces in Canada or elsewhere, but it doesn't (Figure 2.21).

Figure 2.21: www.pitsco-lego-dacta.com (June 2002)- A- Catalog order form, with State/ Province menu. B- Menu omits District of Columbia (Washington, D.C.).

Avoiding the Blooper

The way Web designers and developers can avoid this blooper is to do their homework: Analyze fully the requirements of the intended users and then design the site or Web application to provide options that match those requirements. For the UCLA Extension splash page, a full analysis would have exposed the need for more options or combinations of options. Analysis, design, and development should be followed up with usability testing, beta-testing, and customer focus groups to check whether the site provides all the options users need. Costly? Yes, but not as costly as a website no one visits .

Table 2.2 shows travel-time menus from the websites of Continental Airlines and Greyhound Bus Company that avoid the blooper of omitting important options. The first menu (column 1) is from Continental.com's Ticket Purchase page. It has every departure-time option anyone could possibly need, including "all day." As explained already, the specific hourly times are misleading because the search is never restricted to a specific hour anyway. For this reason, the much simpler menu on the site's home page (column 2 of Table 2.2) is better: It gives travelers a choice of morning, afternoon, evening, or all day, without facing them with a huge menu. Greyhound.com's departure-time menu (column 3, Table 2.2) provides slightly more specific options than Continental's, plus a "Show All" option. I consider it just about perfect for specifying departure times and think all airlines and online travel agencies should simply adopt it.

Table 2.2: Air-travel reservation menus that provide all necessary options. The latter two provide a simpler set of choices well suited for searching.

Pitsco Lego Dacta's developers could have avoided their blooper-omitting Washington D.C.-simply by copying code from other pages on another site of theirs. The site with the blooper is the main company site. Their online store is at a different site, PLDstore.com. The customer-registration form at PLDstore.com includes the District of Columbia in its State menu. No doubt, the store site was developed independently of the main site, with no oversight to ensure consistency between them (Figure 2.22).

Figure 2.22: www.pldstore.com (June 2002)-The customer registration form at the PLD Store site has a state menu that includes the District of Columbia.

< Day Day Up >