Visual Basic Concepts

  • Article

When Things Go Wrong: Interacting with Users

In an ideal world, software and hardware would always work flawlessly, and users would never make mistakes. Reality dictates that mistakes can and will happen. A part of user interface design involves deciding how the application will respond when things go wrong.

A common response is to display a dialog box, asking for user input as to how the application should deal with the problem. A less common (but preferable) response would be to simply resolve the problem without bothering the user. After all, the user is primarily concerned with performing a task, not with technical details. In designing your user interface, think about the potential errors and determine which ones require user interaction and which ones can be resolved programmatically.

Creating Intelligent Dialog Boxes

Occasionally an error occurs in your application and it's necessary to make a decision in order to resolve the situation. This usually occurs as a branch in your code — an If…Then statement or a Case statement. If the decision requires user interaction, the question is usually posed to the user with a dialog box. Dialog boxes are a part of your user interface, and like the other parts of the interface, their design plays a role in the usability of your application.

Sometimes it seems as if many dialog boxes were designed by programmers who have never had an intelligent conversation with another human being. A message such as "A sector of fixed disk C: is corrupted or inaccessible. Abort, Retry, Ignore?" (see Figure 6.22) has little meaning to the average user. It's kind of like a waitress asking you "We're out of soup or the kitchen is on fire. Abort, Retry, Ignore?" How would you answer? It's important to phrase questions (and choices) in a manner that the user can understand. In the prior example, a better message might be "There is a problem saving your file on drive C. Save file on drive A, Don't save the file?"

Figure 6.22   Which dialog box presents the clearest message?

When creating dialog boxes for your application, keep the user in mind. Does the message convey useful information to the user? Is it easily understandable? Do the command buttons present clear choices? Are the choices appropriate for the given situation? Keep in mind that it only takes one annoying message box to give a user a bad impression of your application.

If you're designing your own custom dialog forms, try to stick to a standard style. If you vary too far from the standard message box layout, users may not recognize it as a dialog box.

For More Information   To learn more about dialogs, see "Dialog Boxes" earlier in this chapter.

Handling Errors Without Dialog Boxes

It isn't always necessary to interrupt the user when an error occurs. Sometimes it's preferable to handle the error in code without notifying the user, or to warn the user in a way that doesn't stop their work flow. A good example of this technique is the AutoCorrect feature in Microsoft Word: if a common word is mistyped, Word fixes it automatically; if a less common word is misspelled, it is underlined in red so the user can correct it later.

There are a number of techniques that you can use; it's up to you to decide which techniques are appropriate for your own application. Here are a few suggestions:

  • Add an Undo function to the Edit menu. Rather than interrupting the user with a confirmation dialog for deletions and so forth, trust that they are making the right decision and provide a Undo function in case they change their mind later.

  • Display a message on a status bar or icon. If the error doesn't affect the user's current task, don't stop the application. Use a status bar or a brightly colored warning icon to warn the user — they can handle the problem when they are ready.

  • Correct the problem. Sometimes the solution to an error is obvious. For instance, if a disk is full when the user tries to save a file, check the system for space on other drives. If space is available, save the file; put a message on the status bar to let the user know what you did.

  • Save the message until later. Not all errors are critical or demand immediate attention; consider logging these to a file and displaying them to the user when they exit the application or at another convenient time. If the user makes a possible entry error (for example, Mian St. instead of Main St.), log it. Add a Review Entries button and a function to display the discrepancies so the user can correct them.

  • Don't do anything. Sometimes an error isn't important enough to warrant a warning. For instance, the fact that a printer on LPT1 is out of paper doesn't mean much until you're ready to print. Wait until the message is appropriate to the current task.

For More Information   To learn more about error handling techniques, see "Debugging Your Code and Handling Errors."