How many times you have seen an error message window to pop-up in an application giving you a meaningless error message and all you can do is to press “Ok” or “Cancel” without any idea where the error message was related to. At best the error message gives you some hint what was wrong and you may get back on track with the application. However once you close the pop-up, you no longer have the details of the error message to help you with fixing the problem. Do the applications you yourself have developed behave this way?

Well, things don’t have to be this way? On the contrary, you as a developer should design applications so that you never let your users to find  themselves in situations like this. It’s not only a benefit of the user, but also a benefit of you as a developer. Once your applications works fluently and gives your users intuitive feedback, you need to spend much less time for the user support and you’ll have much more time for your most important tasks.

One way to increase the usability of your application is to avoid pop-up windows altogether and instead display contextual error-messages in-place as close to the actual point-of-problem as possible. For example, when you have a user editable string control, your application should display the error message right next to the string control and instruct the user right away fix the problem occurred.

Not only locate the error message next to the actual point of problem, but also give the feedback instantly when the problem occurs so that the user can take immediate actions to fix the probelm. Much to often I’ve seen applications that let you fill in forms or configure your applications settings in an incorrect way and only when you press the “Ok” button, you are shown a long list of error message. Once you close the error message window, you have no idea what ten items there were in the separate error message window.

Let’s examine a simple LabVIEW VI that illustrates how things can be made more comfortable for our application users. In the example the user is guided to fill in an IP address to a string control. Once she has entered the address, she can go on her task by pressing the “Ok” button. To help the user complete, we place an instruction text above the string control to inctruct the user of the form she should enter the IP address. To avoid error states in our program flow, we disable the “Ok” button until the user has entered a valid IP address. However, we allow user to cancel the task at any point.

If the user enters an invalidly formatted IP address, we should inform the user immediately of the situation. To accomplish this, we user a value change event to validate the control value once user has finished editing it. If the value is invalid, we place a red error message right next to the IP address string control, change the color of the control caption to red and make sure the “Ok” button is disable so the user cannot proceed until the problems have been fixed.

The error message should not only indicate what the error was but also guide how to fix the error. So instead of telling the user that the IP address was malformatted, instruct the user how to correctly format the IP address. Depending on your application audience, your user may not even know what an IP address is and instead try to type in a domain name or even email address. So you have to give good and polite instructions on how the user can proceed with her task.

I made an small example VI on how you could utilize contextual error messages in your application.

EDIT 11/3/2008: Andrey suggested to check for input errors while to user is typing the input. I was initially against this idea as it can be very distracting for the user if an error message is displayed when user is correctly entering a value into a control. However, we can alter the value validation algorithm slightly to be used with update value while typing. We can check if the string user is typing can lead into a valid value while user is typing the value. If not, we display an error message. If the beginning of the string is valid, we should not distract the user but let her continue. However, we should not allow user to continue until the value is fully completed.

I edited the example in accordance with these principles. The regular expression for checking partial string is constructed from the regular expression for full strings in the following way. Our full regular expression string consists of several components. A partial string user is typing is valid if it is 1) empty or matches 2) partial first part, 3) first part and partial second part, 4) first and second part and partial third part, and so on. You get the point.