Slashdot Mirror
How Do You Get Users To Read Error Messages?
A BOFH writes "The longer I do desktop support, the more it becomes obvious that my users don't read anything that appears on their screen. Instead, they memorize a series of buttons to press to get whatever result they want and if anything unexpected happens, they're completely lost. Error logs help a lot, but they have their limits. I've been toying with a few ideas, but I don't know if any of them will work and I was hoping my fellow Slashdotters could point me in the right direction. For example, I was thinking about creating icons or logos to identify specific errors. They might not remember that an error is about 'uninitialized data' but they might be more able to remember that they got the 'puppy error' if I showed a puppy picture next to the error message. Or for times when finding images is too time consuming, you could create simple logos from letters, numbers, symbols, colors, or shapes, so you could have the 'red 5' error or 'blue square' error (or any combination of those elements). I've even wondered if it would be possible to expand that to cover the other senses, for example, playing a unique sound with the error. Unfortunately, haptic and olfactory feedback aren't readily available. I like to think that my users would remember the error that caused them to get a swift kick in the balls. And if they forgot it anyhow, I could always help them reproduce it. Does anyone else have experience with ideas like these? Did it work?"
Using Bluetooth to activate a transmitter in the seats of our users, we've had a 671% increase in efficiency when helping our users due to increased "awareness" of error messages.
and let out a big screech followed by the sound of glass breaking and it saying "Danger Will Robinson! Danger!"
That which does not kill me only postpones the inevitable.
they memorize a series of buttons to press to get whatever result they want and if anything unexpected happens, they're completely lost.
Sounds like their jobs are easily automated. Tell them if they don't pay closer attention to error messages you'll inform their boss how to replace them with another computer program. ;)
Developers: We can use your help.
Just put a timer on the buttons that won't let them click it for 10 seconds... but ultimately you can't fix stupid.
I do like the ball-kicking error idea, but be careful which one you use. Windows can be testy and the last thing you need unprovoked genital damage when you are trying to fix a workstation.
Do yourself a favour and produce a one-click tool that collects all the info that you need (logfiles, version numbers, registry listings) and sends it to you. If you can make it 0-click, even better.
If you were blocking sigs, you wouldn't have to read this.
...with no "Dismiss" button. The message would stay on the screen until the user talks to you and you tell them how to get rid of it.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
with super big text, and a timer to keep it on the screen for a certain amount of time. I don't think they'd miss that.
I've even wondered if it would be possible to expand that to cover the other senses, for example, playing a unique sound with the error
You're going about this the wrong way. You don't make the user remember, you make their colleagues remember. Supply your users with a 5.1 sound system attached to their PC and when the user encounters an error, the speakers blast "HEY EVERYBODY, I'M WATCHING PORNO OVER HERE".
As I said, make it a memorable experience.
8 of 13 people found this answer helpful. Did you?
I've often described the action of quickly clicking on ok on whatever window pops up as the wack-a-mole behavior. With Windows, I can't say I blame users for this behavior because the popups that come up are so frequent and so useless that they've kinda been trained to do this. Linux errors are usually more useful, descriptive and since the order of the buttons change from window to window, you have to be more careful. ;-)
There should be no errors. Period. Your program should not allow errors.
Now, if you're talking about a programming language or programming environment, that's different, but someone writing a program using your compiler/interpreter would be expected to read and understand the messages. But even there, some efforts are lax and feebel. I've gotten errors in MS Access that say error n: there is no message for this error". Boundary conditions for common "errors" are handled poorly; end of file, for example. If you make your own next/previous buttons to replace the puny little almost invisible Access buttons, there is no easy way to determming the beginning of the file, and Access returns an error in a big scary "stop" combo. This should be there in a debug mode, but a user shouldn't see it -- and Access' docs should be a lot more clear.
I'm not just talking about Microsoft, you're all bad about it. Well, not you -- your PHBs who want it shipped yesterday when the damned thing's barely out of alpha are bad about it.
With a graphics program or word processor, for an end user to see an error message is inexcusable. If your users are getting errors, your program is poorly designed.
Free Martian Whores!
We have found that the only way to make users take responsibility for errors is to give them a penalty for forcing the error to go away. For starters, where possible, the error wont actually close for them unless we enter an admin password to make it go away, and if they reboot to get rid of it (Task Manager is disabled on all client PC's) the machine will not open the application that crashed for 15 minutes. Of course, this all depends on the type of users you are dealing with, as more technically adept users wouldnt accept this kind of system, but after trying for literally YEARS to make users take responsibility for crashes and making sure the IT department is aware of them in order to fix the issue before it gets too hard to manage, these are the only steps that worked. Now, all of our end users are aware that if they ignore errors, they are going to suffer for it themselves.
...are the worst evil ever unleashed on support analysts. There's nothing more fun than your average dead-ender mindlessly reading eighteen Java bomb strings and ending with "so that's the problem." Why not just display a skull and crossbones image? It'd probably save some time.
Is it just my observation, or is eldavojohn an idiot?
Show the message in full screen using a blue background and white foreground. Just like a BSOD.
The largest prime factor of my UID is 263267.
Users have already trouble copy-pasting error message text into a mail (or reading it aloud on the phone), so how the hell are they going to do it with a sound or a smell? Well, the sound, they could still record it, and attach the recording to the mail, but you can be sure that the recording will be spoiled by the perp's coworker loudly sneezing or coughing midway through. After all, lusers are not afraid of sending in screenshots of error messages half-hidden by other windows either.
No, I think the problem is not the messages (textual messages should be the easiest to deal with, especially when asking for support via mail), but rather the users. And to fix those, you just need a baseball bat...
I had done something very similar, but I kept it very simple for troubleshooting.
3 colours: red, amber, green
3 shapes: circle, square, triangle
Another idea I was toying with was to substitute traffic signs: ie. stop, yield, caution, etc.. but I found that people are used to ignoring those.
With my setup, it gave me 9 distinct error levels (more if I used them in combination), but 9 was good enough for me to track down most problems.
Shapes:
Circle - Bad Input (i.e. data field entry)
Square - Bad Output (i.e. printer jam)
Triangle - Back-end (db/php/html, etc..)
Red, amber, Green = error levels
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
We also had the same issue at first, my apologies for not clarifying. Our version 2.0 system includes a small amount of absorbent material woven into teh seat bottom that can hold 50X it's weight in liquid. We now call the system the Electric Shock Wow system.
Tell them that reading the message will enlarge their penis... which isn't too hard to achieve anyway.
--- What?
In the late 90's our startup had HP as a customer for a new on-line product. One day, about six months after they had become a customer, we get a call saying our product does not work. At the end of a SIX HOUR support call, I got on a plane for a cross-country flight because we just could not duplicate or figure out the problem. At 7:00 AM that morning I arrive, and at about 7:03 AM had the problem figured out. HP had recently made a change to their nework removing the browser ID string when employees were surfing the net. Our product needed that information for some processing. Even though the error message was CLEARLY being displayed, not once in the previous day's support call did this get mentioned. "Oh, that happens all the time, it happens with all sorts of applications, so we just ignore it." We had a fix in place by 10 AM and I was back on a cross country flight that afternoon. All because the customer ignored an error message.
Dear Slashdot,
I am filled with a black, unutterable contempt for the troglodytic users of my application. Can you suggest ways to translate this contempt into software?
Read my blog.
It's not an error. Errors prevent you from continuing. The only thing approaching an error is the little box telling you there's a problem. That is solved by the user clicking "OK".
The entire way errors are handled is wrong. I don't know what the solution is but I very much doubt it's a simple modification to the current fundamentally flawed system.
I have been wondering about this for 30 years. End users are not interested in learning how the computer software works, except for how it lets them do their job. On-screen messages, manuals, fax-back systems, wiki pages, they don't care. What they want is to pick up the phone, make a call, and have someone tell them what to do. At first, I thought it was them being lazy. However, I now think it is closer to why programmers don't like to be interrupted in the middle of a task. The user has a mental model built up of their task, and they don't want to risk losing it while they search for information on an error. Making a phone call, and having someone else walk them through the problem solving means they can maintain their task in "main memory". For them, it is more efficient.
Why, without your clothes, you're naked, Miss Dudley!
Stop pushing the inadequacies of the program on the users. If you come across the error, then log it. Why are you relying on a person to sit there and read back to you something that could just as easily be written to a file that they could send to you or read directly.
The error message has to have a good plot and some character development. Pull the users in with that and then get the error message across. Ok, seriously, as a writer of error messages at times, I have found putting in 'interesting' wording works sometimes with some of the more intelligent users. Unfortunately, there will always be the ones that just want someone else to do their work. I suggest that they be burned because they're witches.
Fat, drunk, and stupid is no way to go through life, son.
Every day I have to fire up a Microsoft Access database program to clock in.
Every day the first thing it does is pop up a dialog box that says something like, "Only run this if you trust it".
I just hit OK.
It's not my problem if it works right or not.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
a risk based approach is required, so that users know that occasionally a message box will appear that will have serious negative consequences if they fail to take the correct action.
For example "If you don't turn around right now I'm going to smack you over the head with a baseball bat" [OK]
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
Amiga had this right. Use a little humor with your messages, it may diffuse the anger and get some sympathy.
Add an input field on the error message that makes them type the text of the error (or the key bits, anyway) before they are allowed to dismess it.
i've had this happen to me too. its to the point i log everything and i tell users i will not help them unless they provide a screenshot of the error and a log.
at that point you either get the screenshot and a log or the user stops using the product. either way support costs goes way down.
Data is pants.
As a corrallary: Reduce the number of errors/confirmation dialogs they see on a regular basis. If they regularly have to click-past dialogs, they get trained to do that without reading them. If the presence of a dialog means 'call helpdesk, and read the dialog to them', they are more likely to pay attention to it.
Make seeing a dialog an exceptional case, not a normal case.
'Sensible' is a curse word.
I was the alpha geek on a Help Desk at a multi-state corporation, and the CIO had worked with me as an engineer before getting the job. When people too (self-)important to call the Help Desk had a problem, they would call him directly. He would give them to me, and I would make sure they were kept happy and their issues got resolved.
One day, after a vice-president had SCREAMED at him because they couldn't log on, he asked me what I had done to fix it.
I told him that their 'caps lock' had been on.
He asked, "Doesn't the Windows error message remind users to check that?"
I told him, "His lips got tired before he read down that far."
Number one answer would be to make error messages that are actually useful.
Here's an error I got recently. It's a pretty common error in our SAP* system: "Error Code: -1 Error Desciption: Code: K/101. Error occurred in derivation rule. See long text." (Please note that there is no long text.)
Here's another recent error message I encountered. Is this helpful?
You have either entered an invalid Member ID, an invalid PIN, or your User Account is locked. Please validate that you are entering the correct member ID and PIN and try to log in again. "
Translation: when you did the mandatory password change (required every 90 days), you entered a password that contained the } character. Although the rules say you must include symbol characters, we didn't mean that symbol character.
And dozens of other equally useless ones.
--
*"SAP" is not actually an acronym. It is the word used to describe the customers who have been persuaded to buy this software.
http://www.geoffreylandis.com
As a game designer, and sometime game UI designer, I feel your pain.
The best way to get people to read your error messages is to have very few of them. People just tune them out. If you're tossing up error messages for things like synchronizing to network shares before the user really needs to, or connecting to 3rd party tools that the individual tool can handle the error for, cut those. They'll get to those errors later anyway, or the problem will be fixed by then. The only error messages should happen when it is impossible to do what the user asked.
The ones that you do have should be 7 words or less, and should be both meaningful and in plain english (even for engineers). "Uninitialized Data" is technobabble, and "It Didn't Work" doesn't tell you anything. "Couldn't connect to the mail server" is much better, as it tells the user exactly what was wrong, but within a small enough space that by glancing at the textbox the user has already read it.
Icons are most likely going to confuse your users unless they directly relate to the error at hand. "Warning: Trojan Detected [panda kicking a soccer ball]" might be cute, but if people are already confused they're going to have a hard time remembering even the soccer ball. The conflict of visual imagery just muddies the water. Throw a needle on the screen, and everybody will remember in a panic that the error had a needle up there, but not what the text said. If that snippet of information is not enough to work from, you'll need to find a different solution.
The ______ Agenda
Funny error messages. really funny. not 'microsoft' funny.
Read radical news here
I've found, that promising sweets, say a tiny pack of gummibears, for any new error, that has not been seen before motivated everyone.
Simply ask them to make screenshots to prove that it is a new error and you are of.
Think about it. Finding Bugs this way makes fun and is totally worth the packet of sweets.
This really works!
I had a lengthy discussion with some of our field engineers, and a few of our customers, about a year ago about how they use the documentation to troubleshoot problems. My main goal was to see if there was something that we could do to get customers to read the docs more (and call support less).
Eventually, someone cut to the heart of the issue from there side. Basically, he said "Do you know how much I pay each year for my support contract? No? Well, it's a lot. If I have any problems that don't fix themselves in under five minutes, I'm going to pick up the phone and call you. I'm paying you to support me if I have trouble, I shouldn't have to troubleshoot it myself."
"uninitialized data" is meaningless. It's something only a programmer would understand.
Instead tell the user what *he* did wrong and tell him how to correct the situation.
"No recipient address given. Please enter the the e-mail address of the recipient and try again".
This is your sig. There are thousands more, but this one is yours.
LART
Welcome to the Panopticon. Used to be a prison, now it's your home.
Okay so this is technically a readme file, but it is still among the best technical documentation I've ever seen shipped with a piece of software. It came with the program "DV Rack", a video capture application written by Serious Magic...
Oh, good.... You're reading this file. You are indeed a wise person who takes
direction well. Blessings be upon you!
IMPORTANT!
WHAT NOT TO DO:
All the captured video clips in this folder (and any subfolders in it) must
remain unmodified and exactly where they are for DV Rack to fully and properly
function. You see, DV Rack has an internal Database that puts the clips here
and this Database bloody well expects them to still be here the next time it
comes around looking for them. Pay attention because this Database has a
personality much like the deity figure in some religions (say, Pan or Loki). It
is a singularly temperamental, unforgiving, and capricious Database Deity. It
knows how to Smite and, trust us, you don't want any smiting going on around
your clips. The only way to make the Database Deity cranky is to mess with the
clips it puts here in this one folder.
Editing, deleting, or renaming these clips will result in inexplicable, random,
and very likely BAD and NAUGHTY behavior on the part of DV Rack. No kidding,
this normally elegant and refined software will start acting like a petulant
three-year-old who is hours past nappy time and just had its ice cream taken
away. No one wants that! So PLEASE do not perform any of these actions on any
clips in this folder. However, if DV Rack is not running, you can use Windows
to copy of one or more clips in this folder to somewhere else on your hard
drive (outside the DV Rack folders). But don't even THINK about ever putting
them back here.
WHAT YOU SHOULD DO INSTEAD:
The instant, easy, proper (and painless) way to get your clutches on these
clips is to first use the magic "Eject" button in the DVR. DV Rack will
graciously take the clips from the evil clutches of the Database and put them
next door, over in the "Ejected Clips" folder. Life is easy over there. No
rules. No consequences. No three-year-olds.
So remember, don't touch the clips unless they're in the "Ejected Clips" folder
or the "Garbage Clips" folder. If you do, don't come crying to us like a three-
year-old who just had its ice cream taken away. You have been warned...
The DV Rack Team Thanks You For Your Most Benevolent Cooperation
Unfortunately, Serious Magic was bought out by Adobe, who decided to write a more "corporate" version of this...and inflate the app size from 18MBytes to over 400.
Users have been conditioned to simply click away message boxes as quickly as possible and get on with their lives.
A Windows computer is constantly popping up boxes that get in your way. Sometimes it's just to inform you that a wireless network was found... Other times it's asking for confirmation for something... Other times it's a warning... Sometimes it's an error...
Folks don't evaluate what the message says, they just make it go away.
You can put all the puppies and red numbers and blue squares as you want... They're still going to click it away just as quick as they can.
You could alleviate this to a certain degree by taking away their ability to clear the error message. Put in an error code somewhere, along with a phone number for technical support, and no way to close the box. They'll call you and you can have them read off whatever you need. Then you can tell them whatever bizarre combination of keys will actually close the box.
A better solution would be to simply write a log of the error message when the box is generated, then you don't need to rely on the user to do much of anything.
"Work is the curse of the drinking classes." -Oscar Wilde
Q: How do you get users to read error messages?
A: How do you write error messages that are worth reading?
Commentary: Users do not read error messages because they are mystified by them. To mystify them willfully only increases their resistance.
The first job is to create error messages that actually help the user. Users are conditioned by the generally crappy state of error messages to ignore them. If you provide helpful error messages then the users that *can* be helped can be trained to read them. It's operant conditioning -- like giving a rat a food pellet for successfully navigating a maze.
The very first thing you should do with error messages is pull them all together into some kind of document. This document should have (1) an unambiguous ID for the error; (2) a description of *what* happened ; (2) a description or at least a guess for *why* it happened; (3a) the impact of the error on the user (3b) how the user can recover from the error; (3c) what the programmer can do to avoid this; (4) what the user needs to do in the future.
Note that 3b also implies that *you* should consider how the program is apt to behave after the error message is displayed so you can offer the user sensible choices. For example, if the program fails to write the application preferences file on exiting, it makes sense to give the user both retry and cancel options, rather than sending him into a pointless loop that requires him to shoot the process down.
Then you write an error message that tells the user roughly what happened, what the impact on him may be, what he needs to do to get out of the corner he's painted himself into, and what he can do in the future. This should always include an unique message identifier for your use.
Example:
Please note this error number: #1234. You will need it if you contact technical support.
The program was unable to update the application preferences file. That is the file that stores the settings you have chosen for things like preferred document styles and last document viewed (choose "More Information" for details).
File updates can fail when the security permissions on the preferences file or directory ave been set to prevent changes; when more than one program is editing the preferences file at the same time; or when the computer's file system is damaged.
You can check for these kinds of problems (chose "More help" for instructions) then choose "Retry" to see if the problem is solved. If you choose "Ignore Error" the program will continue without saving any preference changes. If this error persists it is recommended that you check the security settings, permissions and integrity of your filesystem.
[More information] [Retry] [Ignore Error]
Now if this sounds like a pain in the ass, it *is*. But it's a much better approach than trying to trick users into reading a piece-of-shit error message like "File operation failed" for a condition like that described.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Some advice for programmers trying to do interface design: Don't. Leave question like this to an interface designer. If you can't afford one, or you want to do it anway, a good book for starters is "The Design of Everyday Things" by Don Norman, it's not even expensive. Further, stop treating users as a problem in the system. Every user has his own model on how the system works. This model is very likely very different from the programmers model. Your task as an interface designer is to teach the user enough about the system (or it's model), so he can use the system successfully. Error messages don't help very much, as you've figured out, users don't read them. The lesson is, don't try to force the user to read error messages, instead find other ways to communicate the model. Often, it's a good idea to think about the problem in an abstract way. For example, we have a similar problem at the place I work. There are two doors next to each other, one you should use, the other one you mustn't because it triggers the alarm. They tried to fix it by attaching a sign saying not to use that door. Needless to say, it didn't work, because noone read the sign. Just like your error messages, this sign was completely ignored. It's not wrong of the users to ignore the sign, quite the opposite: We have to filter out information to survive. If you pass through your environment, you too ignore information, i. e. I don't think you read every sign in your proximity. I have no idea why they couldn't come up with a better solution for the door: Locking it would be very easy. Even better, by removing the door handles it would be very clear that the door can't be used.
For example, I was thinking about creating icons or logos to identify specific errors.
Choice 1) I assume you have a company directory with pictures of personnel. Use them. "I got a Patty Sue error...". I have, in fact, done this. It is best to use well known personnel (the receptionist, the director, etc)
Choice 2) I assume, being a slashdotter, you have a vast collection of Pr0n. Use them. "I got a Goatse error...". I threatened to do this, but never actually did it.
Choice 3) Combine #1 and #2. This is by far the funniest if you make pictures that "us slashdotters" would recognize but the general public would be completely unaware of. "Well, I got an error message, it has those two women from accounting, and a cup..." "So, the error message has a bunch of lemons at a birthday party" "After it stopped working, I see a goat on the left side and the Mediterranean Sea on the right side"
Much more boring, yet almost as illegal, is to violate copyright laws and include cartoons. Oh, you say you got a dilbert error? A family circus error, that'll take awhile to fix.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I have had the "filtering out" as well when I tried to explain somebody where to enter the internal domain name. They kept using google and obviously did not get to the screen. So I went to a screen that I knew they were able to see and ask what they saw. I noticed that they skipped information and asked them if they saw X. The answer was "Yes".
Even when i told the person that I needed each and every detail they saw, they kept filtering out importand stuff.
Again, this was just WHERE they needed to put the URL so they could go to the correct page. i tried explaining it with:
What do you see on top in the blue bar? The answer was "Nothing". Do you see the blue E with "Shlashdot Comments" (as I see now)? "Yes" What is written next to it? They gave the correct answer. What is right below it? "Nothing". Do you see a field that says "http://...."? "Yes" What does that field say? "Nothing".
Took me about an hour to get it explained where they needed to type "http://intranet". My guess is that some people rather give no information then give the wrong information.
Don't fight for your country, if your country does not fight for you.
Eventually, someone cut to the heart of the issue from there side. Basically, he said "Do you know how much I pay each year for my support contract? No? Well, it's a lot. If I have any problems that don't fix themselves in under five minutes, I'm going to pick up the phone and call you. I'm paying you to support me if I have trouble, I shouldn't have to troubleshoot it myself."
Perhaps so but there is a big difference between not knowing how to use your crap and your crap being broke. So in cases like this, you have to clearly establish whether "technical support" includes "training".
All that said, I arrange things so that I automate or just do for the users as many things as possible because most of them can only be bothered to learn things by rote which they write on a sticky note....usually with passwords right on it.
I wrote the registration software for a student run job fair. Spelled out on the first page are a few ground rules "We cannot accept credit cards" etc.
Every single semester we'd get some rep that "never saw that" or claimed we "changed the rules".
The final iteration that seemed to work was a 2 - 5 digit, randomly generated 'validation codes' that was in the 2nd and 4th paragraphs.
We'd often get the HR rep that would e-mail us:
"Did you read the instructions?"
"Yes"
"Everything you need is in the instructions."
Occasionally get we'd get some irate HR rep: ...... "Your first validation code is: 23984. Payment methods are Check or Cash. No credit cards are accepted."
"You e-mailed me that they were in the instructions. I can't find them anywhere. We have to register now."
(and this is where you play dumb)
"Oh, I'm so sorry. They should be in the instructions. It may be a software bug. Could you please read the instructions to us".
"Do you have any more questions". (Although usually you'd just get a click after they hit the words "Your validation code is".
I have had similar problems, and have found that
- a full screen fatal error message and
- a stop of all activity
is necessary to get most people to pay attention to an error message. Otherwise, people will ignore even the most dire warnings.
Not as much ignoring as in maybe preoccupied in other things, like that Sukhoi chasing him and SAMs firing big explodey things at him... at those points in time even fighter pilots might not realize that he's headed to a big fat mountain real fast.
What time is it/will be over there? Check with my iPhone app!
ultimately you can't fix stupid.
You absolutely can. It's very easy: discipline people and if they keep doing it, fire them.
It'll probably only take one person before everyone else starts paying more attention. In this economy, it's easy to find replacements (especially if the people in your company are really this stupid.) Lots of folks out there looking for something better than Walmart or flippin' burgers.
Please help metamoderate.
I think the core problem is, perhaps, with the mindset of most software developers. They think logically and prefer a computer to immediately notify them about exactly what's wrong, as soon as an issue arises. They're also accustomed to the traditional way errors are reported, and feel most comfortable making things stick to "tried and true" methods.
The typical user, however, doesn't see any of that as advantageous or even sensible.
Take the example you mentioned, where your users were clicking through a dialog that detects hardware is missing, and then complaining about the main UI coming up and telling them the hardware is not connected. To a user, they've got a specific process they want the machine to complete, and they'd like to go through the required steps they memorized to do the process without any unexpected interruptions in the middle of the input. Such interruptions lead to them "clicking through" the boxes without reading them.
So what would improve this? I think users would like computers to ignore error conditions until they're done with all input related to performing an operation, for starters. Don't want them to click through a warning dialog? Ok ... then don't present them with it until the end. (EG. If a printer is disconnected, either notify them of this state BEFORE they even begin inputting anything into the portion of your application that generates printed reports, or hold off until they're finished and they click "print". At that point, give them a friendly error telling them the printer seems to be disconnected, and their print job will complete automatically, once they re-attach it.)
On the same note, *friendly* error messages are key, too. I can't begin to count the number of times I've received an error dialog box in an application that told me nothing useful. I know something just went wrong in the program, but that's about it. Some apps like to dump a bunch of numerical error codes at the user, with expectations that somehow, this data will get forwarded on to one of the programmers who actually understands it. In reality? There's a near 0% chance of that ever happening! The developers at most companies are insulated from the end-users by layers of "customer service and support" people. And what about apps no longer being actively supported at all? Their developers have moved on and probably don't even REMEMBER what those numerical error codes mean anymore if you COULD contact them!
It's no wonder users just "click through" the error boxes these days! They're conditioned to expect the messages do nothing to help them.
Stop trying to change the user, its much easier to change application. The application should be collecting evidence anytime an error is encountered. To make it easier on the user there should be some sort of builtin mechanism to collect this evidence. Software is built to make things easier and less complex for the user. The collection of this evidence could be triggered when any error occurs and then transmitted to the source developers when an error occurs. Think about microsoft error reporting. Be proactive and when an error occurs have a help desk incident created and contact the end user to solve the problem if it occurs multiple times. Help stop the user from hitting their thumbs with the error if they don't learn from the pain the first time. Its possible the end user could just get frustrated enough and blame the hammer. With the end result being the end user throwing away the hammer and going out to buy a new one. When they hit their thumb again they aren't going to think that they are doing something wrong, users never do.
Users will /not/ read error messages. Office workers are the worst for this.
We use a horrible bespoke system which I've somehow managed to end up supporting. Most of the error messages which pop up are cryptic, internally specific, standard Delphi error messages. That's if we even get to /see/ an error. Sometimes the app just silently fails and you have to know that clicking on another action button will allow you to switch away from the failed task.
If you want users to act appropriately in an error situation, it's best to (and this is in order of preference, highest first): -
1) Not end up in an error situation. /warning/ (not a blocking error dialog!).
2) Make it very difficult for users to create an error situation.
3) Inline-highlight any user entry which may cause an error situation, before the commit a task. Potentially with a little tooltip
4) Suggest alternate values for user-input where they have entered an erroneous value. At least provide an example.
5) Show a very context-specific message which explains the error. Provide a link to the help text.
The main idea is to avoid interrupting the user's train of thought whilst they are (trying) to use your software. If every error results in a 'blah blah blah, click OK to continue' dialog, it pisses people off.
Users see errors as the fault of the software first. I suppose what we're talking about here is interface etiquette. You shouldn't insult users or make them feel stupid. The best example I can think of is in Google's "did you mean ....?" interaction. It doesn't get more elegant than that.
If you absolutely must interrupt the user's workflow due to an uncorrectible error, tell them exactly what happened, suggest how it can be fixed and make the thing easy to read. Tall, narrow window is easier to read than wide, short window full of error text. Highlight very clearly the steps the user needs to take to get rid of your error message and continue on with their work. Most likely, this is the only text they will read. How many times have you heard "how do I get rid of this?" or "something came up on the screen and I don't know what to do"?
OK, granted, some people are still so blind/dumb that they won't take any notice. Those people will either call their tech, or at least nudge someone in the same office 'who knows a bit about computer stuff' to come over and take a look.
Please note this error number: #1234. You will need it if you contact technical support.
The program was unable to update the application preferences file. That is the file that stores the settings you have chosen for things like preferred document styles and last document viewed (choose "More Information" for details).
File updates can fail when the security permissions on the preferences file or directory ave been set to prevent changes; when more than one program is editing the preferences file at the same time; or when the computer's file system is damaged.
You can check for these kinds of problems (chose "More help" for instructions) then choose "Retry" to see if the problem is solved. If you choose "Ignore Error" the program will continue without saving any preference changes. If this error persists it is recommended that you check the security settings, permissions and integrity of your filesystem.
[More information] [Retry] [Ignore Error]
tl,dr
Seriously. You might as well make "Ignore error" the default.
Perhaps you should try understanding the problem domain a bit before criticizing. Pilot workload in the cockpit is amazing on regular planes under certain circumstances when it seems like the environment desires nothing more than the total destruction of your plane and your personal death. Pilot workload in a fighter aircraft is ramped up a bit because it involves much of what the regular plane does, with the added tasks of flying non-standard courses and attitudes, while being responsible for death-dealing weapons, while sometimes being in situations where people are trying to kill you in addition to the environment. Many people can't even talk on a cell phone without it altering their ability to maintain situational awareness in a car with just a 2D control set.
Its not so much ignoring a message as needing as many message channels available as possible (audio provides an additional channel with visual and tactile being used as well) with priority messages getting the most effective channel - the "Kitchen Voice" (apologies to National Lampoon's Doon).
Imagine this scenario in a restaurant:
Your steak is burned on one side, but cold. There's a big pile of a yellow granular unidentified substance piled on top of it. Your waiter comes along and says, "Cook's oven not functioning correctly and unknown substance spilled on top." OK?
In short, most error messages are crap. The blame lies with LAZY system designers and LAZY developers.
I can't tell you how many times, I see error messages like "Default zone not selected.: OK?" or "Type error on search processing object 23: OK?" Every time I see this crap, I want to bitch slap some lazy son of a bitch and ban all dialogs that only have the "OK" button as a response.
The CORRECT response to the first example above is something like. "Sorry, you need to select a default zone first. Shall I bring up the dialog that allows you do to this?: "Yes", "No", "Cancel"
The CORRECT response to the second example above is to fire the lazy system designer and/or programmer who couldn't be bothered to come up with an intelligent useful response to an error and because of their laziness, wasted thousands of hours of user time, just so they could take an early lunch.
Please do not read this sig. Thank you.
I trained all of my users to do screenshots when possible, because if they don't, the machine gets re-imaged. It's kind of like a shock collar for a dog.
Is it plugged in? yes? LIER!
It it turned on? yes? LIER!
Can you see any messeges on the screen? no? LIER!
Why do they lie!??!?
They aren't lying. They literally do not see it.
Your mind is pelted with information every day. Vast, huge, massive swaths of information that make what goes over an OC3 pipe pale in comparison. Your eyes generate a super-hi-Def video stream chock full of useful details about your life and everything around you. Your ears, your sense of smell, all are being monitored 24x7, and don't forget your senses of touch, hunger, and numerous other "metasenses".
There's far more information streaming into your brain than could possibly be processed. So what your mind does is exactly the same thing that your spam filter does at your local ISP: Your mind filters out information that you don't find useful before you are even consciously aware of it!
Studies have shown:
1) People will change lanes into a lane occupied by a motorcycle, even after clearly looking directly at the motorcycle! It's commonplace, as a motorcycle rider myself, I've seen this happen more than once! The reason is that the person isn't looking over to see if there's *anything* there, they're looking to see if a *car* is there. Since my motorcycle isn't a car, the other driver's mind actually filters that fact out before they are consciously aware of it, and to their mind, I'm simply not there. (thanks, brain!)
2) In simulation, highly skilled, trained pilots were instructed to land the "airplane" on a runway littered with stuff. Garbage trucks, buses, big, huge things that were hard to miss. In only a very small number of cases did the otherwise highly skilled, demonstrated, and experienced pilots ever see the junk on the runway, even though they could be seen to be LOOKING DIRECTLY AT THE RUNWAY. Why? Because their minds were only looking for information that was already known to be useful, and filtering out the rest.
3) Think back to when you learned to drive! Everything was bewildering, you were overwhelmed by details too numerous to process easily. Signs and lines seemed to jump out of nowhere. But somehow, it became easier and easier as your mind learned what information was actually needed, and began filtering out the rest. Your mind is trained to look for the red octagonal stop sign, and the street sign that, within your state, looks very consistent. But think about when you experience something new. For example, in my area, they started installing roundabouts where we never had them before. They were a bit disconcerting and bewildering the first few times, and I am a very safe, effective driver. (20 years, no accidents, knock on wood!) My lower brain hadn't learned to filter out all the details of the roundabout, so I had to slow down and process EVERYTHING until I had a chance to train it.
They aren't lying. They literally cannot see what's clearly and demonstrably in front of them. The lower parts of your brain filter out detail and deliver highly processed, compressed information to your cerebrum (the part that's self-conscious) in order to save expensive processing time. Be gentle, be understanding, and accept that the reason why they are calling you is because they need you to see what's wrong and fix it! Accept your pay scale accordingly, and suck it up, because that's human nature, it will always be human nature, and there's not a damned thing you or anybody else can do about it!
However, one thing I've found is that if an error or confirmation is very important, you put red lettering and make somebody type a word, such as "I will pay you $50", or "I'm ready to pay you $200 if I want to delete this" or something before proceeding. Make sure it's different for each situation! I used to just make end users type "confirm" or "accept" but they got used to that.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
If the error popups were not so frequent and identical, people might actually care when one shows up. This of course means having stuff that breaks less...
They're calling you because they want you to come fix it, personally. They don't want to do anything on their own, even if it's as simple as following verbal instructions over the phone. Users don't want to read an error to you. They either want to continue what they were working on before they were stopped unexpectedly, or continue researching kitten videos on Youtube.
Sounds like a variant of the dancing pigs problem
They will completely ignore every error message and try to find a way to get what they want.
I try to keep the error messages as simple as possible, and then have the system email out an error message.
If your company isn't gigantic it can work well, then when you get a call just check the email to see what the full message was.