Today's prize for unhelpful error message goes to...

[jducoeur]

(drum roll, please)

... Microsoft Outlook, for the following delight:

Outlook is using an old copy of your Offline Folder file (.ost). Exit Outlook, delete the .ost file, and restart Outlook. A new file will be automatically created the next time you initiate a send/receive.

Okay, points to them for at least telling me roughly what I need to do, instead of simply crashing. But not only does it not offer to fix the problem for me, it doesn't tell me *where* this old .ost file is. I mean, I've got 150 Gig filled on this hard drive, and probably 50 major directories of Microsoft application crap. So I really have little desire to go hunting for some random file that happens to have the suffix .ost, and I'm pretty sure that Windows Search will churn for an hour looking for it.

(Help me, Obi-Wan Google. You're my only hope!)

ETA: Having just had a discussion at work about a very similar problem (an error message that said "missing required attribute 'source'" on an XML document, but not saying which node the missing element was on), let's draw a moral from both stories:

When you are writing an error message, remember to provide enough *context* to *solve* the problem.

Step back, and assume that you are a user who doesn't know the program perfectly. (After all, if they knew it perfectly, they probably wouldn't have this problem in the first place, right?) Make sure that you include enough breadcrumbs for them to find the solution quickly. Especially for an unrecoverable error, more information is usually better...

Comments

[redaxe.livejournal.com]

(seen via friendsfriends list)

If I were hunting a Microsoft file that wasn't a Windows subsidiary, I'd probably start by looking in my profile (under Documents and Settings, or whatever the equivalent in Vista/Win7 is -- I have a Win7 machine, but this isn't it). A right-click>Search of that folder would probably turn it up. If not, then I'd hunt under both Program Files/Microsoft and then Windows. But yeah, MS has too many places it stashes things.

Good luck!

[jducoeur]

Google did give me the answer, as expected. (user/AppData/Local/Microsoft/Outlook, which probably would have been in my top ten list of places to look. I do wish I really grokked the breakdown of "Local", "LocalLow" and "Roaming", though.)

But really: if the user has to look on Google to figure out what to do with your error message, you've *definitely* screwed up...

[doubleplus.livejournal.com]

Eh, I don't know. I barely look at the official documentation for a lot of things these days (especially Microsoft products), because I'm likely to find a better answer via Google. Why should error messages be any different? (Though, to be fair, the answer I find is often from the official documentation, it's just that Google is a much more efficient way to find it than table of contents, index, or in-site search.)

[jducoeur]

Sure, but the point is that the user shouldn't have to go searching anywhere in order to puzzle out what to do about an error message. An error that doesn't provide sufficient information about how to address it is broken. Sometimes for good reason, mind -- but most of the time, it's simply because the programmers are being lazy about it. It's very easy to write a bad error message; a good one often involves actual work...

[doubleplus.livejournal.com]

Yeah, you're right. This has the feel of "I can't think of a way this could actually happen, so it's not important to explain it, but just in case they can delete this file and fix it. Done!"

[dragonazure.livejournal.com]

When you are writing an error message, remember to provide enough *context* to *solve* the problem.

A concept I cannot seem to get across to our development teams--mainly because there is enough money to write the code that works, but not enough money to write the code that traps the errors with suffcient information to tell you what went wrong. And if you don't specify that you need it, they won't bother writing it--even to assist with their own debugging activities....

[metahacker.livejournal.com]

because there is enough money to write the code that works

As a usability specialist I am required by honor to say, "It doesn't work if users can't use it."

Also, a quick set of guidelines for developers will help them craft proper error messages as they code--it's often easier to write a good error message than a bad one, and rarely harder.

[dragonazure.livejournal.com]

I keep arguing that we need a user interface expert (or as they like to term it these days "Experience Modeler") to at least help us establish a standard set of guidelines. Unfortunately, that usually leads to the inevitable "if you are so smart, write us some"--which I seem to have copious amounts of time to do (NOT).

I don't disagree that it is easier to write a good error message, but for some reason, it isn't a discipline that seems to be taught in these quickie Java/language-du-jour certification classes--which is where we seem to get our developers from.

Sorry. I just had a You kids get offa my lawn moment....

[alexx-kay.livejournal.com]

+1

[aishabintjamil.livejournal.com]

I am reminded by this of a point back in the mid-1980's when I was working for a company which had decided to create an Ada compiler (very badly, but that's another story).

At one point while we were pouring over the spec and starting to run the validation tests, someone pointed out that there were a great many places in the spec which said "Issue an error message", but nowhere did it say "issue a meaningful error message". Therefore if we were feeling perverse, we could simply issue a message saying "syntax error" in every case where the required an error to be noted, and still pass the validation tests.

We did not in fact do that, but we considered the concept frequently.

[dragonazure.livejournal.com]

"Include an error message" at least acknowledges that the user would like some feedback when things go wrong.... I'd like to think that most developers are savvy enough to realize that once the software goes into 'production mode' that someone has to diagnose what happens when things don't go as expected. Obviously, I don't think that, though.... :( My experience has been disappointing: in some cases, *I've* had to write the messages and define the error conditions FOR the developers because they didn't actually understand how to write applications. They knew (sort of) how to write programs, but that isn't the same thing.

[metahacker.livejournal.com]

Hear, hear!

I summarize it for developers like this:

1. State what happened, in the user's language.
2. Explain why the user cares.
3. Give the user breadcrumbs for the next action.
4. Do it all in two lines, three max.

Optional is a code number or something, for more obscure errors, so you can escalate or Google it. Some people don't like "(Error PC_234_51234)", but it does jibe well with search-as-interface-to-all-knowledge.

[cellio]

Yeah, I am surprised by how often this problem occurs. :-(

When I was an undergrad I (like many others) had a part-time job doing odd jobs for a large project in the CS department. One of my early assignments was to rewrite a bunch of error messages. At the time I did not appreciate just how unusual this attention to such things would be in my future career. I probably should have sent a thank-you note years later when I realized it.

[dragonazure.livejournal.com]

Was that back when the sysadmin's ID was Cthulhu?

[cellio]

I don't remember. That is, Cthulhu was around, but I no longer remember in what capacity.