|< Day Day Up >|
A default value that is unlikely to be the one users want is potentially more harmful than no default. A user who overlooks a control that has no default often gets an error message, but overlooking a bad default usually yields an unwanted result.
A common "reason" for a poor default value is that the developers didn't bother to instruct the menu, radiobutton set, or scrolling list to initialize itself to an explicit value, so the control sets its default value to the first value listed.
An example of this comes from the Stanford University Bookstore website. When a user buys a book online, he or she has to supply an address. The State menu defaults to Alabama (Figure 4.29)-the alphabetically first state-even though most customers of this site live near Stanford, in California. If a customer fails to set the state, the problem might not be caught until the book is returned to the bookstore from an invalid mailing address in Alabama.
While we're on the subject of books, let's examine a poor default on the website of Morgan-Kaufmann Publishers. The home page has a Search function for finding books in its catalog. The Search box is a menu for indicating whether you want to search "By Author," "By Title," "By ISBN Number," and so forth. By default, the menu is set to "By Author" (Figure 4.30), probably because it is first in alphabetical order. Unfortunately, that isn't how most visitors to this site will want to search most of the time. "By Title" is much more likely to be what people want. A large number of visitors will either not notice the menu or assume it doesn't matter and make the mistake I've made on this site many times: type a title into the Search box, click Go, and get nothing.
At least MKP.com's Search results page tells you why it found nothing: "No results found for Author = 'GUI Design,'" so users don't have to wonder what went wrong. That's better than the feedback provided by many website Search functions: nothing. But users still have to back up, set the menu to "By Subject," and try again.
Some defaults in website forms are more than bad, they are downright evil: intentionally set so visitors who fail to notice them will get something they probably don't want.
For example, some sites ask new registrants if their data can be shared with other organizations, with the default set to "yes." Other sites ask whether they can send email announcements, defaulting to "yes." An example of the latter comes from flower vendor JacksonAndPerkins.com (Figure 4.31). The option appears at the bottom of its registration form, where people can easily miss it.
Here's one that is even more evil. Let's say a friend of yours uses Evite.com to send party invitations. The friend gives Evite the email addresses of invitees. Evite sends you a message with a link to their site for viewing and responding to the invitation . When you respond, you may or may not notice a checkbox at the bottom of the response form, labeled "Yes, I'd like to receive Evite news and special offers" (Figure 4.32). It is checked unless you uncheck it.
This default amounts to "viral" marketing. People who aren't actual Evite customers, but who just received invitations, can be added to Evite's marketing list simply by overlooking a checkbox.
Defaults such as those at JacksonAndPerkins.com and Evite favor a website's company, rather than its users.
The grand prize for the most ridiculous default value goes to- may I have the envelope, please -ThisDayInMusic.com, a website in the United Kingdom that, given a date, tells you "What [popular song] was No. 1 in the UK/USA on the day you were born." Leaving it on the default date-1 Jan 1952-I clicked the U.S. flag. Up came an error message "The UK charts began on 14/11/52, the US charts on 1/1/55. Please try again using a valid date." The form scolded me for using its own default date (Figure 4.33)!
How do you choose the default value for a choice? Here are several possible ways:
Common sense. Often, simple common sense works. On a form to apply for a San Francisco library card, it's a good bet that applicants live in San Francisco.
Experience and site data. If common sense doesn't suggest a default, perhaps your customer observations or Web logs show that most people pick a certain option. If the site's defaults don't match what people usually choose, change them to save work for users in the future.
Based on user's data. If no single default is suitable for all site users, use different defaults based on whatever you know about a particular user, such as where he or she is located. 
Arbitrarily. Finally, if no particular option seems any more likely than any other, there is sometimes no harm in arbitrarily declaring one to be the default.
Set defaults so that they benefit your site's visitors, not your organization. Let people opt into having their information shared or receiving email announcements, as the American Cancer Society's website does (Figure 4.34).
 Perhaps the user is registered and logged in, so the site " knows " the user's location. Otherwise, the site could guess the location by looking up the IP address in a database that maps addresses to locations.
|< Day Day Up >|