Web Bloopers: 60 Common Web Design Mistakes, and How to Avoid Them (Interactive Technologies)

Blooper 9: Requiring Unneeded Data

Almost as annoying as websites that ask for the same data more than once are sites that ask for data they don't really need. All Web users have encountered sites that

• Require a company name when registering a purchase even though you didn't buy the product for any company

• Ask for both a unique ID number (such as an account number) and a name

• Treat all data fields as "required" even though some aren't really necessary and should be optional

Your Zip Code Isn't Enough; We Need Your State Too

House.gov, the website of the U.S. House of Representatives, provides a page for sending email to your representative. That page requires site users to specify both a postal zip code and a state in order to locate their congressional representative (Figure 2.7[A]). Providing only a zip code is treated as an error (Figure 2.7[B]). Although a state is not usually enough to determine one's representative, a zip code is enough, since the zip code fully determines the state.

Figure 2.7: www.House.gov (Nov 2001)- A ” "Write Your Representative" page requires state and zip code. B ” Error message indicating that state is required.

Tech Talk: METHODS FOR AVOIDING ASKING TWICE

The Web was originally designed with no notion of an extended session-a connected series of requests. Web servers receive requests for individual pages from around the Internet and respond by sending each page to its requester. Each request is treated independent of others. As a result, Web servers-and therefore websites-initially had no way to know that two successive page requests came from the same user .

Why was the Web designed this way? Because it was designed for sharing information, not for processing transactions. When people were just looking at archived documents and each other's Web pages, there was no problem.

When forms, scripts, and e-commerce were added to the Web, the problems of propagating data through a stateless system arose. Web implementers had to devise ways to let Web servers determine that a series of requests is from the same user, and ways to propagate data between pages.

It isn't so much of a problem when data is to be shared between forms on two successive Web pages. In that special case, the script processing the first form's data can load the next form with any data that carries over. The problem arises when there are intervening pages without data on them: Data collected on page 1 isn't needed on page 2 but is needed on page 3. Compounding the problem is that Web users can-and do-navigate unpredictably around a site, rather than in predefined paths.

To allow sites to propagate users' data throughout a site to avoid asking for it again, three quite different methods were devised: "hidden forms," "cookies," and "stuffed" URLs. A fourth, very different approach involving browsers is described afterward.

Hidden Forms

In this approach, every page has a form on it, but most pages hide them. All links from the page trigger a Submit script, which (among other things) passes the data to the next page. This is cumbersome and slow, because

• The form pages must be generated dynamically, in order to be filled in automatically by the scripts. The hidden forms method doesn't work for static HTML forms.

• A site's pages contain extra, invisible baggage, inflating their size and download times.

• All the data is sent back and forth between the browser and the server every time a link or button is clicked.

The "hidden forms" approach is now regarded as "old fashioned"; the next two methods are preferred.

Cookies

Website developers and browser makers devised a way for a website to send a small token-known as a cookie -to a Web user's browser and later retrieve it. The cookie identifies the site that issues it and assigns a unique ID to the user. It can also store other data. The browser saves the cookie and whenever the site asks for it sends it back. When a user accesses a page on a site, the site asks the user's browser if it has the site's cookie. If the browser has the cookie, it sends it back to the site. The site uses the cookie's user ID to retrieve the user's data from its database for use on the current page.

There are two types of cookies:

• Session cookies: Browsers store these in memory and delete them when the user navigates to a new Web domain (e.g., from Amazon.com to Powells.com ). Session cookies allow sites to track a user through a session.

• Persistent cookies: Browsers store these in disk files and don't delete them until asked to by the issuing domain or the user. Persistent cookies allow sites to recognize returning users and relieve them of the need to log in every time they revisit a site.

Cookies are the primary way websites avoid asking users twice for the same data. For example, ACSCSN.org achieves a single site-wide login by setting a login cookie on the user's computer and having all restricted functions check for the cookie. If the cookie is absent, the user is asked to log in before he or she can access the function.

However, cookies are controversial , especially persistent ones. They can be abused to track individuals around the Web, violating their privacy. Although a given Web domain can check only for its own cookies, banner ads can issue and check for their own cookies, from all the sites on which the ad appears. Web advertisers sometimes do this. Some Web users dislike the idea of being tracked. Another problem is that persistent cookies consume space on users' computers. Although the amount of space cookies require is usually miniscule, some people don't like the thought that any website they visit can put cookies on their computer. Based on these concerns, some Web users set their browsers to refuse some or all cookies. Sites that rely on cookies may not work properly for such users.

Browser makers such as Netscape and Microsoft have tried to address concerns about cookies. Newer browsers give Web users more control over what cookies their browser accepts and allow users to examine and delete persistent cookies. However, the tracking problem remains. Browser makers and architects of the Web could help alleviate concerns about cookies by making it harder to abuse them.

Stuffed URLs

Another way to follow users from page to page in a site involves " stuffing " the URL of a destination page with data from the current Web session (visit), such as a unique session ID. For example,

<a href="checkout.html">Checkout</a>

would be sent as either

<a href="checkout.html?id=543XYZZY"> Checkout</a>

or

<a href="checkout.html?email = FredFlinstone@bedrock.net">Checkout</a>

The site receives the URL and sends the page, either augmenting it directly with the user's data or using the session ID to fetch the user's data and then augmenting the page.

Of course, this method results in long, complex URLs most users can't decipher. Such URLs also make poor bookmarks. If the appended data is more than just site-generated unique session IDs, such as an email address or telephone number, there are more serious disadvantages: (1) The data is transmitted unencrypted over the Internet, where it can be intercepted, and (2) the data becomes part of the site's permanent Web log, where many people can access it.

Designers of Web protocols and browser companies could improve this situation by devising a way for browsers and websites to pass session data-preferably encrypted-without appending it to URLs.

Browser-Based Solution: Automatic Form Fill-in

Browser makers recently began offering their own solution to the "repeated request" blooper. Newer browsers can detect forms on displayed pages and offer to fill in data automatically. The browser either remembers the data from previous website forms the user filled out or gets it from a special user-profile form the user filled out.

This approach assumes-probably correctly-that Web users don't care how the "repeated request" problem is solved ; they just don't want to have to reenter data. It shifts the responsibility for remembering data from websites to the browser.

The problems of browser-based form fill in are as follows :

• Not all browsers provide it yet.

• Few Web users use it, even if their browser provides it.

• Browsers sometimes miss data fields for which they have data.

• Browsers sometimes fill in data fields incorrectly.

Web developers can foster browser-based automatic form fill-in by using semantic page-description languages such as XML instead of HTML and by tagging data fields in standard ways. For example, if email address fields in all forms were tagged "<email_addr>," browsers could recognize them reliably.

Browser-based automatic form fill-in may eventually be the dominant way the "repeated request" problem is solved. Until then, the burden is on site developers, who have to do whatever they can to avoid asking their users for data repeatedly.

Obviously, the implementation is too simplistic, probably to save development costs. I'll bet that many people who use this page initially give only their zip code, get the error message, emit a sigh (or curse), and then give both state and zip code.

This site also commits Blooper 8, Redundant Requests. When a user reads "You must select a State" and clicks the link to return to the "Write Your Representative" page, the zip code field has been blanked, requiring the user to type it again.

EarthLink.net provides a function for looking up EarthLink's dial-up access phone numbers in cities around the world. For example, if an EarthLink customer were traveling to New York City and wanted to connect from there, he or she could use the function to find the local access number. However, the number lookup function is too demanding: To determine where the user will be, it requires that you give it a complete phone number (Figure 2.8) even though an area code would, in principle, be enough. Customers who don't yet know where they will be staying might not have a complete phone number. All they would know is the area code. In such situations, customers have to make up a phone number. Even when customers know a phone number where they will be, why should they have to type it, when an area code will do?

Figure 2.8: www.Earthlink.net (May 2002)-Asking for more data than needed. A ” Form requires full phone number. B ” Error message when only area code given. Area code should be enough.

EarthLink's developers might argue that some area codes have more than one access number. Fine, but when a user gives a complete number, EarthLink.net displays not one, but a list of access numbers in and around the specified area ”the same list that would presumably be displayed for just an area code. Therefore, requiring a specific phone number as input is pointless.

You Must Tell Us; It's Required

Some sites designate certain data fields as "required" for no good reason. Two examples of this come from Agilent.com. The form for submitting questions or comments about the site includes a Country setting and treats it as required (Figure 2.9[A]). What country? The user's? Agilent's? Why must users specify a country to comment on the website? A customer registration form asks for a lot of data and states at the top "All fields are required" (Figure 2.9[B]). All fields? What if a customer doesn't have a department, fax, or address 2? Answer: They have to make one up to register.

Figure 2.9: www.Agilent.com -Demanding more data than needed. A ” Comment form (Jan. 2002) requires country needlessly. B ” Customer registration form (Feb. 2001) requires all fields, including Fax and Address 2.

Avoiding the Blooper

The way to avoid this blooper is not to be overzealous about collecting data:

• Ask for as little data as you can ”only what you really need. If you aren't sure what you will do with a certain piece of information, you don't need it, so don't ask for it.

• Stick to the current transaction. Data you would like to obtain for other purposes, such as marketing or establishing a relationship with the user, should be requested in separate and optional areas of the site, such as registration pages, membership applications, and email announcement subscription forms.

• Don't make any data "required" unless you really cannot proceed without it.

• Don't require data some customers won't have: You would just force them to make it up or take their business elsewhere.

• When someone gives you information, deduce as much as you can from it. Use what you know to fill in other data fields if possible. For example, it would be very unfriendly for a website to ask visitors for both date of birth and age, because age can be deduced from date of birth.

Asking for data you don't really need scares privacy-minded people away, hampers customers from achieving their goals, frustrates those who don't have the information you require, and slows throughput at your site, thereby hindering its success.