The purpose of error messages
-
Did it ever occur to you what it means when a program presents you wih an error message? (a meaningful one that is) I'm under the impression that few users understand it - At least when I'd have to judge it by the amount of bug reports I've seen that basically state "there is an error message". For those who don't get my meaning: The purpose of an error message is to inform the user of a problem that is outside the scope of the software. It might be invalid input, corrupt files, inappropriate use of certain functionality, hardware problems, or maybe just a (known!) limitation of the built-in algorithms. In any case, if there is an error message, then it is a sure sign the developers were already aware of that specific problem. Most importantly: the software did catch the error condition. It is like thinking that a fireproof door will prevent a fire. It will not. It will merely prevent it from causing damage. And maybe it can trigger an alarm to the fire brigade. Software error protection is just like that: it cannot prevent that something odd happens, it can only prevent damage and notify the user of the problem. That doesn't mean the software is defective. To the contrary: if there was no error message and the program would just silently destroy your data - that would be a defect. Note this is not a reaction to some current problem, not even a recent one. The topic just came up in a discussion and the realization hit me how common it is for users of software to take an error message as an indication for a doftware error, when in most cases the opposite is true! If you're looking for a question - there is none. Just needed to vent my thoughts. ;)
The things I don't like about software error messages are the ones like "The specified file was not found" and then the error doesn't say what the specified file was and the user didn't specify a file. usually its in a setup or startup routine. Or perhaps there's many specified files in a software options/config. My beef is with that, if the file was specified it wouldn't be too hard for the programmer writing the error handling routine to make the error more meaningful by actually saying what the specified file that wasn't found actually was etc..
-
I already had a mailman who last programmed a little on a C64 and precisely told me what part of the code to look at and what to look for to fix an error he had gotten - without ever having seen the code. This certainly is not your common user. And there also is some political aspect. Paying customers tend to get hysterical at the smallest sign of trouble, especially if they can't really judge wether the error is serious or not. Often enough this quickly escalates and I have to spend more time telling worried bosses that it was really no big deal than it took to actually fix it. On the other side they are totally at ease when you tell them that you already have noticed what has happened and are going to look into it.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
This certainly is not your common user.
Agree, but it's still your user. I'm not saying that you should dump the stack trace to the user (although I wish some applications did so I could try to solve the problem myself) but at leas give an indication of the problem at some level. A simple example is the Page not found problem. When I see this high leve error, I immediatelly look at the address bar and try to ammend possible typo mistakes the developer might have done when creating the hyperlink. And if I can't I simply don't insist on it I know I won't get anywhere and I save myself some time. This is just a simple example, but there are countless that might really be helpful to show the user.
CDP1802 wrote:
Paying customers tend to get hysterical at the smallest sign of trouble, especially if they can't really judge wether the error is serious or not.
They can get like that even if they are not paying :)
CDP1802 wrote:
On the other side they are totally at ease when you tell them that you already have noticed what has happened and are going to look into it.
Completely agree as users also can get hysterical when they see the same error over and over again having no idea of what's wrong and without hope it's being noticed or it's going to be fixed.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
The things I don't like about software error messages are the ones like "The specified file was not found" and then the error doesn't say what the specified file was and the user didn't specify a file. usually its in a setup or startup routine. Or perhaps there's many specified files in a software options/config. My beef is with that, if the file was specified it wouldn't be too hard for the programmer writing the error handling routine to make the error more meaningful by actually saying what the specified file that wasn't found actually was etc..
Agreed. That is what I do not call a meaningful error message. In that case there is a software error: the message is not clear or helpful. Suggested fix: clarify the message and provide additional information as required by the user to solve the problem. A good practice is to provide help nodes for your error messages and provide links to those nodes together with the message. Then the inexperienced user can choose to follow the link to understand and fix the problem, whereas the advanced user can just fix it right away and go on. As pointed out in other responses, my beef is with bug reports triggered by error messages that are totally unambiguous and self-explanatory.
-
My usual strategy is to give only little information to the users. Something like ' An internal error has occured, please try again. The error has been logged as [some id]. Please use this id if the problem repeats and wish to report it'. And, as mentioned, each and every error is logged, complete with a stack trace and the parameters. Sometimes I also have a 'Report' button, which redirects the user to a page where he can simply add his intentions or suggestions to the logged error. More details would just confuse the typical user and provide him with no useful information.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.Error messages like "An internal error has occurred" make me want to slap the developer upside his/her head. Even if a more detailed error is logged, as a user I want to see a meaningful error message. I want a concise error message in simple English that tells me what went wrong (Microsoft, are you reading this?).
-
Error messages like "An internal error has occurred" make me want to slap the developer upside his/her head. Even if a more detailed error is logged, as a user I want to see a meaningful error message. I want a concise error message in simple English that tells me what went wrong (Microsoft, are you reading this?).
Old Ed wrote:
as a user I want to see a meaningful error message
Define meaningful. Do you really want to know that some webservice on some SAP system did not respond? Or that the validation of some entity failed? Or that the webservice, after finally responding, unexpectedly sent us back some null reference? Believe me, to our users it would be all the same. I could really tell them that the flux compensator will not be able to handle the matter-antimatter imbalance in the warp core, it would make no difference. How concise yet simple can those things be told without reducing it to 'There has been an error on the server'?
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
Old Ed wrote:
as a user I want to see a meaningful error message
Define meaningful. Do you really want to know that some webservice on some SAP system did not respond? Or that the validation of some entity failed? Or that the webservice, after finally responding, unexpectedly sent us back some null reference? Believe me, to our users it would be all the same. I could really tell them that the flux compensator will not be able to handle the matter-antimatter imbalance in the warp core, it would make no difference. How concise yet simple can those things be told without reducing it to 'There has been an error on the server'?
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse."Flux compensator error due to matter-antimatter impalance". Just kidding! As both a user and developer I would like to know that some webservice on some SAP system did not respond, the validation of some entity failed, and that the webservice returned a "bad" reference. I can't count the number of instances where a clear error message as related by the user by phone or email has directed me to a bug in code. In addition, a specific and concise error message has helped me more than once when I've dealt with various Customer Support reps. In the days when I did a good deal of support I could tell a system operator what error messages meant in cases where the code was not the problem, and avoid a subsequent call if the error recurred.
-
"An internal error has occured"normal user : Uuuhh ? experienced user : Uuuhh ? as opposed tothe flux compensator cannot handle the matter-antimatter imbalance in the warp core anymorenormal user : Uuuhh ? experienced user : Mmmhh, that's correct. Maybe I should open that box to let a few anti-positron out to balance the matter-antimatter levels, and try again. -
If I heard that there was a "matter-antimatter imbalance in the warp core", I wouldn`t hang around and open a box to let out some "anti-positron" into the room.
I would run for my life, before two men take me away in a straight jacket.
You couldn't run fast enough. The speed of the subspace-time implosion would be (naturally) faster than the speed of light. And no point making out your will. It would be destroyed along with the rest of the planet. ;P
-
Did it ever occur to you what it means when a program presents you wih an error message? (a meaningful one that is) I'm under the impression that few users understand it - At least when I'd have to judge it by the amount of bug reports I've seen that basically state "there is an error message". For those who don't get my meaning: The purpose of an error message is to inform the user of a problem that is outside the scope of the software. It might be invalid input, corrupt files, inappropriate use of certain functionality, hardware problems, or maybe just a (known!) limitation of the built-in algorithms. In any case, if there is an error message, then it is a sure sign the developers were already aware of that specific problem. Most importantly: the software did catch the error condition. It is like thinking that a fireproof door will prevent a fire. It will not. It will merely prevent it from causing damage. And maybe it can trigger an alarm to the fire brigade. Software error protection is just like that: it cannot prevent that something odd happens, it can only prevent damage and notify the user of the problem. That doesn't mean the software is defective. To the contrary: if there was no error message and the program would just silently destroy your data - that would be a defect. Note this is not a reaction to some current problem, not even a recent one. The topic just came up in a discussion and the realization hit me how common it is for users of software to take an error message as an indication for a doftware error, when in most cases the opposite is true! If you're looking for a question - there is none. Just needed to vent my thoughts. ;)
It doesn't matter what you write. The user's eyeballs just slide off the glass and they will report, "I was doing something and it crashed." "Was there an error message?" "Yes." "What did it say?" "I don't know, I didn't understand it." "Couldn't you write it down?" "I was in a hurry, just fix it." I'd be a millionaire if I had a nickel for every time I had the above conversation. Even with QA departments that should have known better. So telling them "the dilithium is depleted" or "Psst, the winning lottery number is..." might be worthwhile since it could tickle their funny bone so they'd remember it and relate it to you. "SQL error, mismatched arguments at line 535" will never be reported. I have difficulty getting inhouse users to send me a screen shot when a problem occurs. My mantra is "If I can't reproduce it, I can't fix it." The sense of that is starting to get across to them. But for external users....dream, dream, on.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
It doesn't matter what you write. The user's eyeballs just slide off the glass and they will report, "I was doing something and it crashed." "Was there an error message?" "Yes." "What did it say?" "I don't know, I didn't understand it." "Couldn't you write it down?" "I was in a hurry, just fix it." I'd be a millionaire if I had a nickel for every time I had the above conversation. Even with QA departments that should have known better. So telling them "the dilithium is depleted" or "Psst, the winning lottery number is..." might be worthwhile since it could tickle their funny bone so they'd remember it and relate it to you. "SQL error, mismatched arguments at line 535" will never be reported. I have difficulty getting inhouse users to send me a screen shot when a problem occurs. My mantra is "If I can't reproduce it, I can't fix it." The sense of that is starting to get across to them. But for external users....dream, dream, on.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
CDP1802 wrote:
This certainly is not your common user.
Agree, but it's still your user. I'm not saying that you should dump the stack trace to the user (although I wish some applications did so I could try to solve the problem myself) but at leas give an indication of the problem at some level. A simple example is the Page not found problem. When I see this high leve error, I immediatelly look at the address bar and try to ammend possible typo mistakes the developer might have done when creating the hyperlink. And if I can't I simply don't insist on it I know I won't get anywhere and I save myself some time. This is just a simple example, but there are countless that might really be helpful to show the user.
CDP1802 wrote:
Paying customers tend to get hysterical at the smallest sign of trouble, especially if they can't really judge wether the error is serious or not.
They can get like that even if they are not paying :)
CDP1802 wrote:
On the other side they are totally at ease when you tell them that you already have noticed what has happened and are going to look into it.
Completely agree as users also can get hysterical when they see the same error over and over again having no idea of what's wrong and without hope it's being noticed or it's going to be fixed.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
I do understand what you want to tell me, but please believe me - it does not work with those people. The web application is supposed to provide downloads with article and price information. The users are the elves sitting in some market who search and select the articles from the sortiment they are selling and then let the application put together a massive XML download for them, which they then import into their ERP system. They know which buttons to push and are really helpless when it does not work. We left them little means to do something wrong. At worst they can request a download which they don't need. The application replaced an older one which was really bad. It simply died quietly, logged nothing and the users had gotten used to it. Most of the time they reported nothing and when they did, it was extremely hard and time consuming to get enough information out of them to reproduce and possibly repair the problem. That's why I started monitoring their inputs and logged them together with the exceptions and stack traces. In the new application I kept this with very good results. Before going online this worked out very much like one big unit test. Everything that happened was logged with as much information as possible. We just had to read the logs and take a look at those things. Since it went online it has not failed to produce a single download and we tested it before by downloading the entire database with millions of articles and everything that belongs to them. Now, that they always get what they are looking for, the users have gotten even more lethargic. They have what they want and that's it for them. The support team, the developers and selected external people must know what is going on in the application. They get to see some things which ordinary users do not get access to. Such things as the logs themselves, overviews over the jobs that are just being prepared or are ready for downloading or pages to do some quick automated tests on the database to see what condition it is in. I just took a look from here at home. By the way, the normal users get a simplified overview over the jobs they have started. They can see the progress (of course only on their own jobs), an estimate when it will be ready to download, download those which have been prepared or delete them once they are done. They actually get more information than ever before. If a download fails, they are not interested why. They just want to have the information. Pronto. But, up to now, not a single job has failed. The only
-
Old Ed wrote:
as a user I want to see a meaningful error message
Define meaningful. Do you really want to know that some webservice on some SAP system did not respond? Or that the validation of some entity failed? Or that the webservice, after finally responding, unexpectedly sent us back some null reference? Believe me, to our users it would be all the same. I could really tell them that the flux compensator will not be able to handle the matter-antimatter imbalance in the warp core, it would make no difference. How concise yet simple can those things be told without reducing it to 'There has been an error on the server'?
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.What about the users that can handle the problem. An "internal error/exception occured" is really not meaningful enough. If the user that does not support the current product, need to download debugger or system information tools to find which module fails, it means the error message was not meaningful enough. A message like "Exception <exception_code_here> occured in <module_name>.dll" (I work on windows most of the time) is meaningful enough, because we know that not current software is guilty about the problem. If we are really insistent, then we could debug, or we could check if module has been overwriten, we could search for original, we could check for bugs (if they are posted on official site) or we can post a bug to support. Or in case "Null data received by server" we could fix the server (if it is ours), notify the server or just wait owner to fix it. In last cases information given is equivalent to "You could do nothing to fix this!". However a massively large group of users will not understand the message and ignore it. Currently all the users from that group will also not understand what is "Internal error" and will also ignore the message. So what you will lose of meaningful error message?
-
I do understand what you want to tell me, but please believe me - it does not work with those people. The web application is supposed to provide downloads with article and price information. The users are the elves sitting in some market who search and select the articles from the sortiment they are selling and then let the application put together a massive XML download for them, which they then import into their ERP system. They know which buttons to push and are really helpless when it does not work. We left them little means to do something wrong. At worst they can request a download which they don't need. The application replaced an older one which was really bad. It simply died quietly, logged nothing and the users had gotten used to it. Most of the time they reported nothing and when they did, it was extremely hard and time consuming to get enough information out of them to reproduce and possibly repair the problem. That's why I started monitoring their inputs and logged them together with the exceptions and stack traces. In the new application I kept this with very good results. Before going online this worked out very much like one big unit test. Everything that happened was logged with as much information as possible. We just had to read the logs and take a look at those things. Since it went online it has not failed to produce a single download and we tested it before by downloading the entire database with millions of articles and everything that belongs to them. Now, that they always get what they are looking for, the users have gotten even more lethargic. They have what they want and that's it for them. The support team, the developers and selected external people must know what is going on in the application. They get to see some things which ordinary users do not get access to. Such things as the logs themselves, overviews over the jobs that are just being prepared or are ready for downloading or pages to do some quick automated tests on the database to see what condition it is in. I just took a look from here at home. By the way, the normal users get a simplified overview over the jobs they have started. They can see the progress (of course only on their own jobs), an estimate when it will be ready to download, download those which have been prepared or delete them once they are done. They actually get more information than ever before. If a download fails, they are not interested why. They just want to have the information. Pronto. But, up to now, not a single job has failed. The only
I understand you, as I said in an earlier post, this is about different scenarios. You obviously know your users very well and I believe your approach to this scenarios with these users is the ideal one. What I was trying to point out though is that in many other scenarios this is not necessarily the best approach.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
Hmm, yeah. Don't agree with that.
Regards, Rob Philpott.
Rob, I like how you use arguments to support your opinion. Makes it easier for me to disagree with you. Stephan, Very good thought, nicely put too. I totally agree, but then again, I am a developer. From my exeprience many programmers suffer from the "There is an error message"-syndrome too. It makes me agry because it always forces me to ask: "Well, what is the message". I have notified those colleges that I will no longer respond to those reports that do not include the actual message. Makes life much easier. :laugh:
-
Did it ever occur to you what it means when a program presents you wih an error message? (a meaningful one that is) I'm under the impression that few users understand it - At least when I'd have to judge it by the amount of bug reports I've seen that basically state "there is an error message". For those who don't get my meaning: The purpose of an error message is to inform the user of a problem that is outside the scope of the software. It might be invalid input, corrupt files, inappropriate use of certain functionality, hardware problems, or maybe just a (known!) limitation of the built-in algorithms. In any case, if there is an error message, then it is a sure sign the developers were already aware of that specific problem. Most importantly: the software did catch the error condition. It is like thinking that a fireproof door will prevent a fire. It will not. It will merely prevent it from causing damage. And maybe it can trigger an alarm to the fire brigade. Software error protection is just like that: it cannot prevent that something odd happens, it can only prevent damage and notify the user of the problem. That doesn't mean the software is defective. To the contrary: if there was no error message and the program would just silently destroy your data - that would be a defect. Note this is not a reaction to some current problem, not even a recent one. The topic just came up in a discussion and the realization hit me how common it is for users of software to take an error message as an indication for a doftware error, when in most cases the opposite is true! If you're looking for a question - there is none. Just needed to vent my thoughts. ;)
Isn't it remarkable, then, that the most unforgiving, grumpy, and bad-tempered calls to help desks come from developers who've encountered error messages? Stupid users normally ask what it is that they've done wrong. How stupid can you get?
I wanna be a eunuchs developer! Pass me a bread knife!
-
Isn't it remarkable, then, that the most unforgiving, grumpy, and bad-tempered calls to help desks come from developers who've encountered error messages? Stupid users normally ask what it is that they've done wrong. How stupid can you get?
I wanna be a eunuchs developer! Pass me a bread knife!
That's different: at least in my experience when developers complain about an error message they usually complain about the message being unhelpful, not the software being bugged. Again, I am talking about bug reports refering to meaningful error messages, and I've never heard a dev complain about any of those.
-
Rob, I like how you use arguments to support your opinion. Makes it easier for me to disagree with you. Stephan, Very good thought, nicely put too. I totally agree, but then again, I am a developer. From my exeprience many programmers suffer from the "There is an error message"-syndrome too. It makes me agry because it always forces me to ask: "Well, what is the message". I have notified those colleges that I will no longer respond to those reports that do not include the actual message. Makes life much easier. :laugh:
I get this "there was an error message" complaint a lot (not, I hasten to add for s/w that I have written; normally from users of products which have been sold in their millions by mega corporations that I don't have a copy of). When asked what the error message said, they cannot recall; they have already closed the application / rebooted / found some circumventions; and almost invariably cannot recall what they were doing that caused the error to recur. They, then, get upset that you cannot fix the problem for them. I try to politely ask them not to destroy the evidence next time it happens but to let me see for myself, but next time it happens, they do exactly the same again. I have tried telling them that it is like contacting the police to say an unspecified crime happened at an unknown location to people that you did not see and then wondering why the perpetrators have not been caught, but they fail to see the analogy. Bizarrely, this behaviour is as common with supposedly computer literate people (e.g. computer operators [data centre people who load tapes / collate line printer listings / schedule batch runs; not people who operate computer keyboards a data entry clerks]) as it is with casual users. P.S. I had an error last week. I can't remember what it was. Please could you fix it for me. Thanks!
-
Did it ever occur to you what it means when a program presents you wih an error message? (a meaningful one that is) I'm under the impression that few users understand it - At least when I'd have to judge it by the amount of bug reports I've seen that basically state "there is an error message". For those who don't get my meaning: The purpose of an error message is to inform the user of a problem that is outside the scope of the software. It might be invalid input, corrupt files, inappropriate use of certain functionality, hardware problems, or maybe just a (known!) limitation of the built-in algorithms. In any case, if there is an error message, then it is a sure sign the developers were already aware of that specific problem. Most importantly: the software did catch the error condition. It is like thinking that a fireproof door will prevent a fire. It will not. It will merely prevent it from causing damage. And maybe it can trigger an alarm to the fire brigade. Software error protection is just like that: it cannot prevent that something odd happens, it can only prevent damage and notify the user of the problem. That doesn't mean the software is defective. To the contrary: if there was no error message and the program would just silently destroy your data - that would be a defect. Note this is not a reaction to some current problem, not even a recent one. The topic just came up in a discussion and the realization hit me how common it is for users of software to take an error message as an indication for a doftware error, when in most cases the opposite is true! If you're looking for a question - there is none. Just needed to vent my thoughts. ;)
The error messages that I like are the ones cold-called on the telephone: "We have been monitoring your computer and believe you have a problem that is causing it to go slow." A typical conversation then goes like ... Me: Which computer? Them: The one running Windows. Me: Oh! That narrows it down ... which version of Windows? (I have several versions on different machines) Them: Not sure - our report doesn't say. Me: Wow! A detailed report that analyses everything about my PC except which version of OS it is running. Them: Err, yes! It is the one that is getting slower. Me: Ah! That one. What does it say is the cause? Them: We need to access your machine to find out. Me: Not a very useful report that you're working from is it, then? Besides, I know what the problem is even without your help. Them: We have the software that can fix it if you let me access your machine. What do you think that the problem is? Me: That would be wonderful, thank you. The problem is a dry joint on the motherboard ... how can your software fix that? Them: Just let us access your PC - we know more about them than you do. Me: I have an honours degree in Computing, 31 years professional experience as a software engineer and computer implementation specialist, am an MBCS and CITP, and am the IT 'guru' for several charitable organisations. What is your experience, apart from being able to frighten the gullible into allowing you to install malware? Phone: 'The other person has cleared'.