More website manner tips (with Keith Instone)

Adam Baker's theory column for March 15, 2001
Featuring Keith Instone of Usable Web, the premiere resource for internet usability information.

Summary: Custom error pages are better than stock error pages, and there are even better practical solutions that may eliminate the need for custom error pages to begin with.

Reduce the need for error pages by correcting mistakes automatically

Keith Instone responded to my column about website posture & manner, pointing out some additional concerns and possible solutions, many of them based on his experience running the valuable and popular Usable Web site:

Even better than a good 404 page is to fix the error and take users to a reasonable replacement page.

I have 2 levels of "error fixers" for Usable Web.

One fixes simple file naming changes, and takes users directly to the new location. For example, http://usableweb.com/sites/asktog.html is an old URL for the Ask Tog articles I have indexed. This goes quietly to the new URL.

Keith's simple solution is definitely necessary, and complements otherwise user-friendly URLs. There are a few reasons why auto-correcting "old" URLs are good for user experience:

If you have so many moved documents that creating self-correcting pages for all of them would be an insurmountable task, looking at web logs can give you a good indication of what old URLs are still popular. The logs should contain a list of URLs that produce 404 (not found) errors, and if a select few have relatively high request numbers (i.e. lots of people are still trying to access them) those particular URLs should be made into auto-correcting ones like Keith's.

A second program fixes more obscure errors by showing an error page and then going to a reasonable replacement after a few seconds. For example, I have a lot of typos in links to my site. One of them is http://usableweb.com/index2.htmll

This approach is a little more technical, perhaps making it less practical for general users (after all, they only tried to use the link, they didn't create it) but there are a couple of important implications.

Firstly, common typos in URLs should be automatically corrected, as I pointed out in my column on user-friendly URLs. Keith's is one of the few major websites that I know of that compensate for this common human error. It took a terribly long time for major word processing software to implement an automatic "teh" to "the" fix, so I suppose I am not surprised that the web, which is even less organized than the word processing software community, is still way below standards in terms of recognizing human error.

Secondly, the somewhat technical nature of Keith's error page at http://usableweb.com/index2.htmll can be of tremendous usefulness to web developers if they are linking to the wrong URL, and test their links (as all developers should). They'll quickly learn that they've made a mistake, and will be shown the new, correct link.

Another little trick is to have all 404 error messages generate an EMAIL to whoever is in charge of fixing the problems. That is incentive to fix those errors!

Great idea, especially for large websites with complex administration.

Don't leave WebTV users out of the helpful-error-page loop

Keith also mentioned a few things that I didn't know, with regard to WebTV, which, unfortunately, I have never had the opportunity to explore in depth:

Also, did you know that WebTV users won't see your usable 404 message without some trickery? WebTV is "smart" and shows its own 404 messages, which I agree are more usable than the standard web server responses.

This is where the division between sites and browsers is getting blurry, like putting Javascript "back" buttons on your pages. It will take us a while to figure out which functionality is best served by which layer of the user experience.

Anyway, http://developer.webtv.net/authoring/no404/ tells you what is going on and how to fix it so WebTV users can take advantage of your usable 404 pages.

I'm going to investigate that information and make a decision about whether or not to let WebTV handle the errors, or force users to see my custom merges.net error pages.

My decision will be based on some thought about the point that Keith made regarding the division between sites and browsers. On the one hand, if the user has been using my website for some time, an error page consistent with the interface of my website has a lot of advantages. On the other hand, however, since relatively few websites handle errors gracefully, a consistent, practical browser-specific error page might be more useful. I doubt that any current implementation would be as good as a site-specific error page, but future "smarter" browsers might offer more useful solutions.

Thanks for your great solutions, Keith!

Adam Baker is a user experience designer who's worked at Google, Apple, BlackBerry, and Marketcircle, and mentored startups in Vancouver.