The worst design mistake would be saying we don't make them

This is Issue 3 of The Sensible Internet Design Letter.

If you're going to stick your neck out and say you stand behind a mantra as promising as "Sensible Internet Design," then buddy, you better mean it.

I received a gentle reminder of that mandate the other day. In a friendly e-mail message, brand-new TSIDL subscriber Jeff Foust brought a problem to my attention:

"The first time I clicked on the link in this message to confirm my subscription, I got the following error message:

'E-mail doesn't exist / already confirmed / or an invalid e-mail address'

"Not only is that not helpful (these are three very different error states!) it was also wrong: I got a message verifying I was subscribed. I did click on the link twice, and got the same message, so it's not clear whether the first or second attempt was successful. While it appears I am successfully subscribed, I thought you should know, since good handling of error messages would appear be a major part of 'Sensible Internet Design'! :-)"

Jeff's right, of course. And here I thought I had done so well by implementing a simple, plain-language replacement for the default "404 - File not found" error page on the Web site, not to mention combing through the language files in SI's PostNuke content system to rewrite error dialogs there.

But in my rush to launch the newsletter, using the generally fine MyMail list management program, I had not adequately worked over the error messages in the subscription routines deployed for this letter. Further, in attempts to scrub the list of invalid addresses, I apparently validated several of them prematurely, possibly including Jeff's.

OK, it's far from a proud moment. So what can we learn from it?

In some cases, a site manager would simply chalk these gaffes up to inexperience with the mail list program, or worse, blame its developers -- even though it's free, working, open-source software.

But the programmers are not guilty of poor error handling from their point of view. If you break the software into a flow chart, error routines and confirmation dialogs (the happy side of error handling) are written in everywhere they should be. The worst offense the programmers committed was vague prose, and no one ever claimed programmers could write like Chaucer, or even Jackie Collins.

You see, this is where responsibility for error handling splits between coders and designers -- at the point where any piece of software actually provides a placeholder for a specific error message. If a program has a routine to throw up a dialog, the designer must prepare that dialog to communicate how to resolve the error state and put the end user back on his or her intended workflow.

The same is true of Internet sites. I won't beat up on Webmasters who haven't replaced their default server error pages with custom, descriptive messages; you've heard enough already. But I'll remind you it's easy (one article pointing to instructions for different servers is linked below).

And I'll remind you -- as I learned again -- that it's your duty as designers to clean up existing error messages in third-party Web software you use. To ensure best customer experience, that duty also includes:

• Making sure you understand the error state, and all the possible ways a user could get there, before attempting to explain it to site visitors.
• Using plain, crystal-clear language. If you understand the cause-effect relationship, try to explain why and how the error occurred without belaboring it. Avoid server- or program-specific technobabble; instead, try for an explanation that would satisfy the editors of "The Way Things Work."
• Being polite, cordial, even apologetic. "Sorry" goes a long way. So does "please," if you're asking a user in an error state to do something to get back out. And even if it's most likely a user-caused error, never assign blame.
• Using humor only if you are confident that (a) it won't aggravate users who may already be frustrated by particularly difficult errors, and (b) your sense of humor plays well in writing. Avoid trying to deflect error-page rage with trite quips or, especially, insults.
• Offering a next step forward when possible, or at least one step back. If the error is not serious and the user does not need to take steps to correct it, allow him or her to proceed elsewhere confidently. If an escape path from the error state is not clearly available, at least allow the user to go back to the last "good" page before the error. If the error state came about because the user submitted a form, work with programmers to ensure that the backward step returns to that form and retains the information the user may have already keyed in before submitting the form.
• Remembering the Golden Rule of Web workflow: Do for your Web visitors what you would have other Web sites do for you.

Now, with those edicts in mind, I took a look at the error state and resulting dialog that spurred Jeff Foust's e-mail. He was right that at least one of those messages had to be incorrect -- in this case, it was the one that claimed "an invalid e-mail address."

Jeff clicked on a URL in an e-mail sent by MyMail. The fact he got the message in the first place shows the address he furnished was valid. So it was possible to arrive at this error state only if (a) the e-mail address within the confirmation URL he clicked did not match any addresses in the database, or (b) the address in the URL he clicked had already been confirmed (the most likely explanation in this case).

I rewrote the text of this error message, among others. It now reads:

"Beg your pardon. The newsletter system encountered a problem trying to validate your e-mail address. This usually happens for one of two reasons:

"1. The e-mail address has already been validated and the subscription confirmed. If this is the case, you should have received a second e-mail message verifying you are all set to receive the newsletter. You need not do anything else.

"2. The e-mail address does not exist in our database. Please check to be sure the URL you clicked to get here included your entire e-mail address. Some e-mail software breaks the URL onto more than one line. If that happens, please paste the two parts together in your browser's address bar and try again. If the URL looks OK to you, however, you may need to go back to the home page (link below) and submit the subscription form again."

Though explaining the nuances of URLs in plain-text e-mail is a challenge, I think this error dialog is at least closer to the pin. If nothing else, it gives the user options.