|< Day Day Up >|
Many e-commerce websites and Web information services exhibit an astounding lack of "common sense" about the domain they are supposed to cover. You ask them to do something, and they respond in a way that no person, no matter how uneducated or new to the job, would respond. In such cases, the problem is usually that the databases comprising the "back end" of the service are missing important, "task-focused" data. Bluntly, the back end wasn't designed to support user tasks . If a Web service has this problem, it doesn't matter how "easy to use" the front end is; the overall user experience will still frustrate users and limit their productivity.
Online reservation systems of major airlines allow customers to book flights over the Web, but many lack information about cities and towns that don't have commercial air service. I'm talking about towns like New Haven, Connecticut (U.S.A.); Paderborn (Germany); or Sienna (Italy). If you try to book a flight to such a place, many airline websites simply say they don't fly there and can't help you. In contrast, a human reservation agent would immediately ”without even asking you-assume you want to fly to the nearest major airport and take ground transportation from there to your destination.
For instance, I had to travel recently to Ann Arbor, Michigan. I knew that major airlines don't fly into Ann Arbor but wasn't sure what major airport is nearest. Any human ticket agent knows that Detroit (DTW) serves as Ann Arbor's airport, but I didn't know it. I gave "Ann Arbor" as my destination. Some airline websites (e.g., United) automatically assume Detroit, but many do not. Continental Airlines' website told me, "Ann Arbor is not currently served by Continental or its partners " (Figure 2.23[A]). Northwest Airlines' site said, "No Northwest ... flights were found ... between San Francisco (SFO-San Francisco Intl.) ... and Ann Arbor, MI (ARB) that matched your request" (Figure 2.23[B]), even though Detroit is one of Northwest's hubs.
American Airlines' website exhibited even less common sense. When giving it my travel data, I had to choose whether I was more concerned about "price" or "schedule" (Figure 2.24[A]). I chose "price." It responded essentially that Ann Arbor is not serviced by American Airlines, so I can't "choose by price" (Figure 2.24[B]). I have to "choose by schedule" instead. Huh? I went back to the home page and clicked "Choose by schedule." Now it listed several possible itineraries , some involving flights on other airlines, all using Detroit as the destination (Figure 2.24[C]). For some reason, AA.com can't figure out that Ann Arbor is served by Detroit DTW if you "choose by price," but it can if you "choose by schedule." Do the two options use different databases, perhaps?
However, the "choose by schedule" list showed no prices and I was concerned about price, so I backed up to the home page and tried a third time; this time giving Detroit as my destination and clicking "choose by price." Finally, flights with prices (Figure 2.24[D]). So if you give your destination as Detroit rather than Ann Arbor, "choose by price" works. But it can't figure out that Ann Arbor really means Detroit. Major back-end blooper!
Airlines aren't the only companies with frustratingly ignorant websites. Greyhound Bus Company's site shows clearly that an easy-to-use front end cannot make up for a back end designed without regard to actual user tasks. The site accepts only the locations of Greyhound bus stations as departure and arrival points. Furthermore, it provides no help in figuring out what stations are nearest to your starting and ending locations. You have to know where the bus stations are. You do know, don't you?
However, it's even worse than that. Let's say you go to Greyhound.com's ticket-center page and type in that you wish to travel from Fremont, California, to Torrance, California (Figure 2.25[A]). Greyhound has no stations in those towns, so it substitutes the closest towns that have stations. The problem is " closest " means alphabetically . Fresno is substituted for Fremont, and Tehachapi for Torrance. In fact, Fresno is nowhere near Fremont, and Tehachapi is about 90 miles from Torrance. It is hard to imagine anything less useful.
If instead of using the site's Ticket Center page, you type your departure and arrival cities into the mini-Ticket Center on the home page, the substituted cities may not even be in the same state as those you type. If you give the California towns Torrance and Rodeo as your Departure and Arrival cities, respectively, it asks you if you meant Toronto, Ontario (Canada), and Roanoke, Virginia (Figure 2.26)!
Airline and bus-line websites may not recognize many small towns and villages, but they at least know the names of major cities. Not all Web services do. The weather-reporting services Weather.com and Yahoo Weather don't seem to know about New York City, for example. Ask them for the weather in New York City, and one responds blankly while the other offers several irrelevant New York towns (Figure 2.27). Clearly, the back ends of these two sites are missing important keywords.
Artificial intelligence researchers are working to endow computer-based systems with the sort of reasoning abilities that in people are called "common sense," but at the present time (2002), they seem far from that goal. Until they get closer (if they ever do), Web developers should work to ensure that their sites and services don't exhibit failures of common sense so blatant that people avoid the site.
This means that developers can't just slap a front end ”no matter how easy it is to use ”onto a non-task-focused back end and expect to have a usable and useful Web service. They have to design the entire system ”back end and front end ”to support users and their tasks. Furthermore, they have to test the service on representative users early and often during development to check that it really supports user tasks and doesn't exhibit any blatant common sense bloopers.
It can be done. As mentioned earlier, in contrast to several other airlines, United Airlines' online booking service accepts towns that lack major commercial airports.
Like human travel agents , United.com distinguishes between a customer's final destination and the destination airport. When given Ann Arbor, Michigan, as a destination, it simply assumes Detroit DTW as the destination airport (Figure 2.28). The difference here is in United.com's backend servers, not its front-end site.
|< Day Day Up >|