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?"
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.
Waste of time. (Score:5, Insightful)
Java errors vomitted out in a dialog box.... (Score:2, Insightful)
...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.
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
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: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.
Not the users fault. (Score:5, Insightful)
Re:Do away with them (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's all about.
For me, depending on how well I'd know the users, the error messages changed. Things I used to write for departments I was in at the time, or people I knew used to have messages for something going really awry (there was no way this was meant to happen) reading "User error: Please replace user and try again.".
When I was writing bespoke software for clients of mine, I'd be descriptive, and state gently in layman's terms approximately what was going on, why it was likely to have happened, and whether or not I needed to know about it. Errors could be on input sanitizing through "Can't find the database or network" to "Everything has gone catastrophically wrong. Call me now" type of errors.
I always found that the general "This is a note you did something wrong" is best handled in page by little icons.
Something that you really want to wake someone up to, as a larger issue is in play (can't find the network or some such) warrants a dialog box, with an curvy icon and yellow background, with explanatory messages put simply on it; no 5 page essays, just a simple overview and a link to a 'help page' to help them solve it if possible (even if that is just an explanation followed by 'phone the service desk' at your site).
The big problems deserve a spiky looking icon with a red background. Again a simple explanation that says "This is really bad, call someone please"; definitely worth of a message that leaves them understanding that "This Is Bad".
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.
Make them retype it (Score:2, Insightful)
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.
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.
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.
Re:Do away with them (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:Fixed Penalty (Score:2, Insightful)
Yet an other IT department that regards its users as nuisances. I'm sure the feeling is reciprocated.
Re:Do away with them (Score:1, Insightful)
I see you've never dealt with software that interacted with other software, or networks, or external services, or external drives that might be disconnected...
Re:Make it turn the volume up (Score:5, Insightful)
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.
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".
You don't. You prevent the situation. (Score:1, Insightful)
You don't. You take a closer look at the function provided to the user, and make very very sure to remove confusion, to accomodate the user's mental modal and workflow, and remove all spurious complexity that tunnel-visioned software engineers extravagantly tend to spray on.
Re:Automation (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.
Outsource much? (Score:1, Insightful)
So, let me get this straight. You have some buggy apps, probably with meaningless error messages that have no correlation to any corrective action that can be taken. The official solution is to halt work immediately, call the help desk, and ... wait? As an added bonus, you disable Task Manager, so they can't just kill the process and re-launch. So they get tired of waiting for the helpdesk and reboot instead. Best of all, they get a coffee break, effectively mandated by the IT department. The Bangalore Bargain Bin is looking better by the minute.
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.
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:Firefox plugin install method (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:Do away with them (Score:2, Insightful)
Yes, seriously. At least as far as possible anyway.
It is all about the design. Your problem is making a user interface that allows users to do really dumb things. You want a number from 1 to 10?
1. Level one is a free text entry field with no checking. The user types in -15 and **boom** - the program bails out.
2. Level two is a free text entry field with input validation. The user types in XYZZY and **boom** - up comes an error dialog. Almost as annoying as 1.
3. Level three is a text entry field that allows only digits 1 to 10, and a maximum of two characters. The user types 99 and **boom** - up comes an error dialog. Still quite annoying.
4. Level four is a spin box. The user can't enter a number directly but presses buttons to ratchet up and down between 1 and 10. It is now quite impossible to enter an illegal value. But pressing a button ten times is a real drag. And you still get an error dialog if you select one of the values that has already been taken.
5. Level five realises that asking for a number between 1 and 10 was a really bad user interface design in the first place and goes back to ask the user what he really wanted to get done.
Interface Design on slashdot (Score:2, Insightful)
Re:Firefox plugin install method (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.
DO NOT STEAL FOCUS (Score:1, Insightful)
I type away frenetically on a mail when all of a sudden a window pops up, takes focus, gets the space bar and disappears.
Now what the #£$ did it say? I will never know.
Re:Electric Shock (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:Fixed Penalty (Score:1, Insightful)
...but after trying for literally YEARS to make users take responsibility for crashes...
Excuse me, but WHAT THE FUCK KIND OF ASSHOLES think that users should take responsibility for crashes??? Your software should not be crashing all over the place. You should devise some automated way to gather information about crashes without requiring the poor users of your piece of shit to do your job for you.
Re:Explaining error messges is what support is for (Score:2, Insightful)
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.
Re:I call it wack-a-mole (Score:3, Insightful)
Well, I don't know about you, but if MY printer was on fire, I'd want to know about it!
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.
Re:Nagging Nora (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:Save your sanity, give up now (Score:1, Insightful)
No kidding.
I'm an end user, not a programmer. When the stuff I work on breaks, I get called and someone gives a vague description of what they want me to think they were doing when things broke and a demand that things be fixed -- and that's often a lot more expensive and time consuming that recompiling. The error messages my equipment sends to the user: the machine stops, maybe makes a grinding noise or some other weird sound and hopefully shuts off before the smoke escapes. My equipment can't send me an email, can't keep a log file - except for metal shavings and other forensics. And some keyboard puncher whose equipment can send them an email, can keep a log file, wants me to keep track of their error messages for their project for them so they can troubleshoot it better? WTF?
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: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: 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.
Stop fighting a losing battle... (Score:2, Insightful)
You don't. (Score:2, Insightful)
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.
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: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 done, I might even understand women...
Re:Electric Shock (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?
Them (irate): Yes, there is nothing that says "about"!
Me: OK, I must have had you go to the wrong place. Let's make sure I do know where you are. Could you please read out loud the words in the top of the window that you are looking at right now?
Them (reading out loud): "About this application"... Oh, is that what you meant?
Me: Yes, I'm sorry I wasn't clear. Now could you please read out loud the number that is written just below the words that you read to me?
Re:Electric Shock (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?
TL;DR (Score:2, Insightful)
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.
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: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.
Re:Electric Shock (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: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: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:2, Insightful)
"The Pie Is A Perjury" will henceforward be the next Internet meme to be bandied about by every would-be BOFH with nothing better to do that spend hours on Slashdot waiting for an opportunity to get his karma back up with a +5 Funny.
Good day.
Re:Electric Shock (Score:3, Insightful)
I completely agree, one of the problems here is not being in the mindset of the user. What does "uninitialized data" really mean to a user? Even to me as a programmer it lacks specificity - I want to know what isn't initialized so I can fix it. As for non-programmers, uninitialized data means exactly what to them? To my wife that means "blah blah blah" what do I click to make this work? I remember my own struggles with programmer specific errors like "Syntax Error" and "Bus Error" - these terms mean nothing unless you've had computer training (and often not until you've hit them and put significant work into fixing the problem, either with print statements or learning a debugger).
MS had this problem in Word once upon a time, using the obscure "Revert Document." I had a student crying because she lost 6 hours of work on her thesis due to that one and a couple of others that lost 45 minutes to an hour of work. In my opinion, that number should have been zero and that should have been caught in QA testing, if not earlier.
Re:Fixed Penalty (Score:2, Insightful)
May I introduce you to this revolutionary technique called a log file?
Re:Dr. Zen's answer (Score:3, Insightful)
Very true.
Programmers have an ethical duty to safeguard users' work. Where we can't, we must give useful guidance (not just in verbiage, but in UI design altogether). If we do our best and users ignore that, it's not our fault.
Re:Electric Shock (Score:5, Insightful)
Re:Electric Shock (Score:4, Insightful)
Re:Electric Shock (Score:5, Insightful)
The karma from funny is a lie.
Less Error Messages (Score:2, Insightful)
Re:Electric Shock (Score:3, Insightful)
They don't want to read (Score:2, Insightful)
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.
Re:Electric Shock (Score:1, Insightful)
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!??!?
Liar is spelled LIAR.
They're not lying. they have a blind spot, like your spelling.
Yes it is jargon (Score:1, Insightful)
jargon (n) ... 3. The specialized or technical language of a trade, profession, or similar group.
The uses of jargon are:
a. to communicate information efficiently, and/or
b. To confuse those outside the group.
Don't be ashamed of using jargon when appropriate for communicating with others on your level, but do remember that not everyone belongs to your select group.
Dancing Pigs / Bunnies (Score:2, Insightful)
Sounds like a variant of the dancing pigs problem [wikipedia.org]
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.
Re:Electric Shock (Score:3, Insightful)
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.
This may sound strange, but I completely understand the user's behavior.
How many monitors have you seen that bounce a message box around saying "No video signal" instead of just going to sleep? I can understand displaying that for 10 seconds, but I've come back hours later to find this message still on the screen. Users ignore these types of messages. They probably saw a bouncing grey box, and their brain completely filtered it out. This is the same brain circuitry that helps people to ignore ads, or the sound of the person sitting behind them sniffling, or the fuzziness in their TV signal. The human brain is a freakin' awesome pattern recognition and filtering tool.
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:Save your sanity, give up now (Score:2, Insightful)
Sure you do. The error messages are the strange grinding noises or obvious physical defects which you report to the professional technician to get it fixed. We're talking about cases like where the hammer breaks in half and the conversation goes like this:
Or this situation:
Re:Electric Shock (Score:3, Insightful)
You'd think that a company that had people who "work with and create quit sophisticated software systems" wouldn't be using a fax machine to send timesheets to payroll.. Shouldn't it all be done electronically?