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?"
...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.
As said, users learn what to do to get past the error, without remembering the actual error. Make what they have to do depend on the error, for example, make them type the error number. Or better, make them write error number down, and then type it middle digit, next right, second left, third right, etc.
Newall
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 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.
Yep. Lots of software packages now have automatic crash reporters. An on-demand error reporter should be even simpler to implement. If they got an actual error message from your program, there's no reason it shouldn't be written to the log as well.
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.
The "one-click send me the info option" is definitely the best solution.
What is annoying is that in many Windows programs (at least Office 97) you can't even copy and paste the error message text. Your only option is to do a screen capture of the window.
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.
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
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!
and let out a big screech followed by the sound of glass breaking and it saying "Danger Will Robinson! Danger!"
You may be kidding, but back around 1990 or so, when MS-DOS was still the mainstream operating system (at least in Mexico), my father (a computer enthusiast himself, Prof. in Biology) used to battle with his students when using some program (Microstat, Statistica, QPro or the like) because students did not read the messages.
When something that they did not expect happened (say, a message telling them that they should append an = sign to process the equation), they would just block. He was also bothered that students did not read the programs instructions (RTFM!).
Partly kidding, my father told me I should do a program that dictates the instructions or messages aloud. Now, back at the time I thought it was a good idea, unfortunately I was only 9 years old and was doing my first C / Assembler /hex-edit tests.
Nowadays, I think it would be a good idea that each time a "modal" message box is presented in a focused window, all the screen is opaqued (as with Windows UAC) and whatever is in the messagebox is read to the user.
Another option would be to make them write the exact text that is presented in the error, as a sort of Captcha.
Ubuntu is an African word meaning 'I can't configure Debian'
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.
Then the job should be done by an AI, and you should train for a job that can't be so economically automated. It's not like this issue hasn't come up before with the advent of robotic assembly lines and, well, any kind of automation technology ever.
We're not just talking about general ignorance/stupidity here; we're talking about someone's ability to do their job. If they lack that ability then they should be trained further or replaced. It's that simple.
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.
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.
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".
When I was doing support for a regional ISP, one of my coworkers figured out an ingenious way of forcing a customer to check whether or not a piece of equipment was plugged in. You can't just ask someone, "Can you check to make sure X is plugged in," because they'll say they checked already out of pique. Instead, he would tell them to unplug the power cord and plug in back in again, upside down, and would make up some hooey about how the power cords on these routers were flaky. Of course, the equipment in question always had a three-prong plug, but every once in a while the client would say, "Thanks, that worked!" and we'd know that he was covering to hide the fact that it hadn't been plugged in at all.
There is a similar approach I once heard: Use 4 well-defined icons to encode any 32-bit value. You would only need 256 distinct icons to have a complete coverage. Remembering 4 icons like that is fairly easy. Plus if your application only uses 256 or 65K errors, you can reduce the number of icons to 1-2.
Honestly? No.
I don't have to think about error messages, or even actual problems with the tool, when I use a hammer, or a car, or a washing machine. If it's broken, I call a pro and have it fixed, period. (Or, in case of the hammer, I finally give in and buy a good tool, not the $0.99 one from Home Depot ;)
Same goes for software. That's what IT is for, taking care of software. Yes, I could do it myself - but that is not what I am paid for, that's what they are paid for.
I disagree with your comments about the puppy picture. It is not an apology at all, it is a VERY effective means of communicating with your users.
I *do* use this method. I have pictures of cake, a cartoon alien, a dumpster, etc. throughout my systems with different pictures having very specific meanings (to me).
Every error gets emailed to the developers, and also logged, so there is a lot of 'professional' stuff going on behind the scenes.
But here is a scenario I've been in before...you are sitting in a meeting, and the conversation turns to your newest creation, when one of the people says, "I was using the system this morning, and I got an error." Which could be a show-stopper as far as an positive discussion is concerned.
But then they add, "It was a piece of chocolate cake." To which I respond, "Okay, thanks for letting me know about that- I'll get it fixed ASAP."
The conversation moves forward, because confidence was restored in the system. The user did not have to talk about, "I don't know what it said- some computer gobbley-gook," which I would respond with "I will look into it."
With the cake picture, the user tells me everything I need to know, in a very simple and easy to understand way.
No reason to lie.
I lied because I was tired of the DSL tech trying to get me to configure my SpeedStream 5100A as if it was a 5100B (the latter does routing and gives it an IP address with a web UI, the former is a dumb modem, so it's a big difference) and I just wanted some darned login credentials. Since you ask.
But that's just me.
The World Wide Web is dying. Soon, we shall have only the Internet.
Why do they lie!??!?
As a tech support agent, this is a question I ask myself every day.
If a customer says, "My internet is broken," the very first thing I ask is "what error message do you see?" 9/10 times I can fix the issue based on the error message alone, without knowing anything else. But, if instead they throw some random words at me like "it says it doesn't work," then I ask them to reproduce the error. If they can't do that then it's time to shotgun troubleshoot, and I know it's going to be a long, painful phone call.
The people who act like reading error messages is unnecessary, bothersome, or uninformative are the same ones who for some reason lie about everything. "Reboot your computer please," (one second later...) "Ok it's rebooted." Sigh.
I wish error messages on computers were more like tv set top box errors. They stay on the screen, saying blandly, "Error 14" (for example) and so customers do tend to let us know what the error number is, because there's no way around that screen. I get the error message, look it up, and a few minutes later the issue is resolved. I say take the information about what's actually going on out of the hands of the user, since they don't care anyway, they just want it fixed. Any informed user who wants to know what "Error 14" is just needs to (gasp!) look it up on our website, and then they can fix it on their own if they so choose.
My comments here are my own; I do not speak for my employer.
This is one of the first things I noticed about Linux, too.
On Windows, you either get some bullshit that doesn't mean anything ("Limited or no network connectivity", "Windows has encountered an error") or a hex dump. The first doesn't give any information, and the last doesn't give any useful information.
On Linux, when something breaks, it fucking tells you what broke. Sometimes what broke is fairly technical, and I may not understand what exactly the message means ("wtf is /dev/wumpus?"), but if it's a complicated technical issue I'm going to have to google to figure it out anyway.
Right now, my not-very-technically-sophisticated mother has an issue I'm trying to fix from 1500 miles away over the phone: "Windows can not boot due to a hard drive configuration error." WTF does that mean? Clearly it can read the boot sector.
Dear uninformed...
1 - No balls on women, ask a woman if they find that a punch or kick to the groin area is painless. Guess what it hurts like hell to them there too. DUH, please get a basic education, then come back and refine your response.
Also hating your users when they LIED on their resume that they are "experienced in using office computers and software" gives you 100% justification. It's simply an example that management and HR are incompetent in screening new hires.
Sorry, but becoming confused with the windows login screen means that user needs to be fired right there and escorted from the building. They will be nothing but a liability to the IT department from that moment on. Dont get me started about the endless fight with saving your damned files on your H: drive directly or into your "my documents" so they go there anyways instead of random locations all over the hard drive.
Do not look at laser with remaining good eye.
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.
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.
Well, the all red stuff would suit me just fine. I can't see it. Back in the days of Dos, I fiddled around with the screen colors, and found a combination that looked kinda cool, then made it flash. The wife took one look at the screen and told me that there are epileptics in the family who would fall over if they saw that.
Bearing in mind that it would be myself who had care for those epileptics until they recovered, I stopped tinkering with color schemes . . . .
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I have an idea... we should put a timer on the ok/continue button.. but not to prevent them from clicking it... no.. to know how fast they clicked it...Imagine..
Error message sayong something, user click ok.. other screen saying you can't have read that error message in 1.23546 seconds... that impossible... please read the error message carefully before continuing... then the ok button would bring back the last error.