What’s A Poor User S’posed To Do?
October 30th, 2005
When trying to log into the ACM.org full text library, this error message appeared:
Click to see entire error message page.
It has such clever sentences, such as my personal favorite:
The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (1271:5) to (1271:67) in the template file F:\WWWROOT\PORTAL\V6\POPLOGIN.CFM.
Damn! I hate when that happens!
ACM isn’t the only site victimized by problems like this. This page appeared while trying to make a reservation on Marriott’s site:
No! Not Line 209 again! Oh, the humanity!
So, what is the user supposed to do with this information? What is the next step? Sure, you could (somehow) message the information to the site administrator. (And why doesn’t the system just automatically do that?) Then what?
If we can’t be sure we’ve eliminated all the error messages from our site, we need to ensure we design the experience we want a user to have when encountering one. Do we want them to go away? Do we want them to try an alternative approach or a workaround? Do we want them to come back when we’ve fixed it? (And when will that be?) What, exactly, do we want from them?
If we don’t tell them, it’s likely they’ll just give up on us. Is that what they were supposed to do?
Tweet
October 30th, 2005 at 6:05 pm
I’m glad you raised this point!
I’ve been working on the Web since 1998 and the ability to trap “internal” errors became available in Microsoft IIS in 2000. Ever since my web applications have hidden all error messages from users (and either save them in the database or email them directly to me) and instead provide a “user-friendly” explanation of what happened and what to do next.
If a site doesn’t do that, I attribute it to the laziness or total inexperience of the programmer in charge. There’s no excuse.