Slashdot Mirror
How Do You Get Users To Read Error Messages?
A BOFH writes "The longer I do desktop support, the more it becomes obvious that my users don't read anything that appears on their screen. Instead, they memorize a series of buttons to press to get whatever result they want and if anything unexpected happens, they're completely lost. Error logs help a lot, but they have their limits. I've been toying with a few ideas, but I don't know if any of them will work and I was hoping my fellow Slashdotters could point me in the right direction. For example, I was thinking about creating icons or logos to identify specific errors. They might not remember that an error is about 'uninitialized data' but they might be more able to remember that they got the 'puppy error' if I showed a puppy picture next to the error message. Or for times when finding images is too time consuming, you could create simple logos from letters, numbers, symbols, colors, or shapes, so you could have the 'red 5' error or 'blue square' error (or any combination of those elements). I've even wondered if it would be possible to expand that to cover the other senses, for example, playing a unique sound with the error. Unfortunately, haptic and olfactory feedback aren't readily available. I like to think that my users would remember the error that caused them to get a swift kick in the balls. And if they forgot it anyhow, I could always help them reproduce it. Does anyone else have experience with ideas like these? Did it work?"
Using Bluetooth to activate a transmitter in the seats of our users, we've had a 671% increase in efficiency when helping our users due to increased "awareness" of error messages.
and let out a big screech followed by the sound of glass breaking and it saying "Danger Will Robinson! Danger!"
That which does not kill me only postpones the inevitable.
they memorize a series of buttons to press to get whatever result they want and if anything unexpected happens, they're completely lost.
Sounds like their jobs are easily automated. Tell them if they don't pay closer attention to error messages you'll inform their boss how to replace them with another computer program. ;)
Developers: We can use your help.
Just put a timer on the buttons that won't let them click it for 10 seconds... but ultimately you can't fix stupid.
I do like the ball-kicking error idea, but be careful which one you use. Windows can be testy and the last thing you need unprovoked genital damage when you are trying to fix a workstation.
Do yourself a favour and produce a one-click tool that collects all the info that you need (logfiles, version numbers, registry listings) and sends it to you. If you can make it 0-click, even better.
If you were blocking sigs, you wouldn't have to read this.
...with no "Dismiss" button. The message would stay on the screen until the user talks to you and you tell them how to get rid of it.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
As said, users learn what to do to get past the error, without remembering the actual error. Make what they have to do depend on the error, for example, make them type the error number. Or better, make them write error number down, and then type it middle digit, next right, second left, third right, etc.
Newall
...when it can't restore the tabs from the previous browser session.
"Well, this is embarrassing!" or something OMG-idiotic like that. Just give us our home page and shut up.
Lots and lots of popups! They're great as they get in the user's face and FORCE them to see what you want to see. So I recommend POPUPS!! Oh and confirmation messages when they try to close the popups that say something like "Did you read the previous error message?"
I remember EditPad's "Text encoding mismatch" error message, although it's a paragraph of obtuse text relating to something no normal user ever checks. Why? Because instead of saying "OK" at the bottom, the button said "Bummer."
Guarantee they'll learn quickly to avoid the goatsea error.
with super big text, and a timer to keep it on the screen for a certain amount of time. I don't think they'd miss that.
I've even wondered if it would be possible to expand that to cover the other senses, for example, playing a unique sound with the error
You're going about this the wrong way. You don't make the user remember, you make their colleagues remember. Supply your users with a 5.1 sound system attached to their PC and when the user encounters an error, the speakers blast "HEY EVERYBODY, I'M WATCHING PORNO OVER HERE".
As I said, make it a memorable experience.
8 of 13 people found this answer helpful. Did you?
I've often described the action of quickly clicking on ok on whatever window pops up as the wack-a-mole behavior. With Windows, I can't say I blame users for this behavior because the popups that come up are so frequent and so useless that they've kinda been trained to do this. Linux errors are usually more useful, descriptive and since the order of the buttons change from window to window, you have to be more careful. ;-)
There should be no errors. Period. Your program should not allow errors.
Now, if you're talking about a programming language or programming environment, that's different, but someone writing a program using your compiler/interpreter would be expected to read and understand the messages. But even there, some efforts are lax and feebel. I've gotten errors in MS Access that say error n: there is no message for this error". Boundary conditions for common "errors" are handled poorly; end of file, for example. If you make your own next/previous buttons to replace the puny little almost invisible Access buttons, there is no easy way to determming the beginning of the file, and Access returns an error in a big scary "stop" combo. This should be there in a debug mode, but a user shouldn't see it -- and Access' docs should be a lot more clear.
I'm not just talking about Microsoft, you're all bad about it. Well, not you -- your PHBs who want it shipped yesterday when the damned thing's barely out of alpha are bad about it.
With a graphics program or word processor, for an end user to see an error message is inexcusable. If your users are getting errors, your program is poorly designed.
Free Martian Whores!
We have found that the only way to make users take responsibility for errors is to give them a penalty for forcing the error to go away. For starters, where possible, the error wont actually close for them unless we enter an admin password to make it go away, and if they reboot to get rid of it (Task Manager is disabled on all client PC's) the machine will not open the application that crashed for 15 minutes. Of course, this all depends on the type of users you are dealing with, as more technically adept users wouldnt accept this kind of system, but after trying for literally YEARS to make users take responsibility for crashes and making sure the IT department is aware of them in order to fix the issue before it gets too hard to manage, these are the only steps that worked. Now, all of our end users are aware that if they ignore errors, they are going to suffer for it themselves.
...are the worst evil ever unleashed on support analysts. There's nothing more fun than your average dead-ender mindlessly reading eighteen Java bomb strings and ending with "so that's the problem." Why not just display a skull and crossbones image? It'd probably save some time.
Is it just my observation, or is eldavojohn an idiot?
Your expectations for users is to high. Better logging along with an option for the user to click and report the error they just encountered is about the best you could do. The single click should provide you all the information you need rather than expecting the users to fill in a form to complete the information. Of course this is provided that the errors fail gracefully. If this is web related it's best to not be displaying errors to users at all. Better logging is the way to go.
Show the message in full screen using a blue background and white foreground. Just like a BSOD.
The largest prime factor of my UID is 263267.
Users have already trouble copy-pasting error message text into a mail (or reading it aloud on the phone), so how the hell are they going to do it with a sound or a smell? Well, the sound, they could still record it, and attach the recording to the mail, but you can be sure that the recording will be spoiled by the perp's coworker loudly sneezing or coughing midway through. After all, lusers are not afraid of sending in screenshots of error messages half-hidden by other windows either.
No, I think the problem is not the messages (textual messages should be the easiest to deal with, especially when asking for support via mail), but rather the users. And to fix those, you just need a baseball bat...
I had done something very similar, but I kept it very simple for troubleshooting.
3 colours: red, amber, green
3 shapes: circle, square, triangle
Another idea I was toying with was to substitute traffic signs: ie. stop, yield, caution, etc.. but I found that people are used to ignoring those.
With my setup, it gave me 9 distinct error levels (more if I used them in combination), but 9 was good enough for me to track down most problems.
Shapes:
Circle - Bad Input (i.e. data field entry)
Square - Bad Output (i.e. printer jam)
Triangle - Back-end (db/php/html, etc..)
Red, amber, Green = error levels
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
We also had the same issue at first, my apologies for not clarifying. Our version 2.0 system includes a small amount of absorbent material woven into teh seat bottom that can hold 50X it's weight in liquid. We now call the system the Electric Shock Wow system.
A bit bitter about the ID-10-Ts on the keyboards, perhaps?
This is why I think the world should be more dangerous... with the dangers clearly marked by logical but confusingly obfuscated signs.
Give schoolmarm evolution some help.
Tell them that reading the message will enlarge their penis... which isn't too hard to achieve anyway.
--- What?
In the late 90's our startup had HP as a customer for a new on-line product. One day, about six months after they had become a customer, we get a call saying our product does not work. At the end of a SIX HOUR support call, I got on a plane for a cross-country flight because we just could not duplicate or figure out the problem. At 7:00 AM that morning I arrive, and at about 7:03 AM had the problem figured out. HP had recently made a change to their nework removing the browser ID string when employees were surfing the net. Our product needed that information for some processing. Even though the error message was CLEARLY being displayed, not once in the previous day's support call did this get mentioned. "Oh, that happens all the time, it happens with all sorts of applications, so we just ignore it." We had a fix in place by 10 AM and I was back on a cross country flight that afternoon. All because the customer ignored an error message.
Worker Drones love to open attachments and read jokes. Use this to your advantage and profit.
captcha: formats
Or you could have them enter a unique code before allowing the OK button to be pressed. That way they have to call TS to get the code. That would guarantee that you would get the message. The problem is that you would get so many extra calls that you wouldn't be able to do anything else.
Dear Slashdot,
I am filled with a black, unutterable contempt for the troglodytic users of my application. Can you suggest ways to translate this contempt into software?
Read my blog.
It's not an error. Errors prevent you from continuing. The only thing approaching an error is the little box telling you there's a problem. That is solved by the user clicking "OK".
The entire way errors are handled is wrong. I don't know what the solution is but I very much doubt it's a simple modification to the current fundamentally flawed system.
What error does the "women's underwear" icon stand for?
I have been wondering about this for 30 years. End users are not interested in learning how the computer software works, except for how it lets them do their job. On-screen messages, manuals, fax-back systems, wiki pages, they don't care. What they want is to pick up the phone, make a call, and have someone tell them what to do. At first, I thought it was them being lazy. However, I now think it is closer to why programmers don't like to be interrupted in the middle of a task. The user has a mental model built up of their task, and they don't want to risk losing it while they search for information on an error. Making a phone call, and having someone else walk them through the problem solving means they can maintain their task in "main memory". For them, it is more efficient.
Why, without your clothes, you're naked, Miss Dudley!
I've been down that road. It's a good idea until you have a hundred people calling-in trying to hum the error to you. What's worse is you can't debug because they're tone-deaf :)
Seriously though, it sounds like you want a system that can record the error for your debugging purposes later-on without the user needing to remember a number of color. Why not just log the error in a system file, or better yet have it send a quick message to a central logger/email that you can check? Then you can be as technical with the data as needed and know the entirety of a problem before they call for a blue square.
Also, for self-debugging make sure you keep reported errors to simple, broad categories, ie: blue = file error, yellow = network error, etc.. The barrier for calling you with errors is when a phone call is less effort than thinking for themselves, and while there'll always be a group who aren't capable of the latter there'll be an equal number who can associate yellow with "unplugged network cable". This applies to sending people to help files as well, they won't look if it's easier to call you so it's a wasted popup.
Hope this helps,
-Matt
--- Need web hosting?
Get rid of the time rush that works are under as some people may try to just get around the error so they don't have to wait on hold / go though all the level 1 stuff like reboot your system / and other stuff that do not get to what the error is.
Take a deep breath and remember that if users were savy enough to read and understand error messages - well, what would they need you for? You are there to make their jobs easier, not the other way around.
Stop pushing the inadequacies of the program on the users. If you come across the error, then log it. Why are you relying on a person to sit there and read back to you something that could just as easily be written to a file that they could send to you or read directly.
The error message has to have a good plot and some character development. Pull the users in with that and then get the error message across. Ok, seriously, as a writer of error messages at times, I have found putting in 'interesting' wording works sometimes with some of the more intelligent users. Unfortunately, there will always be the ones that just want someone else to do their work. I suggest that they be burned because they're witches.
Fat, drunk, and stupid is no way to go through life, son.
Every day I have to fire up a Microsoft Access database program to clock in.
Every day the first thing it does is pop up a dialog box that says something like, "Only run this if you trust it".
I just hit OK.
It's not my problem if it works right or not.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
a risk based approach is required, so that users know that occasionally a message box will appear that will have serious negative consequences if they fail to take the correct action.
For example "If you don't turn around right now I'm going to smack you over the head with a baseball bat" [OK]
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
Amiga had this right. Use a little humor with your messages, it may diffuse the anger and get some sympathy.
Add an input field on the error message that makes them type the text of the error (or the key bits, anyway) before they are allowed to dismess it.
I guess after you waterboard them for several hours when they dont tell you the error message, maybe they start to read it. However i have doubts about it. My experience rather says that when the secretary says "i could access the webpage which you mentioned about without problems" it means "yes, i also clicked away the warning about the missing certificate".
...is an educated customer with which your technical support people can converse in an intelligent manner so they can listen as the user recreates the error by performing the original error-causing actions again.
Barring any intelligence on the other end, we have had good success with extensive error logs that are either automatically emailed to us or sent by the user to our technical support people. These logs tend to contain brief information that points directly to the offending code - i.e. routine name and even line number if possible, with small variable or data dumps when that would be helpful. This way our developers can see exactly where the error occurs and can either build in some bulletproofing or can backtrack the logic to see where the error originated. Just logging "error 5576" doesn't cut it unless there is only one place in the code where that error occurs and the developers can find it quickly by searching their code.
This type of log can be generated in cooperation with technical support - i.e. the end user selects a preference that starts logging - or it can simply run all the time and software keeps only the last few days of logs while deleting the older ones.
Another solution is to use webex - that way you can start a remote session and watch in almost real time as the user works - you can often catch things happening that the user would otherwise not report. This isa big help in rooting out issues where the real problem is user error.
i've had this happen to me too. its to the point i log everything and i tell users i will not help them unless they provide a screenshot of the error and a log.
at that point you either get the screenshot and a log or the user stops using the product. either way support costs goes way down.
People can't handle the number and complexity of error situations which most programs unload on them. If you make the error messages more visible (or audible as someone else suggested), the users will only get more annoyed, not more informed. "Check engine". The engine of a car is not something which can be repaired in a few minutes at almost no cost, yet people frequently ignore that message.
Users will not read error messages. I've talked people through problems with their computers on the phone, repeatedly telling them not to click anywhere without me telling them to, but I still hear click click click-click. "Did you just click on something?" "I always click on that" "What did it say?" "I don't know, it was just a popup."
The solution is remote desktop software, or, if there is a problem with their network access or some hardware problem which prevents online assistance, on-site service. Users pay for it if it's important to them and if it's not important enough to them to pay for the solution, then it's not worth my time either.
I was the alpha geek on a Help Desk at a multi-state corporation, and the CIO had worked with me as an engineer before getting the job. When people too (self-)important to call the Help Desk had a problem, they would call him directly. He would give them to me, and I would make sure they were kept happy and their issues got resolved.
One day, after a vice-president had SCREAMED at him because they couldn't log on, he asked me what I had done to fix it.
I told him that their 'caps lock' had been on.
He asked, "Doesn't the Windows error message remind users to check that?"
I told him, "His lips got tired before he read down that far."
Put the error message in a popup window with a background random pic from Sport Illustrated swimsuit edition.
Number one answer would be to make error messages that are actually useful.
Here's an error I got recently. It's a pretty common error in our SAP* system: "Error Code: -1 Error Desciption: Code: K/101. Error occurred in derivation rule. See long text." (Please note that there is no long text.)
Here's another recent error message I encountered. Is this helpful?
You have either entered an invalid Member ID, an invalid PIN, or your User Account is locked. Please validate that you are entering the correct member ID and PIN and try to log in again. "
Translation: when you did the mandatory password change (required every 90 days), you entered a password that contained the } character. Although the rules say you must include symbol characters, we didn't mean that symbol character.
And dozens of other equally useless ones.
--
*"SAP" is not actually an acronym. It is the word used to describe the customers who have been persuaded to buy this software.
http://www.geoffreylandis.com
Again and again it seems that the best option would be to find out what a firm with staff lacking opposable thumbs and with an inability to read does to afford your fee. Then copy the business model using staff that can hold a fork and read at the same time. It would seem that the bar is not very high. Profit.
I have roughly 50 users I support, of varying technical capacity. Yet 99% of them are completely comfortable capturing screen images of items they are unsure of. I suggest installing a simple to use print screen utility. My personal favorite for ease of use is FastStone Capture, which would require licensing, but it allows them to quickly capture part or all of the screen and attach it to an email in a few simple clicks. Since the error itself is almost more valuable then the log data, it could be relatively easy to justify the cost. It also may be beneficial to any users that update business processes or other documentation with screenshots. Hope that helps, and good luck. I'll be keeping an eye on the thread to see if anyone else has any great suggestions.
As a game designer, and sometime game UI designer, I feel your pain.
The best way to get people to read your error messages is to have very few of them. People just tune them out. If you're tossing up error messages for things like synchronizing to network shares before the user really needs to, or connecting to 3rd party tools that the individual tool can handle the error for, cut those. They'll get to those errors later anyway, or the problem will be fixed by then. The only error messages should happen when it is impossible to do what the user asked.
The ones that you do have should be 7 words or less, and should be both meaningful and in plain english (even for engineers). "Uninitialized Data" is technobabble, and "It Didn't Work" doesn't tell you anything. "Couldn't connect to the mail server" is much better, as it tells the user exactly what was wrong, but within a small enough space that by glancing at the textbox the user has already read it.
Icons are most likely going to confuse your users unless they directly relate to the error at hand. "Warning: Trojan Detected [panda kicking a soccer ball]" might be cute, but if people are already confused they're going to have a hard time remembering even the soccer ball. The conflict of visual imagery just muddies the water. Throw a needle on the screen, and everybody will remember in a panic that the error had a needle up there, but not what the text said. If that snippet of information is not enough to work from, you'll need to find a different solution.
The ______ Agenda
In the late 90's our startup had HP as a customer for a new on-line product. One day, about six months after they had become a customer, we get a call saying our product does not work. At the end of a SIX HOUR support call, I got on a plane for a cross-country flight because we just could not duplicate or figure out the problem. At 7:00 AM that morning I arrive, and at about 7:03 AM had the problem figured out. HP had recently made a change to their nework removing the browser ID string when employees were surfing the net. Our product needed that information for some processing. Even though the error message was CLEARLY being displayed, not once in the previous day's support call did this get mentioned. "Oh, that happens all the time, it happens with all sorts of applications, so we just ignore it." We had a fix in place by 10 AM and I was back on a cross country flight that afternoon. All because the customer ignored an error message.
I have two questions for you:
1. Why does your application care about the browser ID string so much that it is unusable when there is an unexpected value?
2. Why didn't your application phone home with the higher error levels so the application experts (i.e. you) could diagnose the problem?
It's funny that you blame this problem on your customer. Is this startup you were working for still in business?
Funny error messages. really funny. not 'microsoft' funny.
Read radical news here
The first thing you need to learn, that your slowly starting to learn, is that your user base can't be bothered. If they click a button and the error message goes away than they consider their problem gone. Unless they can no longer use their needed application, they will not both bother to call it in.
Look at the user experience for someone who does have to call it in. In many companies this means a call to a helpdesk in India, an aggravating set of phone menus and an unpleasant conversation. However if they just click the button, use task manager or reboot than they have 'solved' their problem themselves.
What you need to do is to adapt to your users instead of trying to get your users to adapt to you. Set up software on their computer that monitors for certain error codes. You can fairly easily set up different tools to look in the log files for certain events and than do something about it. That something could be as simple as a timestamp, taking a screenshot, recording all open applications and services and sending a notification to your helpdesk with the requisite log file.
Short of using something like another commentator said about disabling the users ability to do anything other than to report by using penalties, there isn't anything you can do get a user to report because the bottom line is that they can't be bothered.
How about just asking the users to press the print screen(PrtScn) button and send the screenshot to you.
I've found, that promising sweets, say a tiny pack of gummibears, for any new error, that has not been seen before motivated everyone.
Simply ask them to make screenshots to prove that it is a new error and you are of.
Think about it. Finding Bugs this way makes fun and is totally worth the packet of sweets.
This really works!
Because the bosses are hanging on every word and observation that the Help Desk Guy shares with them.
You were walking the user through the process, and you never asked them what's on the screen?
http://www.geoffreylandis.com
"how these people have a job not requiring a broom is an eternal mystery."
And the can VOTE to regulate people's lives!
You cant fix stupid...
Many times when I ask a customer for the error message log, it will have the solution listed in the error log...
"Application whatzit cannot find the snapinfo lun, please rerun the whatzit configuration wizard"
I am the unwilling control for my Origin.
Beat them.
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."
Sounds like *you* have a problem communicating with these people by not making it dead obvious that you need to know about anything that they encounter during the process.
Ultimately, end users don't know what's important and what isn't. You need to point this out to them with no question of what you need to know.
Didn't read it, but it had a stapler
Make your error messages interactive. Hide a code in the message itself and make it so the user must find the code and key it in to continue. Perhaps let the code be written out numbers (one, two, three) spattered throughout the message in random locations.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
ALL people remember what is important to them, and do so by relating it to things they already understand. We software types can relate messages like "too few file descriptors" to things we understand - WE know what a "file descriptor" is. Imagine that the error message instead said something like "LO VCO UNLOCK", or "Wrong mode for DX window": while some of the people here might understand those messages, unless you are a radio guy they are meaningless, and you have nothing in your world experience to which to relate them. I'm sure many of you can add your own problem-domain specific errors here.
Adding error numbers: "Error -522: LO VCO UNLOCK" doesn't help - unless the number "-522" has some special meaning to you, you still won't be able to relate it to your world.
However, thinks like puppies, colors (save for those who are color blind), and simple shapes are things most people can relate to. So the idea of "[image of sad puppy] LO VCO UNLOCK" can resonate with users of all stripes.
I'd suggest that any such errors log the details, even across runs, and that there be a way to retrieve the error data and send it onward to you as well.
www.eFax.com are spammers
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.
Yes, exactly, Praise Jesus!
Many of those "messages" to the user have absolutely no meaning to them. When I see things like "Error in Foobar::method; 0x2383FFAA, trace ..." and the program chugs along without a problem or shuts down and restarts.
I think just how useless to the user it is. Users have gotten trained to ignore them because they have no meaning to them.
Or the other things programmers do is that they have an information message box for every little piss ant activity. I don't need to see a message box if the file has been successfully saved!
This is how we handle errors and such on our internal software -- the user is prevented from continuing if "something" must be done to solve the issue. These are rare, because in many cases we can programmatically figure out what's wrong and dynamically prompt for replacement values and such. But in those instances where continuing would leave data in a "dangerous" state, we halt the user's progress, and they either get the opportunity to fix or they're instructed to get someone who can. If they wish, they can back out and redo the whole transaction.
We've found this works quite well - in most of the cases the users may not know exactly what they did that generated the error, but they appreciate being able to self-manage the problem without having to run to our dep't. for resolution.
Get rid of first-line support and make it very, very difficult for them to get in contact with the troubleshooters and sysadmins.
No, I'm serious. That's the only way to get them to read the error messages: send them afloat by themselves, without the liferaft. They'll have to hold themselves afloat by their own sheer heft and willpower.
Even if they do manage to track down the higher level techs, the "don't talk to me, I'm busy" rule applies.
This way nobody actually gets 'blamed' for user stupidity but the user who breaks the computer, there are fewer user errors due to them actually paying attention and learning, and the sysadmins actually get work done.
More will get done and the users will have fewer actual errors. Support costs will be saved, and users won't begrudge those IT guys who do "nothing" all day.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
"uninitialized data" is meaningless. It's something only a programmer would understand.
Instead tell the user what *he* did wrong and tell him how to correct the situation.
"No recipient address given. Please enter the the e-mail address of the recipient and try again".
This is your sig. There are thousands more, but this one is yours.
LART
Welcome to the Panopticon. Used to be a prison, now it's your home.
Imagine you're Click and Clack. Someone calls you up and tries to reproduce a sound. As if by magic, you can deduce the problem, how difficult and expensive the solution is, and who's qualified to perform the work. Now imagine you have full control over every sound the engine makes and can in fact make error sounds to make this job easier.
It seems to me that you have two choices for volume ("Was it quiet? Was it loud?"), a few tone questions ("Was it high pitched, low pitched or somewhere in between") and even a few frequency ones ("Was it intermittant? Fast or slow? Was it constant?"). I'm sure that, if you have more variables than that, you can toss in a few more permutations. Just make sure they're easy to pick out.
Also, force the error message not to be dismissed in less than two full minutes with your phone number on the screen.
Of course, having every error message drop some key logs into a database you can query might be a good idea too. Then you can post-process it with a few scripts and call them with the solution.
Unprovoked Genital Damage!
Knowledge = Power
P= W/t
t=Money
Money = Work/Knowledge so the less you know the more you make
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.
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.
Install Splunk and read them on your own.
robots obey what the children say - TMBG
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.
...obfuscation.
Users have been conditioned to simply click away message boxes as quickly as possible and get on with their lives.
A Windows computer is constantly popping up boxes that get in your way. Sometimes it's just to inform you that a wireless network was found... Other times it's asking for confirmation for something... Other times it's a warning... Sometimes it's an error...
Folks don't evaluate what the message says, they just make it go away.
You can put all the puppies and red numbers and blue squares as you want... They're still going to click it away just as quick as they can.
You could alleviate this to a certain degree by taking away their ability to clear the error message. Put in an error code somewhere, along with a phone number for technical support, and no way to close the box. They'll call you and you can have them read off whatever you need. Then you can tell them whatever bizarre combination of keys will actually close the box.
A better solution would be to simply write a log of the error message when the box is generated, then you don't need to rely on the user to do much of anything.
"Work is the curse of the drinking classes." -Oscar Wilde
I find there are really two scenarios: unknown error, or a known situation. Displaying an error really should be a default error by security principle. Let’s say you have a login screen. You would not want to have multiple errors: username does not exist, password is incorrect, and your account has been locked. You give a hacker the information that they have a proper username, and that their next attempts are in vain. By simply saying invalid credentials, you cover all cases. Additionally if you have a know situation, of system being used improperly you should either thrown a security exception, or handle the situation. You should create more of an information, or user manual on proper use and call it a day. If you have a global application wide catch for unhandled exceptions, you can log information and decided if the user should be logged out.
You were walking the user through the process, and you never asked them what's on the screen?
I can relate. I used to manage a group for a web development team (at a previous job.) Part of that included managing the helpdesk, and I worked closely with that team during rollouts. I got some first-hand experience that when you ask users to tell you what's on the screen, often they will "filter" the information for you, because they figure some stuff just "isn't important".
You can tell them all you like that it's important to know exactly what they see, but they'll still "filter" little details like this. It's very frustrating. On the web, pop-up messages tend to get ignored for example (late 1990's) even though you put an error message there. You might be 15 minutes into a call before they mention that little pop-up window that they read but dismissed.
Managing that helpdesk is where I picked up the maxim, "Nobody reads anymore."
The longer I do desktop support, the more it becomes obvious that my users don't read anything that appears on their screen.
Error dialogs are like the sign at MacDonald's that says you have to pay for extra ketchup packets - nobody reads them. If you are honest with yourself, you will admit that you don't even read them unless you are working an issue. Bright colors and cute picture are a waste of time - no one will see them.
I like to think that my users would remember the error that caused them to get a kick in the balls.
That's a terrible plan. If using your product is painful, then the user will find an alternative.
It's already been said, but it bears repeating. Automatic crash dumps are the only way you are going to get reliable information.
Don't produce an error message and expect the users to remember it. 1.) Write all error to log file. 2.) Keep a running log file of recent activity, so when there is an error you can see what led up to it. 3.) Present a simple messages. Worst case should be something like: "An error has occured, contact Engineering staff for support."
I try to design my apps so that users cannot progress to the next stage unless all the required fields are filled in, correctly. I also put a colored frowny face on some error messages -- the user might remember the color, which is a clue to the cause -- however, don't rely on that. Rely on the logs.
How about asking the user for his/her credit card information and a check box, which, if left unchecked, could allow the systems administrator access to use that card number for any number of online purchases, shipped to some random place in Central Africa? Hey, they can use your users' stupidity to buy well needed learning equipment, right!?
--Stak
Holy happy hippy crap!
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.
And a gun.
Make a note of this error message and take it to the help desk or we shoot this puppy!
Another option is physical violence: when you start to explain something to them and they whip out the note pad and start to write things down, a steel rule across the knuckles accompanied by a polite reminder that this isn't f***ing French dictation - look at what I'm f***ing well showing you on that big square glass thing!.
Alternatively, a full Clockwork Orange rig with eyelid hooks and head clamps can encourage users to actually notice that things are happening on the screen when they're typing. Ludiwg Van is optional.
The real problem is if you're dealing with older, trained touch-typists who've been subjected to techniques not a million miles from the above to stop them looking at their work.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
In your SIX hour support call, did anyone ask if there were any error messages?
The software was poorly designed if something that simple broke it.
Having used computers since punch cards, the one thing that error messages have taught me is that they arcane, contain so little information why bother recalling them, the meaning of the message is in some large book that I don't have readily available or "It's not meant for the user to have." So just call the help desk.
Well, actually...
PHEM - party like it's 1997-2003!
Your friend,
Clippy
Users, in the vast majority of occurrences, want to just get their job done. They don't care how the software works, and as long as it works, that's perfectly fine. When it inconveniences them, they just want the inconveniences to go away, not learn C++ from the ground up so they can pinpoint the error for you.
To that end, I have two suggestions based on the situation in which you find yourself.
First:
If you're supporting a program that you wrote / helped write, make the error message box more than 5 paragraphs of memory addresses and an OK button. Make the popup something that a user actually cares about, like "Oops, the program made a mistake. Please help us fix it by clicking submit below." Have a submit button that will automatically gather all (of the automatically gatherable) information for you, put it in a report, then allow users to add their own comments to let you know what they were trying to do. Always give them a way to skip a certain step, mentioning just how helpful their submission could be to finding the error and eliminating it forever, giving them more facebook time at work. If your process is slightly informative and makes the end-user feel valuable, they'll be more likely to help you. On a side-note, always send thank-you e-mails to users who report issues, even if it's an automated e-mail. Thank them for their invaluable help, because it's only due to users like them that the program can be improved. Stroke some ego.
Second:
If you're doing 'desktop support' in a general manner, where you need to fix errors caused by other programs, make it easy for users to report those as well. Put a pleasant-looking note (so they don't just trash it) on their monitors with clear instructions on how to take a screenshot and get it to you. Emphasize that helping you find the problem means it won't happen again when you find out why it happened. Users are lazy creatures, and the easier you make it on them, the more likely it is that they won't mind helping you.
The Euro-fighter has a feedback system called Nagging Nora. The system provides important audio warnings in a nagging women's voice.
This could definitely work for computers.
Our boss picked this book, "Made to Stick" (http://www.amazon.com/Made-Stick-Ideas-Survive-Others/dp/1400064287 ) as this year's reading assignment. There are some interesting ideas in here that support things like "the sad puppy picture error".
But a big part of the problem that I've seen is the irrelevance of error messages to the recipient. The Blue Screen of Death in theory contains useful information to the developer, but is completely meaningless to the user. Error reporting (whether it's exceptions tossed by a module or alerts presented to the user) should be based on a clear model of the user/caller's world. "A603 Load Module Does Not Exist*" is a lot less useful than "Cannot locate program to run".
(* If you're old enough to recognize the source of this error message, reply below. First one to get it right gets a prize... :-)
add a captia type feature into the error message. so that the user has to read the error then answer a question before the window will go away...
but this assumes that you want them to read it. not so much to understand it.
then again, this will just get them to read the error just enough until they know where the answer to the captia is, and answer that to get the window to go away.
so in the end we are back to square 1
Perhaps if you used error messages that people accually understood.... Instead of:
The instruction at "0x52fa32b0" referenced memory at "0x45f2588727b". Memory could not be "written".
Which is pretty much the medical term for you have a broken leg. Great for the doctor but pretty meaningless for the patient.
You're dead in the water already. Users don't read dialogs. End of story. Where else in life besides the computer do humans get interstitial errors that pop up and disrupt what they're doing? Not in the car. Not on the phone. Not reading a book. Error dialogs shouldn't be treated as a problem you have with end users. They should be treated as a problem you have with developers. An inordinate amount of the time, users are presented with dialogs for problems that the software itself could and should resolve, and more importantly, the user can't resolve.
Try to make the UI in a way where it is difficult or near impossible for them to make user level errors which would popup an error message... And save error messages for things such as bad or corrupted install or lack of network connection (when the application is actually broken)
Giving Users error messages will only give you headaches. As they will give you wrong messages, or not at all, or panic when they get one. Go with logging if the problem is persistent then quit the app. Yes it takes more work... However if you though of the condition that could create an error message if you put a bit more though you may be able to get the UI so it doen't need to give an error.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Sorry, but this one is your company's fault. Before anyone boarded a plane, you had access to server logs and could have run a protocol analyzer on some sessions where users recreated the problem. I worked on international systems, where that "cross country flight" of yours would have been 21 hours to Hong Kong. There was never an emergency support flight because we solved our problems remotely. Thanks to a 13 hour time shift, we were HIGHLY motivated to make things foolproof.
Looking back at everything that happened in your story, it should now be obvious that the solution could have been found without showing up onsite. Assuming your startup is still afloat, I'm sure that next time the problem will be solved much quicker as long as you have the veterans of "last time" in a position to help.
HP had recently made a change to their nework removing the browser ID string when employees were surfing the net. Our product needed that information for some processing.
It would have saved you some aggravation, if, in addition to displaying the message to the user, it would have logged in on the server. That way, you could have figured out what went on without relying on the user.
Still doesn't excuse the luser of course.
It's not an error. Errors prevent you from continuing. The only thing approaching an error is the little box telling you there's a problem. That is solved by the user clicking "OK".
The entire way errors are handled is wrong. I don't know what the solution is but I very much doubt it's a simple modification to the current fundamentally flawed system.
WTH was this marked as troll? It is true. How many times have you compiled something and gotten a page of warning messages, scanned through thinking "warning, warning, warning, warning, blah, blah...no errors? Sweet, it worked!"
Q: How do you get users to read error messages?
A: How do you write error messages that are worth reading?
Commentary: Users do not read error messages because they are mystified by them. To mystify them willfully only increases their resistance.
The first job is to create error messages that actually help the user. Users are conditioned by the generally crappy state of error messages to ignore them. If you provide helpful error messages then the users that *can* be helped can be trained to read them. It's operant conditioning -- like giving a rat a food pellet for successfully navigating a maze.
The very first thing you should do with error messages is pull them all together into some kind of document. This document should have (1) an unambiguous ID for the error; (2) a description of *what* happened ; (2) a description or at least a guess for *why* it happened; (3a) the impact of the error on the user (3b) how the user can recover from the error; (3c) what the programmer can do to avoid this; (4) what the user needs to do in the future.
Note that 3b also implies that *you* should consider how the program is apt to behave after the error message is displayed so you can offer the user sensible choices. For example, if the program fails to write the application preferences file on exiting, it makes sense to give the user both retry and cancel options, rather than sending him into a pointless loop that requires him to shoot the process down.
Then you write an error message that tells the user roughly what happened, what the impact on him may be, what he needs to do to get out of the corner he's painted himself into, and what he can do in the future. This should always include an unique message identifier for your use.
Example:
Please note this error number: #1234. You will need it if you contact technical support.
The program was unable to update the application preferences file. That is the file that stores the settings you have chosen for things like preferred document styles and last document viewed (choose "More Information" for details).
File updates can fail when the security permissions on the preferences file or directory ave been set to prevent changes; when more than one program is editing the preferences file at the same time; or when the computer's file system is damaged.
You can check for these kinds of problems (chose "More help" for instructions) then choose "Retry" to see if the problem is solved. If you choose "Ignore Error" the program will continue without saving any preference changes. If this error persists it is recommended that you check the security settings, permissions and integrity of your filesystem.
[More information] [Retry] [Ignore Error]
Now if this sounds like a pain in the ass, it *is*. But it's a much better approach than trying to trick users into reading a piece-of-shit error message like "File operation failed" for a condition like that described.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Some advice for programmers trying to do interface design: Don't. Leave question like this to an interface designer. If you can't afford one, or you want to do it anway, a good book for starters is "The Design of Everyday Things" by Don Norman, it's not even expensive. Further, stop treating users as a problem in the system. Every user has his own model on how the system works. This model is very likely very different from the programmers model. Your task as an interface designer is to teach the user enough about the system (or it's model), so he can use the system successfully. Error messages don't help very much, as you've figured out, users don't read them. The lesson is, don't try to force the user to read error messages, instead find other ways to communicate the model. Often, it's a good idea to think about the problem in an abstract way. For example, we have a similar problem at the place I work. There are two doors next to each other, one you should use, the other one you mustn't because it triggers the alarm. They tried to fix it by attaching a sign saying not to use that door. Needless to say, it didn't work, because noone read the sign. Just like your error messages, this sign was completely ignored. It's not wrong of the users to ignore the sign, quite the opposite: We have to filter out information to survive. If you pass through your environment, you too ignore information, i. e. I don't think you read every sign in your proximity. I have no idea why they couldn't come up with a better solution for the door: Locking it would be very easy. Even better, by removing the door handles it would be very clear that the door can't be used.
at that point you either get the screenshot and a log or the user stops using the product. either way support costs goes way down.
... and it will drive your competitor's (client's new supplier) support costs up, as they will now have to deal with the silly screenshots...
Require them to type in a passphrase to dismiss the error. Similar to the "red 5" / "blue square" - each error has a specific word or phrase that must be typed in. They should remember if they just got the "Mickey Mouse" error, or the "OMG that's not good!" .
-Remote control of user desktop helps a lot.
-Command line commands can be very simply instructed by support. (instead of "click on the rabbit icon")
For example, I was thinking about creating icons or logos to identify specific errors.
Choice 1) I assume you have a company directory with pictures of personnel. Use them. "I got a Patty Sue error...". I have, in fact, done this. It is best to use well known personnel (the receptionist, the director, etc)
Choice 2) I assume, being a slashdotter, you have a vast collection of Pr0n. Use them. "I got a Goatse error...". I threatened to do this, but never actually did it.
Choice 3) Combine #1 and #2. This is by far the funniest if you make pictures that "us slashdotters" would recognize but the general public would be completely unaware of. "Well, I got an error message, it has those two women from accounting, and a cup..." "So, the error message has a bunch of lemons at a birthday party" "After it stopped working, I see a goat on the left side and the Mediterranean Sea on the right side"
Much more boring, yet almost as illegal, is to violate copyright laws and include cartoons. Oh, you say you got a dilbert error? A family circus error, that'll take awhile to fix.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
...I am an IT person who, with our crappy commercial software and half baked open source or in-house solutions, has a user base that no longer reads the endless, incomprehensible, tiny font hobbled, hex code laden error messages with which they are continuously pummeled. When my users complain, I treat them like dirt on open forums where they can see the general attitude of IT folks toward people who just want a tool to do their job, and suggest they go back to preschool or that the computer deliver electric shocks. I ignore the simple possibility that the users have simply become immune to the endless errors and bugs, and I instead whimper like a crack whore jonesing for another fix. My question is this: is it too late to salvage my life?
For starters, where possible, the error wont actually close for them unless we enter an admin password to make it go away, and if they reboot to get rid of it (Task Manager is disabled on all client PC's) the machine will not open the application that crashed for 15 minutes.
An IT guy tried something similar where I work many years ago. All the investigators ever found was the remains of one of his shoes in a drainage ditch several states away, and the word "Croatoan" carved in a nearby tree.
I like to start with Green Eggs and Ham and work up. Eventually, they stop mouthing the words and are able to read whole sentences. Put lots of pictures in the error messages so that they can be sure to understand. Maybe add a 'treat door' in their cubicle. When they click on an error message, they get a candy.
*** Don't be dull.***
One should never try to rely on users to give any kind of report other than layman symptoms. The application should create proper error logs which is then used to debug the error. (OSDial is such an example. It is a dialer and to save time we only need an indication on where the problem is to save time on the debug.)
Of course this does not work unless you are the programmer, or have access to source. Windows is not particularly known for good logs.
I had a support call once where the customer was 'interpreting' the error message I needed to know about. It wasn't exactly a long message - just one short line, but I didn't recognise the message from what he was telling me. Even when I asked him to read it to me verbatim, he still insisted on 'interpreting' it. Eventually I was reduced to asking him to spell it out to me. He clearly thought I was an imbercile, but I finally found out what was on the screen in front of him. It was nothing even remotely related to what he had been telling me; suddenly everything made sense and I immediately had all of the information I needed to provide a fix.
I love haptic error feedback. Nothink like the "slap in the face" error, sure your users will remember it!
Let's drink!
Employee Of the Month - Cyberdyne Systems Corporation - September 1997
Bill.Gatez@microsoft.com... : no such user => clearly a message to the user, not the programmer (hint: check that spelling!)
Bad login or password => same thing
IE6 no longer supported => not the programmer's problem either...
I was trying to explain to my wife (who was pretty sciency, seems less so now) why I hated the way science/history are taught in school. I said they go on and on about the 'great minds' that history was kind to like Edison, but don't even mention people like Nikola Tesla. She proved my point by asking 'who?' I said Tesla, the guy Edison stole many of his inventions from and the father of AC power without which we couldn't have our nationwide power system. I start to explain why AC facilitates high voltage power lines (transformers) and why HVPLs are important (low power loss per distance) she stopped me and said don't explain it too me.
And she wonders why I can't remember everything she says. While basically telling me tldl (listen).
They are correct to ignore the error most of the time. Errors like that are worthless when ignoring them "seems to work". Obviously many folks will try their best to make things work an all browsers, but if you're going to take that route, don't throw errors. Either it works or it doesn't, but don't show an error and then do your best with what you've got. If you need information, it should not be possible to proceed without it and the error should be there plain as day. Pop-ups are not OK, they can be dismissed and then you're back to what exactly? Then on the phone, you ask "what does it say on the screen?".
Anything that can be dismissed will be dismissed and the user will think they took care of that problem - I made it go away.
Most errors spew garbage about Exception and Null Pointer, and No Resume, etc etc ad-nauseum. That will get an immediate non-response from an end user. Most importantly, you need something that a typical end user can understand. The technical error can always be logged elsewhere, but the information as presented to the end user can't be overly complex, overly long, or confusing (Keep It Simple Stupid). I can't stress that enough.
If all else fails, you can randomize the 'chime' that's played for an error to grab their attention, as well as utilizing full screen errors to hide what their working on.
You can also consider non-standard response dialogues/buttons that actually require them to read the button.
We used non-standard modal dialog boxes, odd colors, plain text errors and consequences, and non-standard buttons to good result.
You were walking the user through the process, and you never asked them what's on the screen?
Users are not reliable sources of information. Anyone who has ever worked in support will tell you that asking a user what is on the screen is an almost pointless activity.
About 30% of the time they will tell you the truth in terms that are meaningful, like "There is a dialog that says xyz".
50% of the time they will tell you something, but it will be couched in terms that are meaningless or misleading. Users have a different conceptual universe than developers, and often give reports that are honest in their own terms but so figurative and metaphorical as to be useless for practical debugging.
The remaining 20% of the time users will tell you something that is flat-out false, claiming there is no error dialog on the screen when there is, or reading off an error string that does not exist (or is clearly marked as from a different application!) and so on. They will claim the application will not start when it does, or tell you it is still running after it has crashed.
So asking users what is on the screen is something support people always do, but they never expect to get accurate information back because much of the time they don't. In the case at hand, certain types of error dialog rapidly become invisible to users, and they will deny ever having seen them despite log files that clearly show they clicked on the OK button.
Blasphemy is a human right. Blasphemophobia kills.
...I am still trying to find a way to get desktop support techs to read the error messages.
The less you talk, the more people hear you say.
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.
As many others have pointed out, users have become conditioned to just click "OK" to proceed, even when that's not the best course of action.
Put buttons on the dialog that make the user think about the answer:
"I agree/Disagree"
"Save in this directory/Choose another location"
"Cancel import/Search for file"
"Continue with errors/Ignore bad data"
Of course, this assumes you have some control over the messages. If you're trying to get them to read messages from some third party, well...make it more painful when they don't! :)
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
When you accept that, you actually open up a few more options.
That last point is key. Do not waste the user's time telling them something they don't need to care about. We have only ourselves to blame - for years we have been thrusting annoying, pointless, and confusing messages into the generations of software developers popping annoying messages into the user's face -- effectively training them to ignore the messages. Many of those messages are things that users do not need to know or care about - so don't slow them down with the information.
Finally, keep in mind that users aren't necessarily looking at the screen. I can't count how many times I''ve seen people staring at their keyboards and continue typing blithely while a message is displayed and input is being ignored. Usually this leads to one of two things: a) user sees their typing is lost, gets annoyed, and clicks through the stupid message preventing them for working, or b) user hits the Enter or space key in the course of their typing, and dismisses the message without ever realizing it was there.
I have had the "filtering out" as well when I tried to explain somebody where to enter the internal domain name. They kept using google and obviously did not get to the screen. So I went to a screen that I knew they were able to see and ask what they saw. I noticed that they skipped information and asked them if they saw X. The answer was "Yes".
Even when i told the person that I needed each and every detail they saw, they kept filtering out importand stuff.
Again, this was just WHERE they needed to put the URL so they could go to the correct page. i tried explaining it with:
What do you see on top in the blue bar? The answer was "Nothing". Do you see the blue E with "Shlashdot Comments" (as I see now)? "Yes" What is written next to it? They gave the correct answer. What is right below it? "Nothing". Do you see a field that says "http://...."? "Yes" What does that field say? "Nothing".
Took me about an hour to get it explained where they needed to type "http://intranet". My guess is that some people rather give no information then give the wrong information.
Don't fight for your country, if your country does not fight for you.
1. Why does your application care about the browser ID string so much that it is unusable when there is an unexpected value?
That's a good point. Hey, ip_freely_2000, can't you force all the HP staff to use Netscape Navigator 2.0, and simply use HTML 2.0 in your programming? Why were you trying to detect the User Agent ID?
2. Why didn't your application phone home with the higher error levels so the application experts (i.e. you) could diagnose the problem?
That's another good question. YOU are the ISV. You should tell HP, they should allow your software to contact your Internet servers - especially if your software deals with confidential data! Your convenience should come before HP's need to protect data!
It's funny that you blame this problem on your customer. Is this startup you were working for still in business?
I agree with cryfreedomlove. Your ISV must be so silly to comply with HP's wishes, it must have collapsed.
But people will not remember if they saw a puppy or a kitten. You have to show them something they cannot forget.
"Ok, so when the error came up, did you see goatse or tubgirl?"
how do you get users to read?
Looks like for the software that you are maintaining the question is different: how do you train the users to do what they do without getting the errors?
I am working on a system that is very new to its users and some of the functionality is much too complex for them to understand intrinsically (actually it requires them to use some simplified form of a regular expression for searching of data they need.) This wouldn't work for internet search for 99% of population, so it's not done that way, but in a corporate setup, sometimes specialized functionality is needed.
So, I put in enough logging and monitored the users actually try to search for various items in real time. It did 2 things for me: 1. I called a user when I saw that he/she was trying to search for something, but they clearly misunderstood how to do it. I called them and immediately explained what they needed, before they became frustrated and gave up or maybe worse, accepted the wrong results as if they were correct.
2. I added these types of errors that I detected users doing to a manual page explaining how to use the search.
Now, obviously it is still a useless page if nobody reads it, but it is part of the manual and for power use of this application a little manual should be read, otherwise the user will not know what to do at all.
Logging + preventive work, calling them as you observe them trying to do something that will not actually generate an error (in my case) but give them incorrect/incomplete results, because what they do is not the correct way of using the application.
Later it became obvious that more functionality needed to be added - certain types of search are a bit too complex, so adding a screen with different types of searches being named and the appropriate search expression right there, to be used, instead of typing it by hand.
Just 'reading errors' may not really be the right question, why are these errors happening? Are these system errors (runtime errors, network failures, something a user is not responsible for) or are these user generated errors (input errors, incorrect sequence of actions and such.)
For the first problem you will just have to do more logging and save information to check on it later, and provide users with very generic 'system error, please contact help desk' or some such. For the second problem it maybe that you need to produce a manual and do training, some business software really cannot be used without training, it's not software for everyone to use at home, so it's not built for people with no knowledge of the business domain and processes in the first place. As part of their jobs they probably are expected to understand how to use their software correctly and effectively.
You can't handle the truth.
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.
A, the subtle difference between a non-fatal and a fatal error...
Very simple. Get a coding wiz to write a background app that hooks into the OS and whenever it sees a error dialog box pop up, it either captures the text or does a screen dump to a file.
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".
1- do away with error messages. Have suggestions instead, like "You need to initialize a data file to do that", with whatever file initialization menu you have
2- automate error messages: have a very easy way to send the error log to the help desk, so that at least you don't have to re-walk the user through the whole error
3- have a good UI that actually helps users to avoid mistakes
4- show them how helpful error messages are, saving them time and the humiliation of having to call support.
5- bill for support
6- train your users to handle error messages at the same time you train them to use apps
7- belabor that point during support calls: don't solve the problem for them, show them how they can solve it by themselves
The Cloud - because you don't care if your apps and data are up in the air.
You could always make the software easier to use.
Your description sounds like the errors are because the user "didn't do something right".
Why not accommodate the thought and usage patterns of your users instead of forcing them to memorize a cryptic list of "things to click on to get this thing to work".
I'm a 2000 man.
i teached my mum how to read the f*** messages... i just stand in front of the monitor and asked her to read the message, then i asked her to explain me the error, the first 10 times she read the message it was like "perss esc key to solve all problems in your life" and she answered i dosent understand, i make she reads the message like ten times until she reads it like a human and not like a robot. now or she read and proccess the messages or she is to affraid to ask me... any way, thats worked
A user phones up the helpdesk...
User: I just got an error message on my screen
Helpdesk: OK, what does the error message say?
User: I don't know I just clicked Cancel and it went away
Helpdesk: ???!
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.
I calculate the time to read the message (normal speed), and multiply it by the importance factor. (Warnings: x1.5, errors x2)
The dialog’s closing button is counting this down. But not second by second, as this creates pressure which distracts from reading.
Also the big title of the window consists of the worst-case implication in case of ignoring it.
E.g. doing something that could result in a trojan/rootkit being installed, would look like this: “DANGER! You could go to jail for this!”
Also, to keep things fresh, one could randomize the whole layout and positioning of the dialog. But I don’t think it’s nessecary.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
but you can't make it to drink. So the best way would be to take over their PC. As long as there is no connection issue, then this is much faster and will save you a lot of time. If you use pc Anywhere or http://showmypc.com/ or anything else will depend on your needs.
ShowMyPc has helped me a lot already. For occasional usage it is free. I you want your own server andadvertising, prices are available as well and not that expensive.
But again, Internet access should be available.
Don't fight for your country, if your country does not fight for you.
While it might get slightly better results then just showing ye old wacky error message I predict you'll get the "the what now icon in the corner? I didn't see any icon in the corner" respons. If you can implement something like this to alter the error messages why not just have it send the error message directly to the helpdesk "[user] has experienced the following error .. blahblah" and a full (or as full as you wish) report enclosed. Problem is helpdesk might get utterly flooded and stop reading the error messages or just pipe them all of to dev/nul.
If you have been working in tech support as long as you say you should already be familiar with two specific phrases: "please show me / do what it was you were doing when the error came up" and "read me the exact error message you just got." The rest of this is a waste of time. If they want to be rude and Not do these two things you ask just inform them to write the error done the nex time they get it and backburner them until they do.
Couple of things. In my experience, if its a single error, that pops up fairly frequently and the user can reproduce it, they will give you the error message. If not, then you can follow their steps to reproduce the error message. If they can't remember the error, can't get it to pop up, then tell the user that you are not creating a ticket at that time, and for them to call back when the error appears, and then you can remote assist them.
If users are rapidly clicking through error messages, then either something such as your login script is generating errors on their computer, or they got spyware.
In the end of the day, I think creating custom error messages is going to be more trouble than its worth - just play some tough love and mention that you cannot help them if they cannot tell you what the problem is. This may frustrate them at first, but it won't take long at all before attitude changes. Otherwise, they are wasting their time and yours while you "investigate the situation".
Nothing you can do will get the users to read the message. NOTHING. The best you can do is to make sure that the error will live in a log somewhere (with timestamps and perhaps screen shots if possible) so that you can figure out what they are talking about.
There's simply no way to force people to pay attention to error messages on the screen - they are focused on doing something, and the error dialog is in the way, so they dismiss it as fast as possible. Then they complain that it's not working.
There's just no way around it - they won't read, they don't read, and they can't be made to read. Give up trying to make them read, and instead find a way to get information in the absence of user assistance.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
ultimately you can't fix stupid.
You absolutely can. It's very easy: discipline people and if they keep doing it, fire them.
It'll probably only take one person before everyone else starts paying more attention. In this economy, it's easy to find replacements (especially if the people in your company are really this stupid.) Lots of folks out there looking for something better than Walmart or flippin' burgers.
Please help metamoderate.
This isn't a problem with computers or electronics, its a problem with that people cannot or don't READ what is in front of them. They lack any self-motivation to learn and as a result when something appears broken they assume it is. Basically everyone is such an idiot that if they hadn't been taught which end food goes in their bodies then they probably would all be dead by 3 years old.
Comment removed based on user account deletion
If possible, force people to fill out paperwork when making a support request. People hate paperwork, even if it's short and easy, so they will be willing to do a little actual thinking to avoid it. If the paperwork asks them to copy the text of the error message, it may prompt the user to actually read the message. Those users who can't even handle something that simple will hopefully ask someone more than half-capable, who will solve the problem without bothering you. At the very least, you will hopefully get the text of the error message so you can read it.
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.
Oh man, olfactory feedback! I wonder what a UAC dialogue would smell like.
Don't insult users with pictures of puppies. They may have fear problems using computers (yes, I find this is still the case) but generally speaking, no matter how dumb they may seem using software, people usually know their jobs extremely well; consider it your duty to defer to end-users as experts of their own domains, whether or not they can express themselves in the language you expect. Work with their strengths, not their weaknesses. Tag all task-specific methods (DAO and up) with attributes containing descriptions that will be meaningful to those likely to invoke them. This will allow you to supply plain-English stack traces when something goes wrong, ones that are both recognizable and memorable to those who will read them. In addition, all (unexpected) exceptions should be automatically logged. You should know about and be working on the problem before the user calls, and generally speaking they should never have to call.
I was thinking about creating icons or logos
Remember that there are some people (like me) who are exclusively verbal, and for us, icons rarely provide any information.
I often do not "get" what an icon is supposed to be a picture of, and when I do occasionally recognize an icon, it is often far too generic for me to relate it to a task. (For example, I can recognize a screen-and-keyboard icon, but I have no ability to map that into a meaningful function.) I think the only icon I have ever "gotten" has been a question-mark-in-a-circle to represent "click this if you have a question".
Just remember that some of us just automatically skip over all icons, and focus only on words.
Stop trying to change the user, its much easier to change application. The application should be collecting evidence anytime an error is encountered. To make it easier on the user there should be some sort of builtin mechanism to collect this evidence. Software is built to make things easier and less complex for the user. The collection of this evidence could be triggered when any error occurs and then transmitted to the source developers when an error occurs. Think about microsoft error reporting. Be proactive and when an error occurs have a help desk incident created and contact the end user to solve the problem if it occurs multiple times. Help stop the user from hitting their thumbs with the error if they don't learn from the pain the first time. Its possible the end user could just get frustrated enough and blame the hammer. With the end result being the end user throwing away the hammer and going out to buy a new one. When they hit their thumb again they aren't going to think that they are doing something wrong, users never do.
I've done this.
The "Danger Will Robinson!" bit, I mean.
A third-party app used to die and shit Paradox .lck files, which would then prevent it working when you restarted it. So I wrote an app which would clean them up, but it was important that the third-party app not be running when you cleared the locks.
So often customers would call me, I'd recognise that the problem was bogus .lcks, and I'd tell them to start up my .lck-clearer. Normally on a tech call you have to keep asking them, "What are you seeing now?" or, "Do you see such-and-such?". But with this app, as soon as they got it running, they'd see the page explaining to them why they should only press the button to clear .lcks when the third party app was not running, with the aforementioned text emblazoned across the top in 36-point bold, and they'd say, "Danger Will Robinson". And I'd know they were looking at the right screen.
Make them answer a multiple choice question based off of the error given, if they answer wrong, the error is displayed again, and again and again, until they pay attention and answer it right.
you can't as each popup is seen as something "in the way" of obtaining the user desired result, no matter what, even if the operation did by the user makes totally no sense in the given context.
one principle of design is not to allow the user to perform operations that cannot be completed. so for example if you're on a client/server application graying out each window during a disconnection will effectively tells the user that no operation could be done at the moment. couple that with a colorful status message like a "trying to reconnect" progress bar and now you're sure that the user won't try to retry the operations each time dismissing the "unable to connect" error popup without reading it.
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.
Everyone reads those. Everyone. You could flash people with strobe lights and not get more attention than scareware and spam gets. So why not copy their behaviour?
Scare the user into reading your error message. Tell him in no uncertain terms that you close his bank account and make his monitor explode if he does not read carefully what you want to tell him and follow the orders.
It seems to work...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If you can manage it, don't rely on users at all.
This won't work for everyone, but as a medium sized company with its internal software being a web-service, we have the system email errors to ourselves (developers). Perhaps it's a waste of bandwidth and my mailbox, but the benefits outweigh the cost - dramatically.
Doing this, you have the error message within your grasps, and rarely have to rely on users to tell you what they did wrong. It also gives use the ability to quickly recognize any bugs that make it into the system. Of course it's not 100% foolproof, but it has REALLY helped us, since you absolutely cannot count on the user to do the right thing, read the right thing, or pay attention to anything.
i think users would start to pay attention if the program gave the user a way to fix it and not just an error code that wants to send information back to the main server. if you really gave the user an easy way to fix the error, many more people would try to fix the problem. where it stand now, is its just an annoyence to most people when all they want to do is use the email (which they may have a hard time even using that haha) thats how i feel at least.
Put an animated gif of shaking boobs over the error message. 100% guaranteed read.
After the dialog is dismissed, give them a multiple choice question
about what the error said.
/facepalm
Hell, I am an admin and I don't read error message.
If the same thing pops up 2 or 3 times then I might read it.
TRUTH.
I'll try anything once. Twice if it tastes good
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.
make the buttons dependent on them actually reading the message and having to answer a question that shows they read the text to get to the next screen. Then they have to click the correct button to get past the alert. Be sure and move the button around position wise so they don't just click the rightmost button everytime.
I have one relevant anecdote that I have told before...
Our application had a delete button, that performed a permanent delete (like deleting something from your recycle bin). And we popped up a message that stated that this action was irreversible. But we continued to get requests from users to "undelete" items - several requests per month.
We finally changed the pop-up to force the user to key in the word "irreversible", prior to performing the irreversible deletion.
We haven't received a request to undelete since then - which has been several years by now.
PS, before you write back and say that this is a poor user interface, and you should always allow users to undo their actions, the "permanent delete" function was specified by the economic buyer, and it was a non-negotiable item.
If i'm writing a calculator and the user types/clicks 4 / 0 - tell me what behavior is appropriate.
If your calculator is intended to work with floating point numbers, display "Infinity". This represents the limit of 1/x as x approaches 0, as seen in the compactification of the real number line. This brings up what to do with Inf * 0; IEEE has a result for that: "Not a number".
When one of our more, ah, "intellectually challenged" personnel call the help desk, the first thing I have my people do is have the employee do a screen capture and send it to the help desk. Email if it's not the problem, print if it is.
If the employee just plowed through the message without recording it, our SOP is "Reboot. Give us a call when you have a screen capture for us; otherwise we can't troubleshoot your problem."
Possible programming approach: Have the program itself do the screen capture and email. Package the logs with it.
Regards;
The main reason most users don't bother reading error messages is because they aren't used to having messages that are informative. PC LOAD LETTER is an excellent example, but in many cases with products the error messages may even be clear, but they aren't accurate. How many times have we seen a program give an error message about "insufficient memory" or something to that effect. So the user (if they read it) believes that they need a RAM upgrade in their computer. After you research the message, you find out that it really has nothing to do with memory and was in fact some totally unrelated problem. If programmers spent more time creating accurate error messages, maybe people would read them.
Do whatever is possible to make it IMpossible for users to install ANYTHING. Install pop-up blockers. That would be a start. And good luck with taking anything away from the end users, Glynn.
Damping absorbs vibrations. Dampening is caused by moisture.
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.
Except figure out how to upload the log file to the support system.
Whenever I have a problem, and call the IT department in our huge company, I can't get anyone to pay attention to the error message. I say "I got an error message saying xxxx". They say, "uh, yeah, that's great, we are going to re-image your machine".
Brett
Some of my users are either overwhelmed with multiple distractions or uncomfortable with technology or both. In any case, my team is responsible for figuring out what triggered error conditions and getting them fixed regardless of user cooperation or contribution.
When users do not give detailed and accurate information about an error condition and what they were doing prior to the error condition, there are some creative options available.
The CNET.com download site has any number of screen monitoring products (i.e e-Surveiller, The Best Keylogger, Shadow Keylogger, Local Keylogger Pro, etc.) for recording and monitoring PC activity. These products not only record keystrokes, but also provide screenshots and/or video.
For my users, I always let them know before installing such software and let them know that any performance impact will only be until we identify the error conditions and the activities that triggered the error conditions. (We also notified all employees in the employee handbook that we do this and also have the employees re-sign their understanding of this every year.)
By using these tools, we can reduce problem-solving time and associated user frustration.
Live Long and Prosper - Thanks Leonard. You are missed.
It depends on the nature of the application. But I'd start trying to make the application less reliant on error messages to begin with.
Some error messages reflect some external dependency that can't be satisfied. Try to convert some of those error messages to "Please wait while I keep retrying, click here to cancel" messages, which then become "I'm still trying. If you think something's broken, call the helpdesk at ___". Don't interrupt the user with an error message, just try again for them. Bonus points if your retry mechanism can fall back to different systems or systems in different regions.
Some types of error messages don't even need an error message, you just need to change the UI to highlight a mistake the user made. Field validation errors, for instance, should just point out the broken fields and maybe add a blurb of text about what's a legal value there.
Some types of error messages can be worked around, or aren't really important in the grand scheme of things. If the users probably aren't going to care that something didn't work, don't bother them about it. Make the error easily discoverable if they need to investigate why their externally-hosted images didn't appear, but there's no reason this needs to be an error message popping up in their face.
All of these, plus the truly exceptional errors like crashes, should be logged to local disk, and also to a server on the network. It should be possible for you to pull up all of the problems a user is having, when they call you, or even be proactive and notice a lot of people are having the same problems doing X. You could even have monitoring in place that watched for clusters of the same errors, and send out pages to your technicians before users even have a chance to call you.
Imagine this scenario in a restaurant:
Your steak is burned on one side, but cold. There's a big pile of a yellow granular unidentified substance piled on top of it. Your waiter comes along and says, "Cook's oven not functioning correctly and unknown substance spilled on top." OK?
In short, most error messages are crap. The blame lies with LAZY system designers and LAZY developers.
I can't tell you how many times, I see error messages like "Default zone not selected.: OK?" or "Type error on search processing object 23: OK?" Every time I see this crap, I want to bitch slap some lazy son of a bitch and ban all dialogs that only have the "OK" button as a response.
The CORRECT response to the first example above is something like. "Sorry, you need to select a default zone first. Shall I bring up the dialog that allows you do to this?: "Yes", "No", "Cancel"
The CORRECT response to the second example above is to fire the lazy system designer and/or programmer who couldn't be bothered to come up with an intelligent useful response to an error and because of their laziness, wasted thousands of hours of user time, just so they could take an early lunch.
Please do not read this sig. Thank you.
You need a policy along the lines that if you want it fixed, you provide the error message. If people are too dim to copy-paste or make a screenshot then it's time to recycle them for pet food.
But you'll need buy-in from management to get anywhere with that, so good luck. A particular red flag is if you start hearing emotive language like "well if you don't want to help...". - in that case get out while you can, before the whining retards gang up on you.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Has got to be z/OS's IDC3009I message where the combination's of return and reason codes go on for 5165 lines in the message manual.
How do you get users to read error messages? Simple. Put pictures of naked ladies on them. How do you think Michelangelo got the common folk to be interested in looking at "art"? Added bonus: Easy to describe the errors. Like your "puppy error," but more fun. "Hello, tech support? Yeah, I've got the blond chick in the shower... Oh, okay, just check to make sure the network cable's plugged in, got it."
In the DOS version of good old Partition Magic OK button was grayed out until the user typed OK in a text box. This was done in some important dialogs, like one for full format of the partition. Also you may try to set a delay and prohibit to close dialog box till its end.
I trained all of my users to do screenshots when possible, because if they don't, the machine gets re-imaged. It's kind of like a shock collar for a dog.
....opening a popup with naked women in it? Error message in a speech bubble? Should draw the attention of at least 50% of all computer users. :-D
Not sure how you get lusers to read error messages. But the best way to get Admins to RTFM is to disguise the manual as smut. They will read every word trying to find it.
Getting them to follow the instructions they just read is yet another mystery.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Just put a timer on the buttons that won't let them click it for 10 seconds.
It doesn't take 10 seconds to recognize "yeah, this is the same dialog as before"
but ultimately you can't fix stupid.
It's not all stupid (only 99%). Sometimes it's "not well enough informed". Say, in the firefox example. Should I trust "Joe Random Add-On Developer"? Yeah, sure*. Forcing me to spend 10 seconds on a 3-second decision just annoys me.
* No, I shouldn't. But I'm gonna'. And all you people who run ad block plus and what have you, you haven't met with the developers and verified that they have the best intentions about your computer. They could be evil, you know...
Well, speaking through my experience in help desk support, I assume that users do not tell you about the error messages in the screen because they "think" if don't tell you, then you'll "run" to help him... I mean, they think that if they tell you "my computer is doing something weird and there is NO ERROR MESSAGE" you'll prioritize his/her case and go immediately to solve it.
I'm working in another department now, I quit from help desk hahaha... and these guys here do that, they lie to help desk in order to have them solve the problem faster.
hope this helps!
I used to work at an e-commerce company and we added a feature to indicate to our support team if they were looking at information about someone's account & there was an issue. Initially, the information about potential issues was the same font as the rest of the page but it was in bold.
After a week, the manager said no one was paying attention to the errors. Change it to be a bigger font and bright red. So we did. Things were fine for a week. Then the manager came back "people are ignoring the error." These messages were inside h1 HTML tags, bright red, and CSS styled to be huge. 18 or 24 point font on a page where most everything else was 12 point, if I recall correctly. We had did just about everything except for putting it in a BLINK tag. We do have some standards, you know!
The manager came up with what she thought was a good solution: randomly change the color, position and size of the warning messages. We told her no way, just train your people better. I haven't checked back to see what they ended up doing after I stopped working there.
Shorter story that proves the point: I had a family member complain their email wasn't working any more. I went over & told them hit the button to get new email. An error pops up that they have an invalid password. I told them it means that you have the wrong password, call tech support because there's nothing I can do about it.
Let's face it. Most of the desktop users this guy is supporting are not comfortable with computers. They tone out technical jargon and are not going to remember something they can't understand. The other part is that error messages should be understandable and in plain English, and the plain English meaning should be what you want to communicate.
For example, "uninitialized data" just isn't meaningful to most users. Call it "Required input not provided."
On the other hand, "This program has performed an illegal operation and will be shut down" will be misunderstood as "You did something BAD and we're calling the cops to shut you down!" For all my ranting against Microsoft, they did learn from this, probably because of so many people calling for tech support asking if the police were being summoned. Now they say "this program has encountered a problem and needs to close." Much more friendly on the tech support people.
In this spirit, the logos are not a bad idea. However, getting understandable error messages should be an important goal also because the user may be more empowered to figure out what they did wrong if it is caused by them.
LedgerSMB: Open source Accounting/ERP
"Helpdesk? I have a red pegasus error in the error displaying software!"
So you want the application to wait until the user did a bunch of work and *then* tell them they're screwed. Yeah, that won't piss people off.
They stay on the screen, saying blandly, "Error 14"
Back in the '70s and '80s when machines had limited memory and storage, numeric error codes were a concise way of handling exceptions when everybody had a list of those codes (or more often knew them by heart). Trouble is, these have persisted into modern software, and it can be really fucking frustrating when a piece of software spits an error and the deepest, darkest depths of Google cache fail to find a reference list.
And yes, although Microsoft is guilty in this regard, so are a number of OSS developers. A recent occasion I came across this was when setting up a network printer with CUPS. It took me most of an afternoon to accomplish something that should have been trivial, and in fact had been in the previous version of the software.
Basicly I break down users into three groups. I have no sientific facts to back up my claims. Group 1 Power Users smart enough to figure 99% of his or her computer problems and actually read the error messages. This group is maybe 20% of the group. This group typically performs 80% of the work for the organization Group 2 Users can read but are just to darn lazy or too epethetic to try so they just open tickets with the help desk in the hopes that you have time to come to the rescue.. This group comprized 60% of the group This group contributes about 15% of the overall effort to the organization. Group 3 Should not be allowed to have a computer and really should be cut as dead weight but because we are a social welfare state these users just go through life and collect a pay check and provide very little maybe 5%. In a perfect world we would be able to just shoot group 2 and 3. Ronbo
Semper Fi Ronald Ausman USMC Ret
Take a hint from spam and malware writers. Instead of putting up a boring error message, put up big flashing letters that say "YOU ARE THE 1,000,000th user of this system. Click here to claim your prize!!!"
Another option is to make your error boxes "unclickable" like that old prank software that would move the message box every time you moved over the "No" button, so you were forced to click "Yes". Make the "OK" button unclickable for your error messages.
We are the 198 proof..
Just require some feedback from the user. Such as "Please enter any 15 digit prime number to continue:".
10: PRINT "Everything old is new again."
20: GOTO 10
Someone bumps your car and damages it, then drives off. You call the cops and they ask you for the make, color and license plate.
Does that constitute expecting you to catch the criminal yourself?
I don't give a rat's ass how much you're paying for a support contract - it doesn't come bundled with magic, and you only get telepathy on the super gold plus plan.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
"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.""
So, basically, it was "If you want to keep your fat support contract, don't bother trying to improve our ability to support ourselves." Sounds like a stupid answer to me that isn't to their advantage, but, hey, they're paying the bills.
Wasn't that when you had a disk flipped over in the old 5 1/4 inch floppy days on an apple II?
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
Your idea has merit, but you need to extend the idea a little further. Make your error dialogs look like this, and you will get more user participation than you can handle:
--------
INSERT CUTESY PICTURE HERE
A little lost $Animal_Name has wandered onto your farm. It needs help! You can add it to your farm, but you need to tame it first.
To tame it, the magic words are $Magic_Word_1, $Magic_Word_2, and $Magic_Word_3.
When you are ready, click HERE to tame it and add it to your farm!
--------
You just have a simple lookup table for the $Animal_Name and $Magic_Word variables, and you've got all the info you need. Of course, then you need to make some sort of ridiculous farm app, but that could be a further source of monetization! :-)
Make them retype the error message, as with a capcha, those bastards!
Oh, to have a computer that would slap someone when they make a stupid error...
Liberty in your lifetime
It depends on what your goal is.
If your goal is to get the user to remember what the error was when they call you, then yes a memorable image instead of text would be very helpful. If you could make it move, make noise or otherwise attract attention even better. Also if you could make the error box persist for some small period of time -- say 3-5 seconds regardless of button click that would also help.
Most users don't read error messages because the message really isn't aimed at them. Even if they were to read it, they would not be likely to understand its meaning.
I think it is a very good idea.
One of the reasons I'm thinking that people don't look at error messages is that alot of the time they're terrible. You know error 47719 and that's the end of it. (Or worse, the "Error Error" which is what I call it when a program or whatever tells you an error has occured and then nothing else.) So I'd expect alot of people don't look since it's often a waste of time. Then coders turn around and realize nobody gives a shit so they make the error reporting even less useful. (Sometime you run across an app that does a good job of reporting error, that's awesome when it occurs.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Is it plugged in? yes? LIER!
It it turned on? yes? LIER!
Can you see any messeges on the screen? no? LIER!
Why do they lie!??!?
They aren't lying. They literally do not see it.
Your mind is pelted with information every day. Vast, huge, massive swaths of information that make what goes over an OC3 pipe pale in comparison. Your eyes generate a super-hi-Def video stream chock full of useful details about your life and everything around you. Your ears, your sense of smell, all are being monitored 24x7, and don't forget your senses of touch, hunger, and numerous other "metasenses".
There's far more information streaming into your brain than could possibly be processed. So what your mind does is exactly the same thing that your spam filter does at your local ISP: Your mind filters out information that you don't find useful before you are even consciously aware of it!
Studies have shown:
1) People will change lanes into a lane occupied by a motorcycle, even after clearly looking directly at the motorcycle! It's commonplace, as a motorcycle rider myself, I've seen this happen more than once! The reason is that the person isn't looking over to see if there's *anything* there, they're looking to see if a *car* is there. Since my motorcycle isn't a car, the other driver's mind actually filters that fact out before they are consciously aware of it, and to their mind, I'm simply not there. (thanks, brain!)
2) In simulation, highly skilled, trained pilots were instructed to land the "airplane" on a runway littered with stuff. Garbage trucks, buses, big, huge things that were hard to miss. In only a very small number of cases did the otherwise highly skilled, demonstrated, and experienced pilots ever see the junk on the runway, even though they could be seen to be LOOKING DIRECTLY AT THE RUNWAY. Why? Because their minds were only looking for information that was already known to be useful, and filtering out the rest.
3) Think back to when you learned to drive! Everything was bewildering, you were overwhelmed by details too numerous to process easily. Signs and lines seemed to jump out of nowhere. But somehow, it became easier and easier as your mind learned what information was actually needed, and began filtering out the rest. Your mind is trained to look for the red octagonal stop sign, and the street sign that, within your state, looks very consistent. But think about when you experience something new. For example, in my area, they started installing roundabouts where we never had them before. They were a bit disconcerting and bewildering the first few times, and I am a very safe, effective driver. (20 years, no accidents, knock on wood!) My lower brain hadn't learned to filter out all the details of the roundabout, so I had to slow down and process EVERYTHING until I had a chance to train it.
They aren't lying. They literally cannot see what's clearly and demonstrably in front of them. The lower parts of your brain filter out detail and deliver highly processed, compressed information to your cerebrum (the part that's self-conscious) in order to save expensive processing time. Be gentle, be understanding, and accept that the reason why they are calling you is because they need you to see what's wrong and fix it! Accept your pay scale accordingly, and suck it up, because that's human nature, it will always be human nature, and there's not a damned thing you or anybody else can do about it!
However, one thing I've found is that if an error or confirmation is very important, you put red lettering and make somebody type a word, such as "I will pay you $50", or "I'm ready to pay you $200 if I want to delete this" or something before proceeding. Make sure it's different for each situation! I used to just make end users type "confirm" or "accept" but they got used to that.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
If the error popups were not so frequent and identical, people might actually care when one shows up. This of course means having stuff that breaks less...
When an error message pops up, they have 10 seconds to retype it into a dialog box, or they get 25kV in the arse.
After they retype it, they get 10kV anyway, just for being stupid.
There is nothing you can do, you could be standing next to them telling them exactly what to click on while guiding their hand and they still would be unable to follow any directions.
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.
Users are more likely to remember data that they interact with rather than receive passively.
1) When an error occurs, the error code is given by the first word on three different pages of the user manual which the user must look up and type them in. Now they're reading the manual! Code wheels from old Apple II games and Pantone color swatch books could also be used. To encourage users to write errors down, the process could be repeated at random intervals throughout the day.
2) Make up bingo cards filled with randomly selected error messages. Winning cards can be verified against the logs. Encourage victory shouts.
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.
Sounds like a variant of the dancing pigs problem
They will completely ignore every error message and try to find a way to get what they want.
I try to keep the error messages as simple as possible, and then have the system email out an error message.
If your company isn't gigantic it can work well, then when you get a call just check the email to see what the full message was.
FTS:
Unfortunately, haptic and olfactory feedback aren't readily available.
Hadda crowbar that in there, dintcha?
Yep, I get this all the time
Even if I'm sat there next to them and ask them what the window they just closed was I just get "I don't know, it just always appears when I do that".
If I repeat the error and point out that it says (eg.) "printer isn't switched on" they'll sheepishly turn on the printer and apologize for wasting my time but will they learn anything and read the next message that appears?? Dream on....
I dunno, colored puppies sounds like a good idea: "I saw a funny red puppy waving at me" but I'm jaded and don't have a lot of faith in end users.
No sig today...
Just add a "google it!" button. That's what I always do with errors. I usually have to type them, though. For some reason you can never, EVER copy and paste from an error box, and that's so very annoying, especially when you have a nice long generic one with 2 hex codes. ARGH
I think this is the same problem that afflicts tech support staff who don't read any log files or error messages that you submit when opening a ticket.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
The human brain is excellent at filtering information. I think advertising has trained us to turn our brains off to certain things, and we are oblivious to it.
I've seen this phenomenon in myself. Some times when surfing the web with someone else looking over my shoulder, and that person mentions something that they see on the page, and I have to ask them where it is. Often times it is an advertisement, and I read so much online that I just blocked it out. Once I was reading an article that referred to an illustration, and I was frustrated because I couldn't find the illustration. I figured something was wrong on the page. So I decided to scan the page bottom-to-top, right-to-left (the opposite of natural reading order) and the illustration was there! Right where it was supposed to be! Right under an advertisement that I was ignoring.
Someone earlier posted an example with an error message bouncing around the screen. I totally understand why the user missed it -- because many monitors display pointless messages like "No signal" instead of going to sleep.
People are inundated with useless, inappropriate information. As a result, our brains filter out information we don't understand.
Seriously. There's no point to expecting or attempting to educate, bribe, trick, or otherwise coerce users into remembering much less reading error messages. Save everything to a log file. Make it a running log file, not a "last error" log file, so when you do remote in after they've determined it's finally time to call you, you can see all the problems they've had recently and can fix their current issue, as well as all the other little problems they've been having and have failed to mention to you.
If your circumstances support it, have the errors automatically emailed to you, with as much relevant information as possible.
I like the "puppy error" idea though... sometimes you get a user that's not technical but is actually willing to be a part of the solution instead of wallowing in the problem, and you may be able to teach them a few tricks (haha) based on memorable icons. Like "when you see a red stop sign, you need to press the switch on the power strip and then press it again", or "the atomic cloud means you need to call me right away" or "when you see the briefcase you need to call your manager to come take a look" etc.
I work for the Department of Redundancy Department.
I have occasionally gotten my users to call me before clearing out the error message on the screen. But these day, I don't bother, because most of my users literally cannot read the error message off the screen while on the phone with me. Because "that's computer stuff, and I don't know anything about that."
Lord, how I wish I were exaggerating.
It's that simple. A core percentage of your users simply refuse to read what is in front of them. They skim, they look for only the things they expect, and absolutely nothing else. They're basically running the visual equivalent of an Expect script, responding to a prompt in a way which may or may not be appropriate.
I'll give an example. I had a password reset program which, of course, required an email address specific to our users. However, there was a possibility that users would use a different email address that wasn't valid. No, I had no access to that list of addresses to match and verify, that was simply out. Instructions were provided on the page as to which kinds of email addresses were allowed, and which were not. Of course users ignore instructions, as we all know. They see "email address" and they begin typing. Instructions could be on the top, on the bottom, or right before that row -- it didn't matter. This happened about 45% of the time. Okay, half of our users read directions, yay.
So I added something which would detect the wrong type, I could at least do that much, and tell them, via a nice, big Javascript window you had to click to make go away, that they used the wrong kind, and here is what the right kind looked like. What kind of drastic reduction in errors did I see?
95%? No.
80%? Such an optimist!
50%? Ha!
Only thirty percent of my users, presented with a HEY IT LOOKS LIKE YOU ARE USING THE WRONG EMAIL ADDRESS HERE IS WHAT IT SHOULD LOOK LIKE kind of prompt, right in their face, changed their behavior. It was big! It was colored! It covered the form until you made it go away. The rest kept doing it the wrong way. Sometimes several times in a row (I watched the logs). I could see them return a month later to reset their password, which they had forgotten, and make the same mistakes. They will not remember more than a few minutes ago, they will not read instructions, and they will not respond to error messages. They will not remember error messages they see.
Once you accept the existence of this core group and realize that you can do nothing to help them besides providing hopefully appropriate environmental prompts, the rest explains itself. Do not waste time trying to solve the problems with this group. If you carefully watch their behavior on other systems, they experience identical problems wherever they may go. They exist in a perpetual struggle with computers, thrashing like a goldfish thrashing in a corner of an aquarium. Feel sorry for them if you must, design around them if you can, but you cannot change their behavior for them, only provide a padded environment where they cannot hurt themselves too much and can hopefully mouth soft objects with rounded corners.
Sounds like an idea.
Make the error message do various things depending on the severity. Small error, make annoying noise. Big error, shuts down program. Huge error, force reboot.
Causing Chaos Everywhere,
Nik J.
The strange world of a loner, in a populous city, drowning in society
In the messagebox, you are able to associate an icon picture to the message, and also in .net that has been drastically been advanced.
I agree that a puppy picture for some users would signal a more recognizable error message, however, going through the whole catalogue of the animal kingdom, I do not find enough species to cover all possible errors I could propagate in a software app.
I your end users are running windows 7 check out psr.exe. I records what they do with screen shots each step of the way. Now if it could only tell me what PEBKAC is?
The best way that I've ever found to support users with error messages is to make sure that I can be aware of them as soon as they happen. This was easy to implement in many corporate applications that I've built, as I simply built an error management object (in VB6...I'm old) that would log all error messages in one of three ways depending on the capability that the system was left in when the error happened.
The first level was logging to a database table that was used by the application. I had a separate application that would poll that table and alert me whenever an error record was added. It blew the socks off users when I would call them within moments of the error telling them that I was working the issue. (BIG win for our IT department). In cases where the database connection or capability was gone the error management object would send me an email with all of the appropriate information. The last resort was creating a log file entry on the user's local drive.
In all but the third level of managing errors I was empowered to be aware and proactive in my response to users and I didn't have to resort to the 'puppy error message'.
Your printing example ends up doing one of two possible results:
1) By attempting to detect at launch, the program hangs for a few seconds every time, even if you never use the printing segment. See Adobe Photoshop hanging for 10 seconds whenever your default printer is a network printer that's offline.
2) By giving an error after the job is completed, you risk people thinking the error does not apply to their task (they've completed all their memorized steps, after all) or that it won't matter anyways. Most will just end up clicking through it because the error message still gets in the way of their next task: closing the software.
No, the problem's in the mindset. Do you see people ignoring "fuel low" indicators a lot? Do you see people gobbling all their pills at once despite the prescription saying it should be one a day? If people are too stupid to follow basic indications, then they should be stuck in their stupidity until their learn to work properly. In other words, screw them. Car manufacturers won't start blackening the windshield and reading out loud "fuel low" every time, so I don't see why computer software errors would have to be so insanely inventive to get their users' attention. Plus, it would be annoying for those who DO read the errors.
Now, that does not excuse errors like "0xC0003F: Fault in core area."
That is indeed a tempting thought. Maybe get one of these.
Add foobies to your error messages...
You are solving a wrong problem and about to confuse your poor users even more with with strange error message icons.
Instead of trying to force users to read incomprehensible techno bable, you should be designing your program so that it doesn't need to show error messages.
At the very least do not use simple modal dialogs and error messages that only describe the problem. Use error messages that do not prevent doing anything but disposing the message (i.e., modal dialog) and always describe a SOLUTION to the problem.
E.g., if the error is that a user tries to submit a form with a missing required field, you could just move focus back to where a value is missing, put a thick red border with a border title "REQUIRED FIELD" around the widget in question.
I think users would like computers to ignore error conditions until they're done with all input related to performing an operation, for starters.
Absolutely, positively wrong. I don't mean that caustically - I see your idea, and consider it good in theory, but I can tell you from first-hand experience exactly what this leads to in practice:
"Hey, you the jackass that wrote this thing? Yeah, I just spent an hour putting in a quote for a customer standing in front of me, and now it tells me it can't connect to your server?"
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.
Continuing with the previous example, the error message in question explicitly tells the user that it will just save a local copy (which they can print and otherwise work with as normal) until it can reconnect to the server. But no one actually reads that far.
At least if the program tells them it can't get to the server (and will save locally instead) right up front, you don't have to pretend to feel bad that they wasted an hour.
And yes, I've just described a real example (complete with me answering the phone to hear "hey jackass!").
The user should see nothing, or as little as possible. If your program can adapt to the error without the users input, it should (as an example, using relative paths to ensure that if your program is moved it doesn't break).
If it needs further input, it should ask for it directly (this file seems to have moved--where is it now?)
If it's an unexpected exception, always append as much of your state as you can to a log and restart. Never clear this log. If you cannot start, offer the user the ability to send you his log in a Very Short Dialog. Make it trivial to send, a single button-press if possible.
Don't expect them to read a dialog and implement a solution for you. If you know enough about what's going on in the dialog to have them fix it, fix it for them. If you don't, don't have them guess, have them contact you (assuming it's internal company support).
Whenever you solve a problem, be sure to incorporate it back into your program so you don't see that problem again.
One way I've seen, which I thought was particularly good, gave an error message. In order to move past the error screen the person had to call the support company for a passcode to close it. This way, the support company had a full history of 'incidents', could ensure the end user didn't proceed after a meltdown, and knew what error code was being given at what time.
Part of what you're running into is the distinction between packers and mappers (Google 'The Programmer's Stone' for more info). Packers learn by collecting little packets of information, while mappers learn by making mental maps of information. I don't agree with all the directions the originator of the concept has taken it, but I've found it to be a useful distinction. IT types (especially programmers) tend to be mappers, while the user is typically a packer. Businesses tend to run on a Packer mindset. Packers are typically much more comfortable with memorized procedures than with having to think about unfamiliar information(as you noted).
Instead of trying to tweak error messages to make them memorable, your best bet might be to get management to promulgate a procedure to be followed when the user contacts support about an unfamiliar error message. Make it include grabbing a screen shot of the error message, or writing the error message down. Try to make it short, but sufficient to capture the typical information that you need to diagnose a problem. Since they're good at memorizing a set of steps to follow, give them a memorizable set of steps to follow when they encounter a problem. This might be more successful than trying to push them into a mode of operation they're not good at.
Well, it's more the case of small error - don't allow user to continue until error is fixed, medium error - don't allow user to continue until error is fixed, huge error - don't allow user to continue until error is fixed.
I just realized that what made me soo good with computer.. you know the kind of guy that get called by his whole familly, and even the families of friends ... is that I know how to read an error message....
Make them correctly solve a simple math problem in order to enable the "OK" button. My favorite is the captcha from the Moscow institute of physics and technology; http://lib.mipt.ru/?spage=reg_user
You have to determine the total resistance of a very simple resistor network (a wheatstone bridge). Sounds easy, right? Better dust off your knowlege of Kirchoff's law.
Several solutions can be found here; http://yaroslavvb.blogspot.com/2008/01/russian-captcha-revisited.html
Ian Ameline
10 years ago, I ran a few Linux print servers in an otherwise OS/2-only envirunment (yep, that was the banking world 10 years ago, IBM all the way). As I couldn't access SSH from the OS/2 machines (they were too locked down to install additional software), and didn't always have access to a Linux box with a SSH client on it, I had resorted to use different beeps for relaying status messages. The server would go beep-Beep-BEEEEP (melodic ascending beeps like C-E-G) for every successful job and meep-meep for every failed one. So when folks called in, all I had to do was ask them to hold the phone against the server while someone else triggered the print job again. The specific issues we had were reproducable, i.e. if a job failed with a meep-meep the first time, it would fail on all subsequent tries as well, and it had exactly one cause, so we knew where to look. If it would play the melody, but still wouldn't print, we knew it was something like paper jam, paper empty, etc.
Oh here I have to say something... Deadlines... you dont know how fancy and neat every program would be if we had the time we need to finish these up.. but management dont care... they want ti on the shelf yesterday... not when its ready!
I do not make code errors, should the impossible surface then:
On Windows> pop some reg's in HAL divide them with zero reg's and tada a blues screen will display nicely in front of the user it's a very clean and nice way to display error messages on Windows. The user will feel home..
On Linux> impostor a module, call a stack send some nulls, voids whatever the core dumb's. All Linux users reads there daily core dumb's. So this is a fine place for error messages.
On Mac> Show the beach ball in an infinite loop. Mac users don't know how to read error messages.
In order to form an immaculate member of a flock of sheep one must, above all, be a sheep.
If the goal is simply to have users remember the error message, there is some science on learnability and memorability.
See http://ed-informatics.org/2009/12/28/computers-in-the-ed-1/
First of all, if you read about evolutionary psychology, say, the works of Merlin Donald, you will realize that people are designed to remember stories and not numbers, so you could have each error message tell a different story.
See http://ed-informatics.org/2010/01/07/computers-in-the-ed-5/
Or, you could reference the work of Colin Ware, and design error messages that have icons that use preattentive attributes.
See http://ed-informatics.org/2010/01/25/computers-in-the-ed-8
and
http://ed-informatics.org/2010/02/11/computers-in-the-ed-9/
While this tends to answer what you asked, which is to help users remember error messages, some of the other proposed solutions already posted may actually help solve your problem better (debug logs, etc.).
I very much fancy the idea with different icons for different error messages. It does improve the recognition of 'something special going on', as I can say from some pretty small samples where I could test that.
Two downsides remained:
a) Users DID (as they reported later) recognize a special message ('with that picture of a puppy') being presented. But they did not get the message at all (reading - understanding - correcting the problem wasn't improved)
b) The more different icons got involved, the more people just got confused. They just thought of the application as 'a little bit' funny
What got me better results is incorporating the error message into the actual working ui. Think of red boxes around fields that are not properly filled. Say if they break something while entering some customer data, let the whole customer data form turn angry-red or mildly-orange - or maybe just parts.
Highlight broken parts where they should go and fix something. They would only do it, if it got some value for them. If they are responsible for a customer telephone number to be correct, they'd care about a red phone number field. Otherwise they wouldn't.
If they want to go online with their wi-fi, they will care about a red wi-fi icon.
So my advice: Don't distract with (unrelated) icons, pictures or error messages as a whole. You already got their attention on the subject that matters to them. Tell them in an easy and intuitive pattern (traffic light color) if that's ok or not.
Always remember: They care about their work, not about the inner feelings of your app!
1) The fact that your software produces errors means that your software has a problem you need to fix. I distinguish between resource failures (file not found) and full on errors (attempted to access null object, for instance). Files not being found is normally outside your control. Dereferencing a null pointer is completely your fault. The fact that the user doesn't understand your message is not the user's fault. The user does not, nor should, give a shit what a "null pointer" is. By the time the error is displayed on the screen, you have already failed.
2) Depending on users to accurately report complex error conditions is an exercise in futility. Humans do not work that way. Assuming that they do, then accusing them of being stupid when they don't, makes you the moron. If you need to know error details, log them, and give the user a way to send you the report -- even better, send the report automatically.
Most error messages can be dealt with programatically on the developer's side. If a file isn't found, maybe the program should try to find it. If there's a required text box, indicate so on the text box instead of alerting the user when they click the okay button, maybe even making the okay button disabled until text has been entered and (this is important) including a tool tip on the okay button indicating why it is disabled. I've clicked past many dialog boxes without reading them and wished that I could 'undo' or 'go back' to see what they said again. Try to replace the dialog with a better method of informing the user.
I work with legacy systems written in Pro/5 BASIC. Yes, pain. But... if a user calls you up and says "Error 11 on line 31210" you can know pretty quickly what the problem was. Because all our programs are structured in such a way that we know roughly what 31210 is doing.
I don't really handle the BASIC stuff (my part is in Perl and Javascript), but I've heard my associate dictating a new line of code over the phone. Basically a one-line patch, improvised on the spot.
I was very impressed.
The user did not ask for a limit of division when the divisor approaches 0
People don't always get what they ask for. When someone tries to calculate something that is defined only as a limit, he gets the closest approximation: an object, which is not a real number, that represents this limit. The user can still do useful things with the limit, such as divide real numbers by it to produce 0. If the error condition is not fatal, represent it as not fatal.
The fact that IEEE might define a state for when a cpu tries to calculate it (NaN - which btw really is NOT a number), does not change the cold fact that doing so is an error and has to result in an error message.
It's a distinct object that represents an error condition, and such an object doesn't trigger the reflex to click OK because it isn't communicated as an alert box. Nor does a misspelled word in a word processor result in an alert box; it just results in a red underline.
I read a book some time ago in which most people were 'iconerate' as opposed to being fully literate. It meant that they could recognize specific icons and symbols and understand them, but that user interfaces has become so sophisticated that understanding beyond that wasn't needed.
While this isn't exactly the idea you've described, there is more than a passing similarity. Users fly through messages and menus quickly because they know what to expect. They remember that blue thing with the W on it starts word, and the green one with the X starts excel. The problem with using this kind of system with error messages is that unless you're using it to capture very common errors, the users will never get to the point where they can immediately associate the icon with a specific problem. And if the users see the error often enough to achieve that level of understanding then they probably know how to deal with it themselves. Which, come to think of it, may not be bad if they could come to associate an icon with specific recovery steps. but it's not going to help you with the complex issues which is where the helpdesk really needs it.
The puppy error idea may work in the short term, but soon I think that the novelty will wear off and they'll all blur into "some cartooish icon" in the user's mind.
I had a longer comment, but it got lost when I got the screaming yellow unicorn error.
FTFS
FTFW
When you're afraid to download music illegally in your own home, then the terrorists have won!
People have been fired here in the past for trying just that.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
I developed one some years ago. After noticing that the users of the legacy app didn't, or couldn't[1] read the text error messages, I used a series of background colors for the new web app that indicated the general type of error and what should be done about it. The application itself was somewhat checklist based in that it would step the operator through the requisite procedures needed to remedy a situation. The colors, and some appropriate iconography[2] would indicate whether the operator was stepping through the normal operating path or handing an exception.
[1] The original text-based app would present a cryptic error message to the operator along with our on-call pager number. All that was necessary was that the operator contact us and read the message back. Most fixes could then be handled remotely in a few minutes. One night, when I was on call, I received a message from a shop floor manager to the effect that the system was down and I needed to drive down and fix it. I asked him to read me the message on the screen with the idea that it might be something I could fix on line (sitting in my PJs) in a few minutes. At this point, he became quite irate, insisting that there was no message, other than the pager number and for me to get my ass down to the factory. An hour or so later (with production stopped), when I showed up, there was the message (fixable on line in about 5 minutes). But no manager in sight. When I asked one of the employees what the problem was with his boss reading the message to me over the phone, he informed me that this guy was functionally illiterate. He could figure out the pager number to call me, but not read the text.
[2]All error pages included an animated graphic of a character sitting at a screen/keyboard, repeatedly bashing his head on the keyboard. It became obvious to (even untrained) users that somehow, something was f*cked up and they were now in some sort of exception handling mode.
Have gnu, will travel.
Another echo: differences dealing with family tech support. Age is not the issue.
One elder was a stereo freak in the old days, and very Rolodex/to-do-list oriented. When he calls with a problem, he tells me what happened reasonably well, reads what is on the screen, and can follow directions precisely (as long as I give them slowly and clearly). Another elder, formerly a professional artist, when told "Click where it says FOO", denied that it said FOO anywhere on the screen, then when directed there a column at a time skipped some of the column headers, then clicked on something else because it "sounded similar".
People simply don't see what doesn't fit their worldview.
Actually, haven't we essentially solved this in the web world now? Nobody uses javascript:alert("ERROR: 45322626") anymore. Now, we take the user to where the problem can be fixed, or provide them a link directly to it. If it's a form validation problem, the fields with errors can light up and highlight the problem.
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!??!?
Probably because they are trying to sleep (or may actually have achieved said state which would explain why they are not reading the error messages) but that's what you would expect if you are talking to liers. Of course you might also be talking to liars but that would be different.
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.
Possibly one of the most annoying error messages I see are the ones that end "Please contact your system administrator."... Which is great when I *am* the system administrator and I don't have a clue what's broken because, rather than give me enough detail to figure it out, it just told me to go talk to myself...
http://blog.nexusuk.org
A little off topic, but I try to include the EXACT text of error messages for the hard working tech support dweebs. I find it frustrating when the text not only cannot be captured by normal means, but often not even by my Scraper tool. Help us help you.
Implement a random number generator and design several styles of error messages with the buttons moved around. 10 buttons that say "this button doesn't do anything" "this button rapes your computer" and "this button is made of clowns" which are distributed in a random order should help.
This is what annoys me most about modeling hardware in VHDL, verilog, etc. versus programming software.
With software, the goal is to fix any warning messages (even with -Wall), to the point that many programming standards require -Werror as well. The warnings are generally important to follow and are generally heeded.
With hardware, synthesizing a design produces hundreds of warnings even with simple designs -- many of which warn about common, intended behavior. Maybe I just used crappy tools? Either way, the warnings were ignored simply because they didn't seem to be important.
The lesson: don't overload the user with warnings, but use them selectively and usefully.
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.
I think you overestimate the difference between programmers and users.
I remember a curious thing when Acorn first launched their C compiler (Norcroft C) for the Archimedes computer. It was far more sophisticated than most C compilers then available, and was very good at spotting mistakes in the code and warning about them. Compared to the contemporary Microsoft C compiler it was streets ahead.
The odd thing though was the number of times I saw this reported as a defect in the Acorn compiler. "Microsoft C can compile this code without difficulty but this new compiler had 128 errors." was a typical comment. The fact that the errors were in the source code and the Acorn compiler was actually doing a much *better* job of diagnosing them was beyond the comprehension of most of the reviewers.
Part of what you're running into is the distinction between packers and mappers (Google 'The Programmer's Stone' for more info). Packers learn by collecting little packets of information, while mappers learn by making mental maps of information. I don't agree with all the directions the originator of the concept has taken it, but I've found it to be a useful distinction. IT types (especially programmers) tend to be mappers, while the user is typically a packer. Businesses tend to run on a Packer mindset. Packers are typically much more comfortable with memorized procedures than with having to think about unfamiliar information(as you noted).
Instead of trying to tweak error messages to make them memorable, your best bet might be to get management to promulgate a procedure to be followed when the user contacts support about an unfamiliar error message. Make it include grabbing a screen shot of the error message, or writing the error message down. Try to make it short, but sufficient to capture the typical information that you need to diagnose a problem. Since they're good at memorizing a set of steps to follow, give them a memorizable set of steps to follow when they encounter a problem. This might be more successful than trying to push them into a mode of operation they're not good at.
I hate it when someone calls their computer a 'cpu'. A CPU!!! That's like calling your car an engine.
Yes, porn is the answer. Users will pay attention to error messages if there are tits and ass in them, or bait n tackle for the ladies.
Steve's Computer Service, Hobbs, NM
I have a lot of respect for computer users who get thrown in with software that sports poorly written error messages and excessive numbers of confirmation-required dialogs, forcing them to learn to just "click past" to get their work done. I respect these people when they understand to call tech support and follow directions as they are clearly provided.
I have no respect for computer users who refuse to follow clearly provided directions and then blame tech support. True story:
Me: Okay, in this command prompt we opened up I need you to type "ipconfig", spelled like "India", "Papa", "Charlie"... then hit "Enter" on the keyboard.
Him: Okay, I typed that in but it just says "not recognized as a valid internal or external command"
Me: Can you read back to me what you typed in before hitting "Enter"?
Him, Angry: I don't get it, I typed "I" then a space, and then "Configure" just like you told me to!
Or...
Me: Okay, in the lower-left hand pane of the window there is a Log Pane that shows the error message I need to assist you. What does it say?
Him: I don't know what you're talking about, there's no error in the lower-right hand part of the screen!
Me: No sir, I need you to look in the lower-left hand part of the screen - what error does it say?
Him: I'm telling you, there's no message, it just won't connect!
Me: Okay, in that case can you just read off the last line of text in the lower-left hand corner of the screen?
Him: It says "Error, could not open SFTP connection on port 22, connection timed out..."
There are shitty tech support people out there who give vague directions and then get pissed at their users because they can't magically extrapolate details or directions. I despise these people because they give decent support techs a bad name. However, I submit we'd have a lot fewer pissed off/burnt out support techs if more computer users were able to follow basic directions.
The question was also asked on stackoverflow: http://stackoverflow.com/questions/2356698/how-to-get-users-to-read-error-messages with some interesting comments over there.
Most people have no clue what most error messages say to them, so they can't possibly remember what they say. Making sure error messages say something a regular person can understand will make it more likely they will read, and remember the messages. It's just like asking someone to remember names in their mother tongue or a completely different language: it's way easier for people to remember names from their own language.
He clearly thought I was an imbercile
Yesterday I couldn't even spell "imbecile" - now I are one.
True. And while it's irritating to search through a long form to find all the fields that are mandatory it does seem to be pretty robust at preventing people from clicking through without thinking.
Developers need to start making it so error messages don't go away until you reply to an question asking what caused the error to ensure they read it. If they fail at that then they should stick to pen and paper.
From my experience, users tend to ignore what the consider to be "normal" error messages. Unless something strange and abnormal comes up, they generally will ignore the message.
Case in point- while managing a school computer lab, we decided to have some fun after listening to an all night marathon of Monty Python CD's containing, amongst others, the "cheese" sketch. We had located the command codes to send signals to the network attached HP printer, allowing us to change the default display message on the printer. Nobody noticed that the printer was out of paper, when it really was, but 5 people within 10 minutes noticed that the printer was "Out of Cheese" when there was really no problem with it.
Put any of the standard error codes on the panel, and nothing is noticed. Tell a user something unbelievable and weird, and they'll pay attention to it.
Of course the puzzled look that users will give you when you tell them that the printer works much better without cheese is absolutely priceless too.
Right. So Edna, the sweet octogenarian who volunteered at the local library, calls us because the Internets would stop moving at that branch. Do you really think any of us cared what she thought of us, just so long as we were polite and the problem was resolved?
Anyone smart enough to know that it was a three-pronged plug and call us on it would get an explanation as to why we did it. The one time I know of that it happened, the guy had a good laugh over it.
File, Open Location, type it. Press Enter.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
HP had recently made a change to their nework removing the browser ID string when employees were surfing the net.
okay, please tell me why did you not check the actual data the client was sending to your servers?
The instructions on the website I support are spelled out in sequential steps:
1. Enter info
2. Click button A
3. Repeat 1-2 as needed
4. Click button B
Or when given a page of several items to fill out, why oh why do they always start at the bottom and wonder why it didn't work?
You never expect irony, do you?
Want to be a professional wrestler? Visit www.iyfwrestling.com
@iyfwrestling
"they'll sheepishly turn on the printer and apologize for wasting my time"
That symptom reflects the major part of the problem. Somehow, your interaction style leaves the impression that the user is in some undeserving class, and that it's the user's fault for being there. That does not provide the user with encouragement to understand or work with the system.
The mammalian body plan is full of discoverable interfaces which encourage discovery through interaction. Humans are wired to experiment to discover and understand how the works around them. Small children put things in/on/around other things (often dangerously) before the grups tell them that doing so is inappropriate. Geeks punt around with config files and get it wrong all day, without having to apologise to the kit.
The moment that the IT support overlord becomes anything other than a partner in discovery is the moment that users stop learning.
As a first step to improving support, I would suggest never touching any deskside kit and instead teach the users how and why to perform the steps required to resolve the issue (as a support person, you already know how to do those tasks, and are not paid for performing the user's job function). I've found that telling the story of fixing the issue (what do you want to do? what do you see around you? what might that do? how might that help you?) without being condescending, and having the user act out and narrate their actions, takes around 10-15% more time per incident, but they, and their cube neighbors, will become self-supporting on the issue (and on related issues) because they've learned tactilely, visually, and aurally, what they are doing to interact with a particular sub-system. Leaving the highly critical adult mode of thought for a simpler juvenile construction of mutual discovery is quite literally childish, but its effective /because/ its closer to our default way of thinking. After a few visits, your users will have discovered and internalized your problem solving pattern, and *gazp*, will do it from start to finish on their own, or with Google, because that's faster than getting ahold of support. /formally left support five years ago because everyone in my group became self sufficient in their software, except for the once in a decade circumstances (or when we've broken something in infrastructure) where Google doesn't help, so we all have to learn together
There are 1.1... kinds of people.
The blame lies with LAZY system designers and LAZY developers.
Since we're spreading blame, then don't forget the lazy QA department for not testing that, and the lazy BA for not writing sufficient specs, or the data architect who thinks that a CustomerID should only be an INT.
I believe that the root of these issues arises from poor specs that the developer and QA consume to produce code / unit tests that ultimately fail in the end product. I've worked for many companies throughout my career and almost every time this issue occurs it can be pointed to the BA producing the original spec. Most times the BA is over worked / inexperienced and management isn't interested in spending more time on the front of projects to get things done right, or the end users don't want to invest time in working with the BA to get things right. I've seen it all.
Lots of blame to go around, just don't pile it on the developers.
Why is this modded "Funny"? This is exactly right no matter how much we may not like it, although I would go as far as to say it is on a different topic.
TFA is referring more to internal users relaying to an internal team who has to fix internal problems. Once you cross the barrier to the outside of the organization to someone who is paying you (usually a very large sum of money) then "Tech Support/IT" transforms into "Customer Service". Customer Service means you need to do whatever you can to fix their problem while keeping them happy and interested in doing possibly more business with you. Frustrating? Yes. Essential to stay in business? Equally if not more Yes.
We have had this problem in the past. We implemented a BSOD style of system that would literally consume the entire space of the application being run to notify them of errors. No possible way they could miss it, they are not allowed to continue without restarting the application. In addition to the error message we would log basically a full stack trace to a central logging database along with a time stamp, user id, application name, etc. So a use reporting an issue would need only to read a quick id that showed on the error message and we could look it up in the database without having to pester the user for more information. This process seems to work well, and I think they key to get around the task asfixiation thing is to simply not allow them to continue with their session if it is a process breaking errors. For the most part, all other non-ciritical errors that arent affecting data or process are logged silently.
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.
Yikes!!! That sounds all warm and fuzzy, but the first thing that came to my mind was, "Great...the computer detected way back at step one that it can't do anything with the data I am about to enter because my network card failed, so the data won't be stored (no network drive) and it won't be submitted (can't reach the database server). However, it's going to wait until I've taken half an hour to enter everything and *THEN* tell me that I was wasting my time."
Ideally, you could write the data to local storage until it could be submitted, but I've seen web apps do exactly what I described above.
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
Your restaurant performed an illegal operation and will be shut down. (Health department officials on their way....)
LedgerSMB: Open source Accounting/ERP
The problem seems to be the boxes that you click away. Everyone gets a million of those boxes every day, noone reads them and they are clicked away as fast as possible because you're busy and don't have time to read silly things.
So, maybe:
1) there should only be boxes that are important
or
2) the actually important messages should appear elsewhere, for instance on a part of the screen that stays there and doesn't have to be clicked away
The second solution would actually solve the tech support problem. "Read to me the red text in the bottom right of the screen", would be much easier to answer than "what was in one of the million boxes you clicked away earlier today that was actually important".
What business are you in? That's right. SHIPPING SOFTWARE. You do not develop software. You do not write code. All of that is completely immaterial. It is simply a means to do what you are in the business of. The single most important thing that you do is ship software. You WILL ship cringeworthy code. You WILL ship unfinished code. You should darned well accept that. The "When it's ready" is a total cop out. Virtually NOBODY has that luxury of shipping "when it's ready" code. The demands of schedule and finance will dictate when you can ship, not any esoteric nonsense about "when it's ready". If you run out of money developing the software, then who cares if you're holding on to this notion of not shipping when it's ready? Nobody. If code is developed, and that code is scrapped on a shelf, was it ever written?
You can't blame management for your inability to communicate. People sit down and blame management continually about every little detail about "I don't care, ship it!". Remember, that's because what you do is SHIP CODE. Management wants that stuff on the shelf yesterday because you didn't convince them that it wasn't possible. You can say that you did, and that stupid management ignored you, but the reality is that you're just plain wrong.
There HAS to be a reason why there are plenty of successful software applications out there that shipped "unfinished". BTW, how you handle the second part of shipping code (ie what you do with software patches) is where you can redeem yourself.
I don't bother asking users to describe anything any more. I just remote in with UltraVNC and have a look myself.
It gripped her hand gently. 'Regret is for humans,' it said.
Include cussing or other language that is likely to get the user's attention.
"Your network connection is fucked." Easy to understand, and will grab your users' attention.
:(){
Damned right it is! No user: no problems.
Sent from my ASR33 using ASCII
Maybe it was a "percentage of browsers visited this webpage" component.
Also, it's easy to bitch about such things in hindsight. It's also easy to _imagine_ getting permission to send log files automagically to the supplier, rather than _actually_ getting permission.
The reason user's don't read the error messages is largely because, they don't mean anything to anyone but the person who wrote the application or environment. I have been a software developer for over 10 years, and I have difficulty understanding half the error messages I read on a daily basis. Developers, majoritively, lack the understanding that the people who will see their error messages the most, have no idea what 'data' or 'uninitialized' even mean. Even if they do know that basic stuff, that doesn't mean to say they know how it relates to the specific application and what has gone wrong. They will never remember what it said. If you speak english as your only language and you read a sign containing 10 or 20 words in arabic.... are you going to remember what it said half an hour or a day later when you speak with your support guy ? I doubt it. People ignore and fear what they don't understand. Make useful error messages, and people will most likely not only remember what went wrong, they may know how to fix it themselves. ;)
I like the IDE (Eclipse, Visual Studio...) way: - group all errors into a list - double-click on a error takes user to the screen/field that causes the error - fields causing errors are highlighted - when possible, a "autofix" icon next to the error can be clicked to see a list of suggested fixes. Clicking on a suggestion applies the fix (similar to Resharper) The missing part to make this a realistic option would be frameworks that make this easy to implement for "business applications"
So, which came first?
The farm.
Since you're basically operating blindly, you should have said:
Open your web browser. Hold down the Alt key. Hold down the D key. Release both the Alt key and the D key. Now type I N T R A N E T and then hit enter.
As a bonus, the person learns a faster way to point their web browser.
You should consider looking into books on improving memory. There are very simple techniques that make things easy to remember - like adding movement. E.g. an animation is easier to remember than an icon.
I'm not that much into memory techniques but say, nine different errors could be nine different animations with combinations of three animals combined with three objects - all interacting differently (dog, rabbit, crow, ball, cake, hat). A dog bites a ball, a rabbit eats a cake. A crow balances on a ball. A rabbit jumps on a hat, a dog burries a cake etc.
We can't get developers to pay attention to compiler warnings, what makes you think users are going to fare better?
I Browse at +4 Flamebait
Open Source Sysadmin
A someone who is just barely more informed about computers than his fellows, I know that seeing an error message with a lot of numbers and "technobabble" words just causes me to space it all out. A simple code such as you suggest would be VERY helpful in allowing me to note and report the error message.
One thought: you might want to avoid using actual colors in case any of your people are color blind.
Society should be expected to keep up with current terminology and technology. I don't think we should pander to them by making it stupidly simple. Although the idea of an error message opening the lolcatz page is hilarious/ "Do you see cute kittens with terrible grammar" "yes, ooozy boozy kwittens" "Ok your problem is x" Idiocracy here we come.
Application from hell. Client was almost ready to accept delivery of an application from another firm. Application was to distribute procedure documents created by central office.
Client forgot to develop and application to generate the procedure documents.
We had to slap together a tool to do this in less than 1/100 the time used to design the original application.
Did I mention it needed to support rich text, linked documents incremental translation and editing for the overseas offices?
Duct taped together several programs (Word, Access, Excel, others), users had to follow instructions and prompts. But, users don't -read- instructions or prompts.
One guy on my team wrote a custom messagebox. Anywhere any code called Windows MessageBox, it logged to a flat file:
- the calling function and context
- the exact title of the message
- the exact text of the message body
- the exact selection the user made
Tech support could view the flat file, read backwards, and see exactly what the user did, then walk them through doing it correctly.
Still a pain, but a manageable one.
I think that as caused by the BSOD. ( the Bleu Steak Of Death )
Stop blaming users - conduct usability testing! Poor interface design is the problem. This may not be sexy, but: Most error messages are not seen because they are competing for the user's (limited) attention. Common problems: Unexpected placement. Incomprehensible messages. Think like a user, or better yet, conduct usability testing. At @InterfaceGuru, over hundreds of usability tests, we ALWAYS ask users what they see "first." Every application is different, so testing is warranted above and beyond best practices. With all due respect to RFguy, society can only keep up with technology when we make it universally accessible.
cia9* Wanting the moon + 9 stars
Clearly you just need to make it a popup resembling My Computer stating in massive bold capitals VIRUS DETECTED ON YOUR COMPUTER! TO REMOVE IT DO THE FOLLOWING:
Followed by your error message. Clearly this works for the malware industry, why shouldnt it work for legitimate folks like us?
It's clear from scanning a good portion of the replies that the first obstacle is the utter contempt in which many Help Desk jockeys seem to hold the average user. Sorry guys (and it's always guys) but I bought a computer to do stuff with not to be a code monkey. When I get an error message like Error: No default for Main.CNode at 13:1-13:29.(Id 219,[(Id 200,Id 249)])it's clear the intended audience was not me. When I do get an error message in something that resembles English, I try to figure it out, I go read the FAQs, I try a forum or two, I thrash around and believe it or not I sometimes manage to sort out the problem. You have had some sensible suggestions from slashdotters like snspdaard, codehog, geoffrey.landis and gestalt n pepper. Try putting the crude humor aside and pay attention. Believe it or not there are a few users out here who do know what a power cable is.
First I want to get out of the way the fact that interface design in Windows(tm) is the most godawful shitty mess I've ever seen. Finishing an action with no error should not pop up a dialog saying "Your action finished correctly". Ridiculous and annoying, and trains everyone to quickly click on everything because 99% of that idiot boxes are unimportant and they are really an impediment to work: nothing bad has happened but they are not progressing unless they click there fast. That's rational behavior on everyone's part. Heck, those stupid dialogs could go even further and pop up every 20 seconds for no reason at all. That has to stop. When an important one pops up, they have clicked something before they realize they should have called me.
So I understand that and I'm not hard on the smart people. Now, on to the idiots. Scorn. That works every time. It works on small people because their stupid world is big about how others act around them. Their minds (for lack of a better word) are highly trained on small, petty feelings like shame and that's where you should hit. Scorn them, calmly, dispassionately, (not with irony! they don't get it!) as if you are talking to a disappointing animal (you are, but they think they are pretty smart, and don't see that coming until after you are gone). Say something along the lines of 'don't waste my time again' or 'call me only if you can still read the message' or, if you are grumpier than the usual me and it's been several times of this, just walk away without even opening your mouth and let them chase you and email inane drivel to your boss. Nothing will happen to you, and they learn something sometimes.
I don't know if my opinion seems far fetched or not, but I can get away with it at my workplace, and it's great. Of course they fear me, some resent me and I get no appreciation from the idiots. But they call rarely.
boobs
Maybe I can interest you in my newest USB gadget. I decided to go with the mnemonic CrotchBrick (tm). And yes, you can trigger it remotely and repeatedly.
Gosh, I hate that. Those warnings are there for a reason. If you truly feel they do not apply to your program, then disable those warnings in your Makefile or equivalent. Or actually fix them.
Which is why the application I work on displays enough information for an experienced user to have some idea of what is going on, and also logs that error message and a memory dump of every variable, open table, open program, and anything else we can gather and puts it all in a central error repository that all the programmers can get to easily. Along with a database where the programmers can put notes associated with each program or error message with suggestions as to causes and how to fix them with the users (which of course is also used to fix underlying problems when there's time).
A typical support ticket, from a user who reprinted a pick directive that someone else was already working on.
Experienced user: "Oh, Hi, John. You got a message 5 minutes ago saying the pick you wanted to do was already done? Well, hang on a second." (click, click, tappity tappity tap) "There we are, it says that Frank aready picked the item, you didn't reprint that pick directive by any chance did you? You did, because the original pick was damaged? Looks like Frank somehow got ahold of one or more of the sheets you thought you had thrown out or something. You and Frank need to go compare pick sheets and figure out who needs to pick what. Be sure and pull a report of pending picks for your area and eliminate stuff one of you has already done to save walking around."
Inexperienced user: "Oh, Hi, John. You got a message 5 minutes ago, but you don't know what it means? Well, hang on a second." (click, click, tappity tappity tap) "There we are, it looks like you were trying to pick something, right? OK, it says that someone else already picked the item, you didn't reprint that pick directive by any chance did you? You didn't? Hmm..." (looks at screen showing John HAD in fact done a pick reprint 15 minutes ago) "Ah, there we have it, must have been a printing error. Frank somehow got the same pick sheet you did and picked that item before you tried, so you and Frank need to have a chat about who is picking what. I'll send you a report of pending picks for your area and you and Frank can divvy it up."
The database also comes in really handy for identifying problems that the users experience often. "We had program XYZ raise error ABC 24 times yesterday, we need to identify what procedural breakdown is causing this, or what controls we can put in the program to prevent it."
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
"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."
Of course it would be possible:
"STEP AWAY FROM THE KEYBOARD, TOUCH NOTHING ... I'M WARNING YOU, THIS THING IS LOADED!"
should do the job.
Don't blame me, it's usually 2 in the morning when I post
Because of the online popup revolution of the early 2000s, people have become numb to the sight of error messages. People have formed the habit of immediately closing any window that pops up into their view. They may catch the first part of the message, but most of it is lost to them. They'll close the error message and then not understand why things aren't working correctly.
This leads me to my bigger pet peeve about those who PARTIALLY read error messages, but don't read the rest out to you. For example, someone may call me and say "I receive an error message while opening my email.. It says could not receive, yadda yadda yadda, and it keeps popping up every time I open my email."
"..... ok, could you read it to me exactly?"
"oh, I already closed it."
ARGH!
As far as not reading error messages is concerned though, the worst (I have found) are those messages that appear in Internet Explorer on the pale yellow bar. The messages that tell you a popup has been blocked, that you need to download the ActiveX, etc.. Trying to get people to focus their eyes on that bar is like trying to get them to stare at the sun. They just can't do it.
This is a very reasonable response. Parent should be modded insightful, not funny.
I've used pictures before and they do work for a lot of people.
The approach I generally use is to think of an error message like spam. To the user it is spam..they just want to accomplish their task and most don't like the computer at all. This message is just an annoyance. So you approach it like a spammer. 1) you can scare them into reading it. I would send out a critical virus update with the title "ACTION IMMEDIATELY TO AVOID SERVICE INTERRUPTION" You do run the risk of the boy who cried wolf so use it sparingly. Much like spam the caps lock is cruise control to awesome. 2) Hook it to something they want. Give a away some new mouse pads or something for early response.
3) Fake authority: Have a director sign off on it and send out a message people would never read if it came from you. 4)You could try promising them a larger penis but that might be NSFW
Well, there are several issues here, really.
First and foremost, why do apps like Photoshop hang the system for 10 seconds when the default is set to an offline network printer? Is that Photoshop's fault, really? No, it's an inherent problem/defect in the way Windows handles network devices! There's no reason it should take a computer 10 seconds (of CPU intensive behavior, to the point it hangs the app running in the foreground!) to figure out a specific network device isn't online! Why have so many people decided this is "acceptable" for so long?
As for giving error messages AFTER a task is completed? Really, it depends on the type of task -- but a message telling them the printer wasn't connected so the job will print when it's re-attached? Even if they click past that, assuming it doesn't apply - they should get a clue when their print job never appears.
I agree that people should be smart enough to follow basic instructions. They can handle things like a "fuel low" indicator on a car, because it's very basic. A warning lamp illuminates, usually right on top of the gauge monitoring the level of fuel remaining - and it's pretty easy for anyone to make the connection that it's trying to call your attention to the state of that gauge. If only software errors were so straight-forward!
What is a BA? I guess it must be a [something] Analyst, yes? Well, to amplify rdavidson's comment, the one time I worked for a software company as a QA, there were no specs, to speak of, and there were no BAs or any other sort of As at all! Not one person in that multi-national software firm had the title of Analyst. I'm serious. So, it was a little hard to complain to the developers about their crappy dialogs without a meaningful spec. I would do so anyway, and sometimes they got better. Often they didn't. Not one of the other QAs made a peep. So, when I finally got my promotion, it was to the Testing Automation Team - the first unit to get axed when there's a downturn. You know the rest of the story.
Social Credit would solve everything...
Here's an idea: let the user ignore the error, but you make it more noticeable over time. For example you could have some sort of a toolbar (people always ignore these) with the error message (or something along the lines of "Click here to report this error."). The user is free to ignore this message (and they will), so why don't you force it on them without blindly clicking on an OK button? Like, make the toolbar grow by 50% every minute, or every time the ignorant user clicks somewhere else...
time delayed activation of confirm buttons and different color of dialog.
God's gift to chicks
If users are ignoring your error messages then you have too many error messages. Users train themselves to ignore error messages because they see the same errors or types of errors over and over. Particularly popup errors will annoy the crap out of the average user to the point that if any popup error shows up they'll just OK them out of frustration or spite. If the user didn't fill out a field that is necessary for example, DON'T pop up a message indicating they didn't fill out field X, instead turn the label of field X red or something like that. It's the difference between saying to a user "you forgot this" with a simple indication and getting up into their face and saying "you are an idiot" with an generic error message popup. The fact that you have users calling you so much because of error messages to begin with is concerning; that is indicative to me that your users are fighting with your software or it is not intuitive enough or it is buggy.
Also, try asking "Are you the person that received the problem?"
Ask who found the problem....
I have trouble counting how many times I've had an error in a program, read the error code, knew what the problem was and a few potential fixes but didn't have admin so I could fix it myself. I let the supervisor know there is a problem and have a clueless supervisor jump in and give IT a load of crap and be unable to even read the message on the screen. I guess the words there were not in his crossword puzzle dictionary.
Remember, a trained manager can manage anything even if they don't understand it just like a trained teacher can teach anything even if they don't understand it. (If you believe this I have shares in a big bridge in Brooklyn you might be interested in.)
As to not reading error messages... try poking one spot on your skin over and over... the spot becomes numb. MS Windows give out so many irrelevant popups that you have to click through that it becomes second nature to "close the damned window that is covering up what you are doing".
I really enjoy having the error log in Windows 7. It allows me to go back and see what irrelevant errors popped up while I was doing something else. i.e. "X application cannot connect" errors that come up when you do not have an internet connection. (peeve - programs that insist on trying to phone home when you are working in standalone)
NRRPT/RCT
Possibly one of the most annoying error messages I see are the ones that end "Please contact your system administrator."
That tends to pop up when the common solutions involve a setting that one would have to sudo to change or (in well-locked-down installations) even look at.
You could grey out the "send" button until all the required data is filled in - this eliminates the need for an error message because it prevents the "sending with a blank recipient" condition ever occurring. But the cost is high - you're now relying on the user to figure out for themselves why the "send" button can't be pressed, instead of allowing them to press it and then informing them why it doesn't make sense by displaying an error message.
Or you could display the error message in a form other than an alert box, such as the tooltip on the disabled Send button. For example, "Send the message" becomes "Send the message once you have put an address in To:". The early implementation of tooltips in Mac OS 7.x, called "Balloon Help", did it this way.
The design of your program is faulty; it should not be able to load or especially modify a file type it can't save.
For some formats, it's a lot easier to write a reliable importer than a reliable exporter. This happens in three cases:
Why would any application reformat the hard drive?
Because it is a third-party replacement for an operating system component. Partition Magic is an example.
There is a time stamp, there should be no reason why I can't have two files with the same name.
If an application's response to a duplicate filename is appending the date and/or time to the filename, that just makes the operating system show "Your disk is full" that much sooner.
The only time you should have to reboot for any kind of update is an update to the kernel or file system.
A lot of applications install something that affects the kernel (such as a device driver) or the default file manager (such as a shell extension).
Getting users to read error messages requires (drum roll please!) ERROR MESSAGES THAT MEAN SOMETHING! Shocking, I know, but most users have absolutely no idea what IRQL = 0x#$%%#@ means or why they should care. On the other hand, an error message such as "USB Driver Failed; if this is the first time reboot, if not call the (no!) help desk" they might actually read the error message and respond.
I have a Comp Sci degree, and a Masters and almost a Ph.D. in Engineering - and where I work, I don't understand all of the error messages being generated...
The real issue, seems to me, is to convey some actual information in the error messages. That is, something more than 'An error has occurred'. That gives basically no "actionable" direction, but constitutes 80%-90% of the messages I troubleshoot.
Also, the use of "Yes" "No" and "Cancel" should be BANNED from dialogue boxes. Make the buttons actually say what they are going to do.
[Yes, you are absolutely right!] [What? That's stupid!] [No comment] [More info, please]
Additionally, in a corporate environment, why not make in-house app errors load part of their text from an external database that the Helpdesk can modify? (For example, the error can have a short, unchanging alphanumeric code string as an index, followed by a 255-character field.) After all, it's the Helpdesk that the user will be calling 99% of the time, so they've got the most invested in coming up with and tweaking text which will make the user NOT call them.
"What's your time worth? Now how much of it do you waste calling us when you could have been back to work five seconds later if you'd just read what was right in front of you?"
No winners. Xerox/SDS Sigma series error message if you mistyped the name of an executable.