How Do You Get Users To Read Error Messages? 951
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?"
Electric Shock (Score:5, Funny)
Re:Electric Shock (Score:5, Funny)
Electric Shock v2.0 (Score:4, Funny)
Re:Electric Shock (Score:5, Funny)
Boring story:
The most memorable example for me was when I was working part time as a tote at a race track during college.
There was some significant "technical problem" which was delaying the races.
I was up in the cash room and the manger was on the phone to the control room asking what was wrong.
She asked me to carry down a TV so I grab one of the dusty old little ones and carry it down thinking one of the displays must have burned out or something.
I got down to the room and the woman who was in the control room was on the phone to some tech support drone wherever the company outsourced these things to.
Turned out she'd told my manager there was something wrong with the "monitor" which had somehow translated to "TV".
I look at the screen and bouncing slowly around over everything there's a big grey box.
It covers half the screen and the only way it could make more of a point that it's there is if it was flashing in many colours.
"Current monitor resolution not supported 1200*1600"
At first I assumed she'd read this to the tech on the other end and there's something deeper wrong so I don't do anything I just hang around and listen for a few moments and it becomes very clear that she has not read this error to the tech, it's as if she has a massive blind spot where the error is.
This isn't a little error like you get in windows whenever it wants to tell you about something and which users get used to clicking right through... no this is a fairly unusual big grey box being generated by the monitor itself.
I can hear the tech asking if she can see any errors or messeges, and she says "no" ....(WHAT THE FUCK?)
All the while the clock is ticking and costing the track quite a lot of money per minute.
I tactfully hint that perhaps I being a computer nerd and a third year comp sci student who's worked tech support in the past might be able to help but she's one of those territorial types and won't allow me to talk to the tech so that I can at least read the error to him.
(You know all know someone like her:she may not have a clue how to do her job, she may not have any idea at all what she's doing but it's within HER domain)
So while she's being talked through how to let him remote in(useless in that situation I know) I lean in, change the resolution to 800*640 .
The monitor goes blank for a moment and she assumes I've broken everything.
Then it blinks back and is working again (now though some of her icons are off the edge of the screen and she starts panicing again until I arrange the icons so they're all on the screen.
Now whenever I'm at an event and hear an announcement about "technical problems" I assume that it's really some trivial crap like that.
And if I ever work phone support again I will assume everything, absolutely everything the person on the other end tells me is a blatant lie.
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!??!?
Re:Electric Shock (Score:5, Interesting)
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.
Re: (Score:3, Interesting)
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.
Comment removed (Score:5, Informative)
Re:Electric Shock (Score:4, Insightful)
Re:Electric Shock (Score:5, Funny)
I once had a user call because he "couldn't get into his e-mail." After about half an hour of being stonewalled on the phone, it turns out that:
1. He couldn't load his e-mail because he couldn't run his e-mail application.
2. He couldn't run his e-mail application because he couldn't run windows.
3. He couldn't run windows because his computer wouldn't turn on.
4. His computer wouldn't turn on because he had yanked out the previous motherboard, stuck in a new one (without a CPU, of course), and just assumed everything would work.
5. Seeing as how this was painfully stupid, he didn't actually tell the tech support this for fear that the tech support would figure out what he had done wrong.
6. And, instead of calling the hardware manufacturer's help line, he called his ISP.
My second favorite tech support call was a user who was having trouble getting online, and no matter how many settings we changed nothing seemed to fix it. "Hardware problem" you suggest? Yup. Over the weekend someone had bulldozed the wall with her network jack.
No matter how bad things might get at my current job, at least I'm not doing tech support.
Re: (Score:3, Insightful)
And if I ever work phone support again I will assume everything, absolutely everything the person on the other end tells me is a blatant lie.
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!??!?
First off, spelling: LIAR, not LIER. Second, never ask yes-or-no questions over the phone. Always ask the user questions that force them to use their own words to describe things. I have gotten very good results by asking them to read things out loud. It seems to break through that blind spot that they have. More than once I have had a conversation go something like this:
Me: What version number does it show in the "About" section of the window?
Them: There isn't any "about" section.
Me: Are you sure
Re: (Score:3, Interesting)
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.
T
Brain == Spam Filter, with false positives. (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
This is not an issue of hating users.
This is an issue of people simply not, , reading the error in from of them to the tech support.
Even if the user does not understand the error, the should be able to read it to the tech. They aren't being asked to fix it themselves.
I like the idea of the puppy error and such.
People remember stupid things, they'll remember the puppy error or the baby error, or the Homer error.
Sean D
Re: (Score:3, Insightful)
Maybe we do need stuff like clippy or that puppy dog Windows has now as its "helping toon". Imagine a puppy with an error message in its mouth, looking at you from biiiiiig puppy eyes, think that might make users read the message, if only so they don't disappoint the cute puppy?
Re:Electric Shock (Score:5, Interesting)
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.
Re:Electric Shock (Score:5, Funny)
Re:Electric Shock (Score:5, Insightful)
Oh lighten up you twat, this is one of the few instances that joke actually works.
Re:Electric Shock (Score:5, Insightful)
The karma from funny is a lie.
Re: (Score:3, Interesting)
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 wit
Re:Electric Shock (Score:5, Insightful)
One of my peeves is users complaining about "jargon". Error messages are not jargon, proper names for peripherals are not jargon. If I ask you if your ethernet cable is plugged into your network card, that is not jargon. And yet users will tell me "why do you guys always use fancy jargon that I don't understand?".
Re:Electric Shock (Score:4, Insightful)
NOUN
1. specialist language: language that is used by a group, profession, or culture, especially when the words and phrases are not understood or used by other people "typesetters' jargon"
2. unintelligible language: pretentious or meaningless language ( disapproving ) "Cut the jargon and get to your point."
____________________________________
Your definition and the dictionary's definition of Jargon do not agree. A network cable is just a cable of some sort to most end users. They don't recongnize it for its function, just that it plugs into thier comuter the same as the monitor cable, the power cable, etc. It's up to you to define the cable for them using terms they will understand. That is part of your role as a support person. Not bothering with this aspect of your job makes you bad at your job.
Re:Electric Shock (Score:5, Insightful)
I like a challenge...
define the cable for them using terms they will understand. That is part of your role as a support person.
Okay, so using nothing but text, please describe the concise difference between:
- An ethernet port
On the back/side of your computer you will see two holes that look like spots to plug in a phone cord. There'll be a little one and a big one. The big one is called an "ethernet" or "network" port, or if you want the fancy term, an RJ-45 connector, but we wont' be using that term again anywhere in this call...
- An ethernet cable
You'll find a cord or wire - it's pretty thick and has a big plug on each end. The plugs look like phone plugs, but larger. This is your "ethernet" or "network" cable.
- A telephone/fax port
actually this one you really don't have to go out of your way to describe as most people have experience with this one. So look for the spot that looks like a good place to plug in a phone cord.
- A telephone/fax cable
This is another one where people have a frame of reference so it doesn't take a description really. Look for the phone cable.
- A USB port
Hi - we need to find your USB port on your computer. It will look like a flat rectangle and there may be a bunch on the front and back of the computer. It's usually the place you plug your iPod in when you connect it to your computer.
- A USB cable
USB cables ... look for the wire that has a flat rectangle on one end, it may have all sorts of different sized things on the other end and we're not going to worry about that now. On the flat end, there should be an arrow and a couple of other funny looking symbols. There ya go - you have the right cable.
And is there anything else I can help you with, today? Your old telephone tech support people (not seen very often nowadays) are used to walking complete newbies or people who are scared they're going to break things through plugging things in, turning it on and then editing configuration files, usually while not at a computer themselves.
Re: (Score:3, Insightful)
You have to get into the mindset of the user. "Is there something on the screen?" translates into "Does the screen display what you want it to display?". I don't know why, but it does. Or they expect something akin to movies where error messages flash in neon colors with a big ERROR or WARNING in the middle of the screen, so a simple dos prompt is certainly "nothing" in comparison.
I have no idea how the mind of a clueless user works. Or if it does at all. But I still try to understand them. And when I'm don
Re: (Score:3, Insightful)
Or they expect something akin to movies where error messages flash in neon colors with a big ERROR or WARNING in the middle of the screen
i WISH the damn things would do that. BLink as well in ALL red and play a air raid siren wav at full volume.
ony then would it get the attention of many of the zombies here at the office.
Re: (Score:3, Insightful)
That would just make them try to get rid of it even sooner and preclude all possibilities of reading it.
Re:Electric Shock (Score:5, Insightful)
My favorite, from the old days, was when I was trying to talk a reluctant secretary through some minor DOS voodoo. I asked if anything was on the screen. She said no. I asked, "do you mean to say that it is completely black, with no letters anywhere?" Well, no, of course not - it just said C:\DOS>
While we all like to laugh at stupid user tricks, the real problem is a lack of communication. In your example, you wanted to know what was on the screen and it seemed reasonable to ask if anything was on the screen; to the secretary, her answer was correct because , for here, something on the screen means "I have something I have opened" on the screen.
One thing I have learned is don't think the other person understood what you said - their frame of reference may be different and you need to consider that when communicating.
Re:Electric Shock (Score:5, Insightful)
Re:Electric Shock (Score:4, Funny)
WE use angry midgets that punch them in the groin if they dont read the error message. One assigned to each workstation.
works great, problem is the pay rate we have to give the midgets is 2X that of the positions that they are working at, except for management, we can get midgets to punch managers and executives in the groin for nearly free, problem is they have a high rate of false positives and un-necessary groin punches. Some have also escalated in severity, the marketing manager started wearing an aluminum groin protector, the midget assigned to him started bring in golf clubs and baseball bats...
Make it turn the volume up (Score:5, Funny)
Re:Make it turn the volume up (Score:4, Interesting)
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.
Re:Make it turn the volume up (Score:5, Insightful)
Re:Make it turn the volume up (Score:4, Interesting)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Informative)
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-deali
Automation (Score:5, Funny)
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. ;)
Re:Automation (Score:5, Insightful)
I know users whose definition of unexpected is that they have to copy text from a program they've never used before. You couldn't handle that with a script, but how these people have a job not requiring a broom is an eternal mystery.
I don't think UI designers should try to pander to them either, because it will make programs unbearable for everyone else.
Re:Automation (Score:5, Funny)
Re: (Score:3, Insightful)
We could be their pets. We'd get to eat and sleep most of the day. Get a new toy every now and then. Walked daily, when we can bark at the other humans. Plus we could lick our own balls whenever we want.
Sounds awesome.
Re: (Score:3, Interesting)
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
Re:Automation (Score:4, Funny)
Firefox plugin install method (Score:4, Insightful)
Just put a timer on the buttons that won't let them click it for 10 seconds... but ultimately you can't fix stupid.
Re: (Score:3, Insightful)
Just put a timer on the buttons that won't let them click it for 10 seconds... but ultimately you can't fix stupid.
And employees will love you because now they have mandatory coffee break. Seriously, they won't read it, they'll do something else until they can just click the button.
Re: (Score:3, Insightful)
10 seconds is not enough to grab a coffee, but locking my pc for 10 seconds sure motivates me to get one.
or Validation Code. (Score:5, Interesting)
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".
You don't "fix" stupid, you fire it. (Score:3, Insightful)
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.
Re:You don't "fix" stupid, you fire it. (Score:5, Insightful)
You absolutely can.
Sorry, no.
It's very easy: discipline people and if they keep doing it, fire them.
That doesn't fix the stupid, it just moves it somewhere else. And how, exactly, does this work when the stupid is in management?
It'll probably only take one person before everyone else starts paying more attention.
Bullshit. The stupid people will continue to be stupid, and blame you for not making their problems go away.
careful (Score:3, Funny)
Waste of time. (Score:5, Insightful)
Re:Waste of time. (Score:4, Interesting)
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.
Re:Waste of time. (Score:4, Interesting)
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.
Re:Waste of time. (Score:5, Informative)
Re: (Score:3, Informative)
Well, Ctrl+A, Ctrl+C, notepad, Ctrl+V
You can also hit PrtSc if they can't figure out how to hit Ctrl and the letter A at the same time. Then open Outlook, Paste it in, and mail it off.
[John]
Pop up the error message in a box... (Score:5, Interesting)
...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.
Re:Pop up the error message in a box... (Score:4, Interesting)
Re: (Score:3, Informative)
CAPTCHA!!!
My users already hate the CAPTCHA text they have to enter to reset their forum password. CAPTCHA on an error message would bring out the torches and pitchforks.
Several Firefox dialogs have a countdown timer, so the message has to stay visible for a certain amount of time before you can clear it. That seems a bit less intrusive. And there is always Windows XP's system-modal shutdown prompt, where the rest of the screen slowly goes monochrome if you wait long enough.
Re: (Score:3, Funny)
Make others remember (Score:5, Funny)
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.
I call it wack-a-mole (Score:5, Interesting)
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. ;-)
Re: (Score:3, Insightful)
Well, I don't know about you, but if MY printer was on fire, I'd want to know about it!
Do away with them (Score:4, Interesting)
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.
Re: (Score:3, Insightful)
Lovely, if you have the time and money to follow formal methods, but usually that's overkill. Which is why most programming languages have error trapping, which allows you to detect errors and handle them gracefully.
There are many unknowns that can happen. Hardware failures, memory corruption, OS doing something it shouldn't, the malware on the system is interfering, the vendor changed the API behind the scenes and so on.. You always, always trap for errors, even if you don't expect them. That's what it
Re: (Score:3, Insightful)
There should be no errors. Period. Your program should not allow errors.
I agree: errors should not be allowed. That's why, when the user does something dumb, instead of allowing an error to occur, you should display a message on the screen alerting the user to the problem and informing them of how to fix it, so that an error doesn't occur.
Come on, seriously?
Re:Do away with them (Score:5, Insightful)
There should be no errors. Period. Your program should not allow errors.
So what is a program supposed to do when the hardware it talks to fails or is not plugged in? Or when the network resource it requires is not available? Shuffle its feet and hem and haw and hope the user won't notice?
Anyone who says "there should be no errors" doesn't know how the word "error" is used in computing. That there should be no BUGS may be a formally realizable goal (at least that's what my functional programmer friends tell me) but let me ask you: when was the last time you drove a car that had no error notifications on the dashboard? No idiot lights, no oil pressure gauge, no fuel gauge, nothing but a speedometer?
Never, right? That's because all machines have a physical component whose state is sometimes unable to fulfill user requirements, and we need to communicate that state to users. We call those communications "error messages" in the software world, and they cover everything from "out of memory" to "printer on fire."
On another note, I like the ball-kicking idea, but my users are mostly female, so it won't work. Recently I've had a bunch of complaints about missing hardware because they are clicking through the dialog that detects that hardware is missing, and then complaining when the main UI comes up and tells them there is no hardware connected. They never remember they've clicked through because they are so used to simply clicking OK on any dialog that comes up, a phenomenon that has gotten much worse in the past few years.
re: Great point, but .... (Score:5, Insightful)
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.
Fixed Penalty (Score:4, Interesting)
Re:Fixed Penalty (Score:5, Insightful)
I am not really sure what you accomplish by disabling the software for 15 minutes. It sounds to me that if the person ignores your error message they get a 15 minute break.
One thing IT people often forget is that their job is to make the other employee's jobs easier and more productive. This means solving problems without getting in the way of the work that actually makes the company money.
The classic way (Score:4, Funny)
Available information content... (Score:5, Insightful)
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...
Similar setup as me. (Score:5, Insightful)
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
Re:Similar setup as me. (Score:5, Funny)
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.
This explains some driving I see on the roads...
Re: (Score:3, Interesting)
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.
Go with what's known to work (Score:3, Funny)
Tell them that reading the message will enlarge their penis... which isn't too hard to achieve anyway.
This is a sore subject with me because it's true.. (Score:5, Interesting)
Re: (Score:3, Interesting)
FTFY (Score:5, Funny)
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?
Re: (Score:3, Funny)
So *you're* responsible for Windows ME.
If clicking the OK box makes the error go away... (Score:5, Insightful)
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.
Save your sanity, give up now (Score:5, Insightful)
Re: (Score:3, Interesting)
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.
Not the users fault. (Score:5, Insightful)
A good plot (Score:5, Funny)
They have no vested interest in the outcome. (Score:5, Insightful)
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.
Guru Meditation (Score:5, Insightful)
Amiga had this right. Use a little humor with your messages, it may diffuse the anger and get some sympathy.
Their lips get tired (Score:5, Funny)
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."
Make error messages that are useful (Score:4, Insightful)
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.
Distill them (Score:5, Interesting)
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.
Your solution : (Score:3, Funny)
Funny error messages. really funny. not 'microsoft' funny.
Explaining error messges is what support is for. (Score:5, Funny)
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."
Don't tell what went wrong (Score:5, Insightful)
"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".
The BOFH's one-word answer (Score:3, Funny)
Use Humor (Score:5, Interesting)
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.
not gonna happen (Score:4, Insightful)
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.
Dr. Zen's answer (Score:4, Interesting)
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.
Icon selection (Score:3, Interesting)
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.
Full Screen Stop (Score:3, Insightful)
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.
Oh, I dunno, try making the error messages useful? (Score:4, Interesting)
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.
Re: (Score:3, Funny)
Data is pants.
Re:Make the error memorable (Score:5, Insightful)
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.
Re:Full screen (Score:5, Funny)
Don't forget to use brilliant colors that are harsh on the eyes!
Yes, let's make it blue just to make it stand out more.
And to ice the cake, maybe we should have it so the only way to get rid of the message is a reboot.
I think I may be on to something here.
Re: (Score:3, Funny)
Why not just display a skull and crossbones image? It'd probably save some time.
Indeed, that'll save lots of time:
User: Help, I get an error message
Support person: What does it say?
User: I dunno. It's just a piraty thingy. Skull & crossbones...
Support person: Well, if you get that, fix the problem
User: But how should I fix it?
Support person: I dunno. Maybe put on an eye-patch, take your sword, and wave it around to scare the problem away. Have a nice day.