The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Conversational Error Messages,guid,ab7a6146-b383-4132-8843-0265ca9947b4.aspx

This was a funny read, but it did make me wonder how people feel about these sorts of error messages. The second one is a little smarty-pantsy, but I like the personal style of the first.

Also, what is the general consensus about error messages that use the personal pronoun "I", such as "I was unable to find the file 'xyz.txt'".

Obviously in a business application or an application with lots of users like MS Word, this may be innappropriate, but if you were writing games or educational software, would it be ok? Would it give the software a personal feeling, or an amateurish feeling?
Paul Stovell Send private email
Monday, September 19, 2005
Those particular examples he has are really terrible error messages because they say the same useless thing as before only now take much much longer to say it.

But I also believe that conversational error messages are better than error codes. Its just that MS has not done a good job here.
Rich Rogers
Monday, September 19, 2005
From a support point of view, I prefer that all error messages commence with a unique identifier (aka error message number). It makes it so much easier to find where in the code they were issued, look them up in a knowledge database, etc.
Monday, September 19, 2005
I think they're both horrid

They provide no real useful info to the user

They provide no guidance on how to fix the problem (or where to look for more info)

And they both could easily come across, both because of style and content, as arrogant, non-caring and disdainful of user's.

I imagine a lot users, even non-technie ones, would translate the messsage in their heads to something like "These guys have buggy software. They're too lazy or ashamed to explain the problem or tell me how to work around it. And they think they just fob me off with some pseudo-cutesy garbage."

I think it's the Clippy of error messages.

And on a philosophical point:

Doesn't it logically completely break/ignore the desktop metaphor?  Since when did the files and tools on your desk, start being people? 

And on a historical point:

People are wise to this now. They know computers are devices, not personalities.

There was a sort of duel between programs which said messages this way (not just errors) - and the non-conversational style predominated.  For good reason I think. Games (with the exception of games where you are playing against a simulated-personality), being a near perfect example:
S Tanna
Monday, September 19, 2005
> People are wise to this now. They know computers are devices, not personalities.

At some level yes, but mostly we are hard wired to anthropomoarphize everything. So even though people know it's a device, they will still interact with a computer like it is a person.
son of parnas
Monday, September 19, 2005
When you get a cutesy message when you lose in game, do you think "how nice", or do you want to smash the monitor in?

"Nice try. You gave me a run for my money. But I beat you. Better luck next time!"

Multiply that feeling by 100 times, when it's a serious error like "I've crashed and lost the last 2 hours work.", or "I've gone mad and lost all the data on your hard-disk.".

Multiply that feeling by 1,000 times, when it won't even tell you why: "I've gone mad and lost all the data on your hard-disk. I don't know that happened, so I can't give you advice how to avoid this situation in future. Please be aware that I may go crazy again in future, and wipe your data again. So, I'd suggest you take regular back ups. Sorry about that. I am really a nice guy, but everybody has has their ups and downs.".
S Tanna
Monday, September 19, 2005
I'm sorry Dave, I can't let you do that.
HAL 9000
Monday, September 19, 2005
I'd prefer messages like "Tried to load xyz.dll and failed.", or "Tried to access xyz.dll and some other task has it locked", or "Tried to access the CD and could not find it in the drive."

Clearly, the program was trying to do something SPECIFIC, and got an error message back that the specific thing didn't work.  Error messages like "something went wrong" are easy to write, but as has been said, give NO hint or any additional data that the user could use to tweak and try again.

"Wait a little while and try again" is right up there with "reinstall the operating system and try again."  What's going to change in that "little while" that the program is hoping for?

And personally I have no problem with the program in the machine referring to itself as "I".  It worked for HAL, after all.
Monday, September 19, 2005
son of parnas
Monday, September 19, 2005
Son of P: Thanks for the link!

I like error messages that are short and to the point, myself, and pretty much in line with what Jakob Nielsen wrote.

But his site... my goodness. For balance, I had to go to the Fab Five and read a little "Design Eye for the Usability Guy":
EKB Send private email
Monday, September 19, 2005

Contingency Design: Maximizing Online Profitability By Helping People When Things Go Wrong

The useit site follows the same logic the hair dressers always have horrible hair. Don't know why.
son of parnas
Monday, September 19, 2005
So anyone got a C macro that can hash the __FILE__ so you can append the app-version, the hash of the name, and the __LINE__ into a single identifier for error and warning message preambles?  I'd like to use something like:

if(some_condition_failed) {
  msgbox(ERRORLOCATION "Sorry about this error, whatever");

where ERRORLOCATION was said macro that makes the appropriate preamble that the developer can reverse to find out where the problem was.

(I don't like long lists of 'assigned' error preambles; keeping them uptodate is far too much work and never really happens.  Somehow knowing version, filename and linenumber seems far more durable.)
new nick, new rep
Tuesday, September 20, 2005
Nick, I entirely agree.

But the problem with the Macro solution is that you WANT the __FILE__ and __LINE__ to be the ones close to where the error happened, not the ones in your error routine that output the error.

Thus I usually make a "report_error" subroutine, that gets the current __FILE__ and __LINE__ passed as parameters.  That way, you get the location of the Call (which should be close to the error detection).
Wednesday, September 21, 2005
> They know computers are devices

I do know that, too, nevertheless, I refer to my computer as he/him when he doesn't do what I want him to do.

When I am really angry, I even address the computer with something like
  YOU stupid something of a beutiful thing
René Nyffenegger
Thursday, September 22, 2005
I came across this once @ work.

Msg -> "Error: This is an error in processing ...."
Msg Definition -> "The error message is a message to indicate an error in processing ..."
Msg Action -> "Contact customer support if this error is reproducible".

I went bonkers seeing such redundant messages, this normally doesnt get past the peer reviews and is usually flamed left, right and center.
It can't be... but I could be wrong Send private email
Friday, September 23, 2005
To munge __FILE__ and __LINE__ file together in C/C++ its something like:


But that will make a pretty fugly error message.
Andy Brice Send private email
Monday, October 03, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz