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. ;)
Hmm, yeah. Don't agree with that.
Regards, Rob Philpott.
-
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. ;)
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. -
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. -
CDP1802 wrote:
An internal error has occured, please try again
I so hate that ! It makes me think every time that the developer was some clueless chap who was hired to replace someone during the summer holidays time.
I hate that as well. But what good does it do to tell a normal user that the flux compensator cannot handle the matter-antimatter imbalance in the warp core anymore?
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. -
I hate that as well. But what good does it do to tell a normal user that the flux compensator cannot handle the matter-antimatter imbalance in the warp core anymore?
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."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. -
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. ;)
-
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.While this is a reasonable strategy, it is the exception rather than the rule that I was referring to. I was thinking of tested, stable release code that doesn't have error messages like that (unless they somehow sneaked past QA). Messages like "Number expected!" should prompt the user to fix their input, not post a bug report. Ok, that example was a bit simplistic, but some bug reports I've seen aren't all that different... Yes, of course, sometimes you get these errors that should have been caught at lower levels but weren't, so in the end you'd have to resort to a technique like what you described. but as I said, well tested code shouldn't have these errors on a regular basis. Ideally the users should never see them. Once I caused an error message to be released that was meant as an internal debug message only (something like: "This error can't happen, please contact <my name here>". Fortunately it was caught during client side testing, before being released to the actual users. This message was indeed caused by an error inside the software, one of the very few occasions where my observation doesn't hold. But then the message wasn't meant to be in release code.
-
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 all depends on the type of error. If you're talking about user initiated errors - invalid data being the primary - then if the application can decide not to accept something then it should inform the user why. If it's an internal error, then the minimum would be to inform the user /where/ the problem is; for example any network fault should be of the "Unable to communicate with ..." type stylee. When an exception is caught it should be, at the very, logged along with the stack for support to investigate if needed.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
"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.Yeah, maybe we should draw our error messages from here :-D
-
It all depends on the type of error. If you're talking about user initiated errors - invalid data being the primary - then if the application can decide not to accept something then it should inform the user why. If it's an internal error, then the minimum would be to inform the user /where/ the problem is; for example any network fault should be of the "Unable to communicate with ..." type stylee. When an exception is caught it should be, at the very, logged along with the stack for support to investigate if needed.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Absolutely. The only type of error that *should* prompt a bug report are those caused by exceptions. But, as pointed out in another response, these should be, well, exceptions ;) , not the rule. I have no qualms with bug reports about those, just with 'bug' reports about legitimate messages by other causes.
-
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. ;)
As has been touched on already, there's two types of 'error message'. There's what we, developers, usually mean by it: an error condition within the application which we don't know how to deal with, effectively a caught crash. These should be submitted as bug reports, and they also shouldn't happen (well tested applications should get rid of them in alpha/beta) – but we all know that real life applications are impossible to get bug free in most cases. And then there's what you're talking about here, a failure of a dependency, usually input or output of data. The user counts as a dependency in this case if your application depends on user specified input, and a failure of that dependency is probably the most common (i.e. user types invalid input), but there are other common causes (file permissions, network outages, database being down etc). This type of 'error' is external to the application and not a bug. I'm not sure that the difference is clear enough between those two types, particularly if the message is something like 'Input pressure must be positive' – is that because the user directly typed a zero, because some intermediate calculation based on the user input produced a zero or because the algorithm read the wrong number? It's better for users to send too many bug reports than too few; it's generally quite easy to filter out those that aren't actually bugs. If you have so many users you are swamped by reports, then you can probably afford to hire more people to filter them.
-
As has been touched on already, there's two types of 'error message'. There's what we, developers, usually mean by it: an error condition within the application which we don't know how to deal with, effectively a caught crash. These should be submitted as bug reports, and they also shouldn't happen (well tested applications should get rid of them in alpha/beta) – but we all know that real life applications are impossible to get bug free in most cases. And then there's what you're talking about here, a failure of a dependency, usually input or output of data. The user counts as a dependency in this case if your application depends on user specified input, and a failure of that dependency is probably the most common (i.e. user types invalid input), but there are other common causes (file permissions, network outages, database being down etc). This type of 'error' is external to the application and not a bug. I'm not sure that the difference is clear enough between those two types, particularly if the message is something like 'Input pressure must be positive' – is that because the user directly typed a zero, because some intermediate calculation based on the user input produced a zero or because the algorithm read the wrong number? It's better for users to send too many bug reports than too few; it's generally quite easy to filter out those that aren't actually bugs. If you have so many users you are swamped by reports, then you can probably afford to hire more people to filter them.
BobJanova wrote:
if the message is something like 'Input pressure must be positive' – is that because the user directly typed a zero, because some intermediate calculation based on the user input produced a zero or because the algorithm read the wrong number?
That's (one of the things) what I meant by 'meaningful'. Of course, a message has to be clear. If it isn't, and the user sends in a bug report, then that is well justified. Not because the condition stated in the message indicates an error, but because the message is unclear!
BobJanova wrote:
It's better for users to send too many bug reports than too few
Alas, I suppose you're right. The ultimate target is to get the application right, and everyone benefits if users do help finding all the bugs hidden in the system. That doesn't change that sometimes such bug reports can be annoying ;)
-
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.By using that strategy you're missing the opportunity to let the user solve the problem himself. Many problems can be solved by the user and save your time on support. Some problems may require the user to be more tech savy, but nevertheless will save you time on support. And I also tend to get very mad when the software won't tell me what's wrong as I usually can get around most problems. So let the user decide whether some information is useful or not, unless there are security issues at stake.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
By using that strategy you're missing the opportunity to let the user solve the problem himself. Many problems can be solved by the user and save your time on support. Some problems may require the user to be more tech savy, but nevertheless will save you time on support. And I also tend to get very mad when the software won't tell me what's wrong as I usually can get around most problems. So let the user decide whether some information is useful or not, unless there are security issues at stake.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
God forbid! The average users of our web applications cannot be trusted to be able to solve a bag of Coolaid in water, much less any problems that might occur on the server! And, by definition, half of them are even dumber than the average users. It already was an effort to train them to use the reporting form if anything goes wrong. Seriously, the sight of a real error message scares them more than a simple 'We have a problem here which you can't really do anything about, but feel free to try again or report it'. I keep an eye on the logs anyway and usually have taken care of it before anybody cares to submit a report. By now there only rarely are log entries, the users can do their work and the application holds the company's record for needing the least support since going live. To be honest, up to now I only had to fix a smaller display bug, everything else was caused by shoddy data from SAP, over which I have no control.
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. -
God forbid! The average users of our web applications cannot be trusted to be able to solve a bag of Coolaid in water, much less any problems that might occur on the server! And, by definition, half of them are even dumber than the average users. It already was an effort to train them to use the reporting form if anything goes wrong. Seriously, the sight of a real error message scares them more than a simple 'We have a problem here which you can't really do anything about, but feel free to try again or report it'. I keep an eye on the logs anyway and usually have taken care of it before anybody cares to submit a report. By now there only rarely are log entries, the users can do their work and the application holds the company's record for needing the least support since going live. To be honest, up to now I only had to fix a smaller display bug, everything else was caused by shoddy data from SAP, over which I have no control.
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.And there are scenarios and scenarios. I believe you're right, you know your community, but if you didn't I believe error messages that don't tell anything about the problem are not good, specially when you have a very large user base like open web applications.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
And there are scenarios and scenarios. I believe you're right, you know your community, but if you didn't I believe error messages that don't tell anything about the problem are not good, specially when you have a very large user base like open web applications.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
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. -
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?).