Everyone knows that pop-ups used to be the scourge of the Internet. These days, modern versions of most browsers contain “pop-up blocking” built in. They had become prevalent due to their use as high-visibility advertising, resulting in high click-through-rates. But everyone knows that pop-ups are bad, because they’re annoying and hurt usability.
Consider why pop-ups are bad:
- They steal focus away from the current context: This should be obvious, but whenever something appears on the screen which interrupts your current task, it negatively impacts usability.
- They require extra actions to complete your task: Every pop-up must be closed before the existing task can continue. This may be as quick as hitting Alt-F4, or take as long as switching from keyboard to mouse in order to click the close button.
Despite knowing that pop-ups are evil in web applications, many application writers continue use pop-ups in client-side applications. The terminology for client-side applications is slightly different, however. Pop-ups in client-side applications are known as “pop up dialogs”, “modal dialogs”, or sometimes simply “dialogs”. Some great examples of annoying dialogs can be found The Daily WTF.
One specific type of dialog that is particularly bad is the “Do not show this again” or “Don’t ask me again” type dialogs. Here’s an example from a project on CodeProject:
These types of dialogs generally show information that the user might be interested in, but most likely isn’t. For developers, the easy way out is to simply implement a “Do not show this again” type dialog, justifying by saying “Sure, it’s annoying, but they only have to see it once”. Chances are, if it is annoying, you shouldn’t be showing it as a dialog to begin with. On top of that, users generally immediately click ok for this type of dialog without reading the text. And if they do click on the checkbox, it’s possible that they may want it to come back at some point, which is likely impossible.
Here are some guidelines for when dialog boxes are inappropriate:
- Providing informational messages that may be interesting to the user.
Informational messages should never interrupt the users workflow. Present this information to the user in ways that are non-intrusive. Examples of this are tooltip-style boxes that provide information without stealing focus, and tooltip bubbles. - Alerting the user to non-fatal errors and warnings.
Users probably don’t care about non-fatal errors. Chances are, they don’t know how to fix the error, or don’t want to bother. For example: a dialog box alerting the user that the connection to a server failed is probably inappropriate. Alternatives would be: status bar text, status icon indicating connection state, and tooltip bubbles. - Input validation errors.
Don’t put up a dialog box saying “Hey, you can’t have letters in your phone number!” This is annoying, and interrupts the users workflow. Direct the users attention to the field using non-modal UI, such as highlighting the erroneous field, or using a tooltip bubble (can you tell that I like tooltip bubbles?)
On the other hand, however, there are some scenarios where you can, should, and must use dialog boxes.
- Feedback is required from the user.
“Do you want to save this document?” is a great example of when a dialog is absolutely necessary. You need to get feedback from the user to determine the proper choice of action. However, if there is ever a scenario where a “default” is usually appropriate, consider the impact of using the default instead of prompting the user for an action. - Fatal errors.
A perfect application would never have fatal errors, but everyone knows that perfect applications are as common as unicorns. When your program crashes, make every attempt to save the users data in some form, and alert the user that a problem has occurred. However, under no circumstances should you give an error that looks like this: “Unhandled exception at doFoobar.cpp:2534″. This sort of information should be logged for customer support, not presented to the user in a dialog box.