Error messages in desktop-installed applications are most often displayed in some sort of modal dialog box. Paraphrasing the Apple Human Interface Guidelines, there are three types of dialog boxes:
Modeless. Enables users to change settings in a dialog while still interacting with document windows; the Find window in many word processors is an example of a modeless dialog. Modeless dialogs have title bar controls (close, minimize, and zoom buttons).
Document-modal. Prevents the user from doing anything else within a particular document. The user can switch to other documents in the application and to other applications.
Application-modal. Prevents the user from doing anything else within the owner application; the user can switch to another application. Most application-modal dialogs do not have the standard title bar controls (close, minimize, zoom); the user dismisses these dialogs by clicking a button, such as OK or Cancel.
Modality exists on the Web as well, but it comes in a slightly different form. Pop-up windows, for example, are modeless. They are often used in applications to configure settings and change preferences (for example, to add or remove a user from a Web-mail program), but they don't interfere with a user's ability to work with the parent window. Sure, clicking the parent window usually means losing track of the pop-up window, whether intentionally or not, but at least you can still interact with the main part of the application.
This behavior is just plain rude. It's not the user's job to jump through every little hoop an application comes up with. It's the job of the software to do what the user wants.
Redesigning rude behavior
Getting rid of application-modal messages in favor of document-modal messages has become an interesting, albeit disturbing, trend on the Web.
In another case, the entire page was dimmed out and all its interactions were disabled while a modal dialog box displayed in the center of the page. Also document-modal.
A new design for modal errors doesn't cure the problem. It just moves it. These designers are just finding more interesting ways to make the same mistake. They're redesigning rude behavior.
Replace it with modeless assistants
Instead of redesigning rude modal alert messages, we need to devise better solutions that help users maintain forward momentum while using our applications. We can do this by going modeless.
When messages are deleted in Gmail, a notification appears toward the top of the page that tells the user the conversation has been moved to the Trash and offers an Undo link. As expected, clicking the Undo link reinserts the deleted messages back into the list of messages.
I can undo my last operation? Brilliant! Bravo, Google. Bravo.
Google does three things right with this feature.
First, it eliminates the need to show confirmation messages that ask the user if she's sure she wants to throw the messages away.
Second, it offers a way to get the deleted messages back.
Finally, it shows the user how to do it via the inline text message at the top of the page.
The message is exposed right when it needs to be, and the yellow background used to display the message draws the eye right to it, so users are much more likely to see the message and know the feature exists. This message remains visible until the user performs a new action, like creating a new message or deleting another conversation. In other words, it stays active just long enough for users to backtrack and undo the delete action.
What Google did was brilliant, but not because implementing an undo feature was an original idea. It was brilliant because no one else was doing it on the Web and it's the right thing to do.
Now that Google has proven undo functions can be created on the Web, and has shown us a great way to do it, we're all out of excuses. Any application that allows users to perform what are normally irreversible actions should include an undo function.