Last time <http:www-106.ibm.com/developerworks/usability/library/us-cranky6.html>, we took a look at the importance of good-quality textual treatment on your Web site. This time, we'll see how Web sites have the power to attract or repel, and how many commonly-accepted Web design features actually drive users away -- even before the page is finished loading.
"... and I didn't even wait for the page to finish loading." How many times do we hear that? As users, all too often; as Web designers, not nearly often enough.
It's important to remember that users are not obliged to view your pages, and may choose to leave. Users will cancel purchases in the face of difficult shopping carts; they will buy other products if the product information they can access is not useful enough.
In this article, we discuss things that drive users away from pages even before the page is done loading.
There are several main reasons why a user might abandon a page. Time is one of them; a page that takes longer than a user is willing to spend will be abandoned. Presentation problems (such as awful color schemes) can also drive people away. Annoying content may cause users to give up on a page, either because it's distracting or because it takes too long to load. Finally, a page with no content can drive people away as quickly as anything.
... and drags on painfully when you're not. The most accepted estimate I've heard is that the LD50 for time is 10 seconds. At that point, half of the users who started loading the page have already moved on to greener pastures, or at least nearer pastures. When I was behind a major corporate firewall, it wasn't unusual for a page with five images to take over a minute to load; needless to say, I ignored a lot of pages that depended on images.
(LD50: "Lethal dosage 50%"; the amount of a specific substance required to kill 50% of a population. It's used to measure toxicity of poisons.)
Estimated download times are only a small portion of the story. A 28.8k modem will frequently spend much of its service life actually communicating at a slower, but more reliable, 26,000 bits per second, or fewer. I have known people whose 56k modems have never gotten past 22,000 bits per second. Furthermore, most estimates of download time assume that DNS, initiating connections, and other traffic issues aren't problematic. I am unable to believe that I'm the only person in the world who browses while downloading -- and my bandwidth is roughly cut in half.
Furthermore, occasionally some other part of the network may be congested. ISPs frequently have much more dial-up bandwidth than Internet bandwidth, because most users aren't using their feed at full capacity most of the time... but during peak hours, performance can suffer.
Unfortunately, even if your page only takes 10 seconds to load, you've still lost HALF of your audience.
Users sometimes try to correct errors. Most often, they don't. I am often patient, and I've discovered that about a quarter of the time when I get an error from an IIS server, reloading the page fixes it. On the other hand, three-quarters of the time, it doesn't. So, these days, I don't bother much. Most other people don't either.
If form data can cause your script to crash, a user who enters that data will not try to correct his data entry; he'll assume your script is dysfunctional. He'll be right. If your server is running IIS, it will fail in exciting new ways, and users will go look elsewhere. Bad links will drive users away very quickly as well. You have to remember that internal link-checking is not enough; if I got pointed to your page by a review of your product, chances are I'll be directed to the page that had the information about that product when the review was written. I won't waste time trying to find it if the page has moved.
Error messages should be rare. Informative, too, but rare is the big key to success here. Run something that doesn't crash. If you run something like ASP, users will be less likely to try to correct errors, because experience will have taught them that your server probably just plain doesn't work.
Downtime has the same effect: If your server isn't serving pages, my first assumption won't be "the poor benighted fools are running NT," it'll be "the company probably folded." I won't be back.
And yes, NT really does have that reputation. Try browsing around for a while, and count the pages you visit that have weird errors and complaints about invalid database entries, and see if you can spot the pattern. Most users can.
Don't depend on a background image: If the image hasn't loaded yet, and I see your page with whatever background and foreground colors you hinted at, and I can't read it, I won't wait on the off chance that an image I haven't loaded yet will make the page legible. I'll leave.
Contrary to popular belief, black text on a black background does not communicate the magnitude of your suffering, or the futility of seeking joy in a meaningless world. It communicates nothing at all, and users are not going to wait around in case you decide to say something later.
A special mention must be made of Web pages with embedded MIDI. This is something that seems to be universally loved by novice Web designers, and universally hated by readers. What about the CD I was listening to? What if I don't like that song? Some browsers compound the tragedy by making it hard (or impossible) to stop a background song ... but the first way a user will try to stop the song is by leaving the page. My wife won't let a page get through three notes, generally; there are other pages to look at, and they don't insist on singing to you.
Similarly, try to avoid overdoing your presentation. One page I saw required about 20 minutes of fiddling with browser settings to load. It had a little Java applet that made a cool rippling effect on the logo. It also made a cool rebooting effect on the computer. I haven't been back, and the only reason I was there that long is sheer hacker curiosity: Most people won't bother trying to "fix" a page.
Pages that cheerfully announce "best viewed in..." generally get dropped immediately. I don't care whether you're trying to dictate resolution (my primary browsers are 160 x 160 and 1856 x 1392), choice of browser (AvantGo, iCab, and a version of Netscape probably best forgotten), or even color depth; if you're telling me that I have to conform or I don't get to see the page, I leave. Even if you really just mean best viewed in, why are you telling me this? My preference for how I view pages trumps your preference for how to display them; any assertion otherwise is just rude, and I won't stick around to see why you so desperately need an 800-pixel window.
Finally, don't forget to consider plug-ins -- specifically, the risks of including them. Think about it; if half of your users aren't going to stick around for 10 seconds to load your page, how many will be willing to invest 20 minutes finding a new plug-in, downloading it, and installing it? The process may require reboots, will probably restart the browser ... and may not work. Users frequently won't bother.
This is one way you can outsmart yourself. If I do finish loading the page, and the stuff I was looking for isn't there, and I have to load another page, I may not bother. Especially the second or third time.
Cover pages are a disaster. What, pray tell, is the point? Do I need to be reminded of your logo, full-screen, before I can think about whether or not I'm interested in your products? If my computer is down and I'm seeking technical support, do you think waiting another minute for your splash screen page improves my mood? A cover page is just a way to guarantee that much more delay before any part of your content can be viewed; it's like putting a gigantic image on every page that the user simply ignores.
Registration pages have the same effect. I recently tried to get a firmware update for a Dell computer. So, I went to their site. The only way to proceed was to select whether I was a "small" or "medium" business, or a residential user. What if I'm not sure how people categorize my company? What if I'm a home user who happens to have a system which was a top-of-the-line enterprise server a couple of years ago? The categorization is rude, but most importantly, /it's not technical support/. The implication that I will get different support if I'm looking on my own time than I would if I were working for a large company is disturbing; worse yet, what if I enter the appropriate value, and I get to the page, and the product I'm looking for isn't listed? Does this mean that I should go back and look for it under a different category?
The purpose of your page is to provide certain content. It should not make this content harder to reach, and Dell's support system did precisely that to me. I tried a couple of times to figure it out. I couldn't find the correct magic cookie for my "system ID," and so the old server will just sit there warning me that the firmware is out of date; I can't get at the downloads, and even if I could with a lot more work, I don't want to spend the time.
By contrast -- and I assure you I had this experience before I started writing a column for IBM -- IBM's Web site allowed me to review FAQs and technical literature about a machine I hadn't even purchased yet, without any kind of registration. Toshiba, when they were in the home PC business, was also very good about this; I could go to their page, ask it to search for files for a given model, and get a list of the current versions of everything.
Users gain value from a page; time and annoyance are costs. When these costs exceed the expected value of the page, the user leaves. The faster you drive them away, the less useful your page is -- to you and to your users.
This week's action item: Monitor yourself when you're browsing. What kinds of things make you lose interest in a page? And check your own page -- how many users see your front page and never go any further?
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at crankyuser@seebs.plethora.net.