Blooper 8: Redundant Requests

< Day Day Up >

Few things annoy people more than having to give an organization the same information twice. It doesn't matter whether the information is requested by a website, a desktop software application, a paper form, a telephone operator, or a receptionist .

When an organization asks you for information you already gave it, the message is that they didn't care enough about you to implement procedures for using already-provided information wherever they need it. They offloaded that work onto you. In some cases, different organizations involved in the processing of your information failed to cooperate or communicate well enough.

Due to the fundamental nature of the Web, avoiding this blooper can be difficult. As a result, it is common for web-sites and Web applications to require users to reenter data they already entered. This blooper comes in several forms, which are discussed in turn , with examples. The examples are followed by a discussion of why this is a difficult blooper to avoid and ways of avoiding it.

Not Using Already-Provided Information

Some sites ask for the same information twice because they ignored what the user already told them.

An example comes from Microsoft.com . If you want to ask their customer-support department a question, you set a menu to the product you are asking about (Figure 2.1[A]) and click Go. That takes you to a Personal Support Incident Submission page, with another menu for specifying the product. Annoyingly, it is not set to the product you just indicated on the previous page (Figure 2.1[B]). You have to set it again.

Figure 2.1: www.Microsoft.com (Feb. 2001)-Asks for same information twice. A- User specifies PowerPoint as subject of question. B- Menu on next page doesn't reflect choice from previous page.

A related blooper-requiring users to indicate more than once where they want to go on a site-is discussed in Chapter 3 (see Blooper 21: Missing Links: It's Back or Nothing).

Poor Coordination between Systems

A similar annoyance can be found at the website of ProxyVote.com , a site for voting online in stockholder elections . However, here the cause isn't a simple lack of transfer between forms. It's a lack of communication between organizations (Figure 2.2).

Figure 2.2: www.ProxyVote.com (Oct. 2001)-Asks for same information twice. A- User provides 12-digit control number. B- New user registration form (lnvestorDelivery.com) asks for same 12-digit control number.

The process starts with a letter announcing an election. The letter provides ProxyVote's Web address. At ProxyVote.com, you are asked to prove you're a stockholder by providing the 12-digit control number from the letter (Figure 2.2[A]). The first time you vote through ProxyVote.com , it temporarily hands you off to a different website- InvestorDelivery.com -to register you as a ProxyVote user. The annoyance is that InvestorDelivery.com asks you for the same 12-digit control number you just gave to ProxyVote.com! Even though the second request comes from a different organization, users see it as a repeated request because from their standpoint it is all part of the same task.

Forgetting User's Stated Preferences

Airline reservation websites seem to have trouble remembering, from one screen to the next, what time of day you want to fly.

Southwest Airlines' website provides an example. Suppose you tell it you want to depart on a day sometime between noon and 6:00 PM and return on another day after 6:00 PM (Figure 2.3[A]). At least the flights it finds reflect those departure and return times; some websites don't even manage to do that. However, on the Search results page, the "Edit your Search?" control panel shows both departure and return times as morning (Figure 2.3[B]). Someone could easily overlook those settings, change the date, search again, and get a list of flights leaving at unsuitable times.

Figure 2.3: www.Southwest.com (Sept. 2002)-Forgets what user told it. A- User specifies afternoon departure, evening return. B- Results page set departure and return to "Anytime" and lists flights that reflect that.

Southwest.com isn't the only airline site that commits this blooper. Continental.com and United.com also sometimes "forget" your preferred travel times as you proceed through the ticket-ordering process.

Losing Data on Return to Page

A special case of asking for data twice is when you return to a previous page-intentionally, or because the website sends you back because of an error, or even just because the page is refreshed-and information you had put on that page is gone.

For example, the website of the California Shakespeare Festival, CalShakes.org, has a ticket-ordering form but resets it if you backup to change your order (Figure 2.4[A-C]). The date menu is reset to the default date, and the text fields are cleared. If you retype the number of tickets but don't notice that you need to reselect your desired date, you end up ordering tickets for the wrong date. Or if you reselect your date and proceed without retyping the other fields, the site shows you an order for no tickets, for which it still wants to charge you a $4 service charge (Figure 2.4[D]). This is almost funny .

Figure 2.4: www.CalShakes.org (July 2002)-Ticket order form is reset when revisited to change the order.

The CalShakes blooper is annoying but pales in comparison to a data-deletion blooper at UBid.com. The site provides a form to send email to UBid. If the email form page needs to be refreshed while you are filling it out-for example, you change the browser window size -all fields except the First Name field are cleared (Figure 2.5). Now you get to type it all again. Or hit Back and go somewhere else.

Figure 2.5: www.UBid.com (Dec. 2001)-Clears most data fields on any page refresh. A- Data in form. B- Form after browser window resized and page redisplays.

Requiring User to Log In Repeatedly

A second special case of asking for information twice is asking people to log in repeatedly. When you log in, you are telling the site who you are. Depending on the site, it might be done using your actual name, a login name, a frequent-flier number, a credit-card number, or a student ID number. Often, sites require you to prove your identity by supplying a password. Once you have identified yourself to a website, it should not ask you to identify yourself again, at least not with the same identifying information you already gave it. But many sites do.

Internet provider EarthLink.net requires customers to log in three times, always with the same email address and password, to activate or deactivate an auto-reply "vacation" message. The first login is to access one's Personal Support Center page (Figure 2.6[A] and [B]). Clicking "Manage Your Mailboxes" displays the "Dialup Maintenance Login" page (Figure 2.6[C]), requiring users to log in again to get to the "Mailbox Maintenance" page (Figure 2.6[D]). Finally, clicking "Vacation Message" displays a page that asks users to log in a third time, with the same "email address, domain, and password" (Figure 2.6[e]). Only after this third login is the page for setting Vacation messages displayed.

Figure 2.6: www.EarthLink.net (Jan. 2002)-Activating or deactivating a Vacation Auto-reply message requires logging in three times.

United.com is another site that often makes people log in repeatedly during a session.

One reason many sites require users to log in repeatedly is that there may be multiple ways to arrive at certain sections of the site. If a section requires login but can't tell whether the user already is, it will require a login of its own. If the user has already logged in, this will be a second-or third-request.

It's a Difficult Problem

One should not be too hard on sites that repeatedly ask users to log in or enter data. Avoiding it is difficult. The "stateless" nature of the Web-page accesses are treated as independent-makes it awkward at best to follow users through a site, bringing their data along. This contrasts with desktop software and non-Web online information systems, in which all windows displayed to a user are part of a single session.

Avoiding the blooper gets even more difficult when completing a task involves multiple websites, as in the ProxyVote example. To avoid asking for data twice, it must be transferred between sites. This is difficult or impossible for two reasons:

Statelessness: Transferring data between pages is at least as difficult when pages are from different sites as when they are from the same site.
Legal restrictions: In addition to technical obstacles, data transfer across organization boundaries may face legal obstacles: privacy policies, rules, and laws.

Not only is avoiding the blooper difficult from a technical standpoint, the "repeated-login" form of it is sometimes intentional. For all a site knows , the user walked away from the computer without logging out or quitting the browser, and now a second person is using it and is about to access information or buy something in the first person's name. Such scenarios are unlikely in private homes but are more likely in schools , libraries, and Internet cafes.

However, most Web users, and an even greater majority of potential Web users, don't know or care how hard the problem is. They don't know or care that the Web is stateless. And they don't know or care that repeated logins may be for their own protection. They just know that having to give the same data again is a bother and is something "good" organizations and desktop software don't do. And since they are the customers, they are right.

Avoiding the Blooper

Not making Web users enter data more than once should be a high-priority goal. Yes, it's difficult, but website designers, architects , and developers can do better than they have. We know this because some sites are better than others at remembering what users told them. Development teams that downplay the importance of this issue to save development time or costs are making an important business decision for their company. They are creating a web-site that will have lower customer loyalty than it would have if it preserved user data and propagated it to wherever it was needed.

Let's consider some things Web developers can do to avoid the blooper. Here, the focus is on high-level goals, not implementation details. The sidebar (Tech Talk: Methods for Avoiding Asking Twice) describes technical methods for achieving these goals.

Don't Lose Data on Return to Page

Losing data when a page refreshes or a user backs up should be considered a showstopper bug. Do whatever it takes to avoid it.

Don't Force Users through Multiple Sites

Websites should avoid architectures that route essential tasks through other sites (see Chapter 3, Blooper 21: Missing Links: It's Back or Nothing), especially when completing the task requires getting information from the user. If one site needs a service from another site, fine, but it should do it "behind the users' back" rather than by explicitly handing the user off to the other site. For example, one website can act as a user interface to another site, feeding data to it and retrieving data from it, filtering and reformatting the data from the other site for presentation to users.

Design Site with a Single Universal Login

To avoid requiring multiple redundant logins, websites should keep track of the user's login status in a way that is accessible to all parts of the site. A particular page's designer should not assume that a user who arrives at the page either is already logged in or needs to be logged in. Instead, any page that needs the user to be logged in should check the user's login status, and if the user is not logged in, display a login page or dialog box before proceeding.

One website that avoids multiple logins is the American Cancer Society's Cancer Survivor Network site, ACSCSN.org. Certain functions on the site are restricted to logged in members, but no matter where members go on the site, they are never asked to log in more than once.

Some websites require multiple levels of security. A user may log in to access a low-security area of the site, then log in again to access a higher security area. However, the higher security login should require different identifying information than the lower security one; otherwise , it's not really higher security.

Push for Better Support from Browsers and the Web

Website developers and designers are limited to makeshift methods of bringing user data from page to page. Better, universal solutions will require help from browser developers and even the architects of the World Wide Web. The sidebar (Tech Talk: Methods for Avoiding Asking Twice) describes the methods Web developers use to avoid this blooper-Web "cookies" and "stuffed" URLs-and explains how better browser support and Web protocols can help even more.

< Day Day Up >