The Problem with Error Dialogs

[drjdpowell]

This is a question to ask how people display errors to non-programmer Users.  

An example of a current Error Mesage that might be displayed to a User of one of my programs is this:

The problem I find is that to a many, if not most, Users, this comes across as "Error N ocurred at blah, blah, blah, I'd better report this to the programmer".  Their eyes have glazed over at the VI name, long before getting to the useful info that might actually help them fix the problem themselves (like realizing that they haven't pointed to the right folder where the file exists).  I tend to get reports like "Error X happened", or even "It didn't work" .   This is particularly bad with Error 1172, a .NET exception, which is full of .NET mumbojumbo like "invocation" and "inner exception".

I would rather have error dialogs like this:

Here, the info useful to the User is directly on the first line, followed by clear description not cluttered by techy-sounding fluff.  Details only important to me, the Programmer, are at the back, where I don't care if the User has stopped reading.

However, I am not sure how to programatically reorder Error dialogs in this way.  The important key phrases such as "File Not Found" are buried in unstructered text.  What have other people done?

[Bryan]

I'm in a manufacturing environment where the production operators are my end users.  Even your "rather have" example would be ignored by 90% of the end users that I serve.  They would just come to me and say "The red box keeps popping up.".  I would ask what it said and they would tell me that they didn't read it.  It appears that if they see lotsa text, they don't even attempt to read it.

What I've had to end up doing is to capture the error message codes and transpose them into something the operators will understand.  Then and present them with a shortly worded and flashy dialog with large text.  In the background however, I'm logging the error message verbatim to an error log file that I, and other LabVIEW programmers in my company can reference for further information and debugging.

To do this, I basically have a configuration file where the error codes are my keys, and the values are plain language error/failure/resolutions that will be presented to the operator.

[Mads]

In our commercial software such dialogs and event logs never expose anything in other than an understandable description of what did not go as planned, and if possible a suggestion on what to do to fix it (the code will evaluate  events at key locations and produce user friendly interpretations). The only thing included in the dialog that has to do with the underlying code is the error code specified as a sub-code of a more user friendly overall code (which is what they can also see described in the user manual) and source that tells what the software was trying to do. When support gets involved we have other means to dig out the underlying details (task specific event logging, debug-windows etc.).

Edited November 1, 2022 by Mads

[LogMAN]

It depends on the kind of error.

If the error can be fixed by the user, we typically guide them through the process. In this case the error is handled as part of the regular operation cycle that we designed with the customer.

If the error cannot (or should not) be fixed the user, then we typically block the process and wait for authorization by a supervisor. These are errors that we anticipated in the design, but whose root cause is not clear (i.e., failure to connect to hardware).

Finally, if the error does not fall into the first two categories, we dump them in a log file and fail the operation with a simple error message like "An unhandled error occurred. Report this issue to your supervisor.". These errors often indicate a bug or a flaw in the original design.

[hooovahh]

I'm convinced most of the users of my software are illiterate.  The good users of my software know the common troubleshooting techniques, and will blindly run through turning it off and on again before telling me.  Then if "The red screen" comes up again they'll tell me, or take a picture with their phone.  Honestly I prefer this over the "I don't know what it said".

[Bryan]

5 hours ago, hooovahh said:

I'm convinced most of the users of my software are illiterate.  The good users of my software know the common troubleshooting techniques, and will blindly run through turning it off and on again before telling me.  Then if "The red screen" comes up again they'll tell me, or take a picture with their phone.  Honestly I prefer this over the "I don't know what it said".

It almost sounds like you work at the same place I do.  I have a few of those users that at least make an effort, but they're few and far between.

Edited October 31, 2022 by Bryan

[drjdpowell]

I was hoping to get an "easy win" of improving error communication, without the cost of custom code to intercept and translate individual errors into more User-friendly ones.  Of course, custom messages is what one should do for the "expected" errors (such as the User not plugging something in, say, or selecting a file of the wrong type), but you can't anticipate more than a small subset of possible errors.

I should say my particular use case involves a large set of third-party code that can throw errors (often without error codes!), plus a variety of different categories of "Users", including not just "Operators", but subject-matter experts in the hardware and some of the third-party packages, who need to be able to use error information to debug problems in their areas.  I need to be able to present arbitrary errors in a way that is most helpful to them.

Edited November 1, 2022 by drjdpowell

[LogMAN]

In that case, perhaps you can improve your error message with functions from the General Error Handler VI. It should allow you to achieve what you want.

Another idea is to add images for well-known errors (file not found, error 1172, etc.). It helps users recognize issues they encountered before (and perhaps learned to fix on their own). Here is a complete example I just put together (it uses a picture ring for the image):

Error Dialog.vi

Edited November 1, 2022 by LogMAN

[ShaunR]

2 hours ago, drjdpowell said:

I should say my particular use case involves a large set of third-party code that can throw errors (often without error codes!), plus a variety of different categories of "Users", including not just "Operators", but subject-matter experts in the hardware and some of the third-party packages, who need to be able to use error information to debug problems in their areas.  I need to be able to present arbitrary errors in a way that is most helpful to them.

You are not using SQLite for this?

Not only can you have multiple messages based on required verbosity but you can have fine grained segregation based on type (information, debug, Critical, Warning etc) and user (Operator, Technician, Maintenance etc). Additionally you can have language translations.

Edited November 1, 2022 by ShaunR

[drjdpowell]

1 hour ago, ShaunR said:

You are not using SQLite for this?

I have an SQLite logger, yes, and the more expert Users do use it.  But even there hard to read error messages are a burden.  Especially the poor first line, as teh first line is what appears in the list of log entries, as in the "Error 63" shown here, which was a failure to find a TCP Service (because the service was not running). 

 

[ShaunR]

2 hours ago, drjdpowell said:

I have an SQLite logger, yes, and the more expert Users do use it.  But even there hard to read error messages are a burden.  Especially the poor first line, as teh first line is what appears in the list of log entries, as in the "Error 63" shown here, which was a failure to find a TCP Service (because the service was not running). 

 

That's because you have only dumped LV error messages into the DB. LabVIEW error messages are for LabVIEW programmers. Pull the error number out to a field so you can look up your own, different messages.

I think what you are struggling with is the difference between application error messages and system error messages. So I would expect an application message something like "Server XXXX is not responding. Unable to connect to server". That is fairly easy as you just override the default LabVIEW message for 63 with a more verbose one.

However. They may have left the IP address blank, in which case the application error would be something like "You must enter an IP address". If you let that through to LabVIEW then it will report error 54 "The network address is ill-formed." That may be ok since a blank IP address is, indeed, ill-formed but the former is more explicit. Note that just overriding error 54 with "You must enter an IP address" will have them yelling at you "I did enter it" as It is a context sensitive error. So adding a custom error code for blank fields that should be filled in is advisable and check the field before actioning. That way you can be sure error 54 was an illegal address. That's a rather contrived example but the sort of error guessing and reporting that I try to do (caveat: non programmers)

In summary, there are application specific errors. A production line operator should only be expected to resolve two types of errors - they didn't enter something they should have or they entered an illegal value. Outside of that it depends on training and remit. If there is training then you should also add the training manual page and section to which the error refers. This will cut down a lot of the "didn't read it" responses as they are expected to refer to the manual to resolve the issue and the manual will contain far more information than an error dialogue and what to do about it. If they can't give you the page number and section then they have not followed procedure and you can chew them out. If they have referred to the manual then you know the common resolutions have already been tried.

 

Edited November 1, 2022 by ShaunR

[ross.smyth]

I usually have one of two things happen:

1. User immediately closes dialog and then tells me my software is broken without any further explanation. A classic.
2. User reads it very carefully and gets confused because of the extra info, which seems to be what you suspected. When in reality the only important info is the first line. The weird ad-hoc LabVIEW error serialization within the source field ("<Err>" and family) just makes my life harder. The best solution I have found for this is to not use the built-in LabVIEW error dialogs for either display or error text sourcing. Their special handling is ok for LabVIEW programmers (but still not that great imo), and actively harmful for end-users.

I try very hard to make illegal states unrepresentable. This primarily means spending about around 2/3 or more of my time on validation and error handling. For example, if the user needs to enter in an IP address as suggested above I have several states that the interface goes through.

1. Have the "Ok", "Accept", "Connect" or whatever the button is to go to the next step greyed out and disabled. Have some text that says what to do. This text may be in a manual, but if it is it should also be relatively obvious from the UI perspective as well. This forces the user to enter in data in to the required field(s).
2. The user enters the data
3. Have an on value change event fire
4. Parse and validate the entered data
   • If valid, enable the button to continue
   • If invalid, keep the continue button disabled and also display what the user did wrong. This can be by a dialog (intrusive so I usually don't), or by blinking the invalid control and displaying a text indicator with the (user friendly!) error message. These usually have examples of correct input as well.

If your software can detect that the user has input invalid data then I highly recommend making invalid states unrepresentable in a form like this. Makes users happy because no scary error messages, and you happy because you don't have to worry about anything sneaking its way in to the rest system by accident (it happens!). So in essence by main solution to the error dialog issue is by treating error dialogs as bugs and a failure in proper input validation. This also includes if the user opens a file, but I do use dialogs to report those errors, but not LabVIEW error dialogs or errors in general.

[Rolf Kalbermatter]

On 10/31/2022 at 2:56 PM, hooovahh said:

I'm convinced most of the users of my software are illiterate.  The good users of my software know the common troubleshooting techniques, and will blindly run through turning it off and on again before telling me.  Then if "The red screen" comes up again they'll tell me, or take a picture with their phone.  Honestly I prefer this over the "I don't know what it said".

I know such users too. But I have also come across another kind of users, or rather not come across them often. We write an application and install it and test it and the customer seems happy. Years later they call us because they want to have a new feature or extension and you go there to discuss the feature and take a look at the application and start it up and almost the first thing that happens is that you see an error message when running a quick test. And the resident operator than comes and tells you: "Ahh yes that dialog, you have to first start this other terminal program or whatever and do this and that in there and then you can start this application and all works well."

"You mean you are doing this all this time already like this?"

"Yes sure, it works, so why bother any further about it?"

"Ahh right, ok!"

And when you then look at the code you can quickly see where things must go wrong and sometimes even wonder how it ever could have worked fine, but these people experimented and came up with a solution that I would never even have dreamed about to work. If they had called, it would have been a question of a one or two hour fix, but they never called.