Ditch Anything Modal

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.

JavaScript alerts, however, are application-modal. Not only do they prevent the user from interacting with other parts of a Web application, they also hijack the browser itself by making it impossible to switch pages or tabs or close the browser until the user clicks a button in the alert to close it. The user is left with no choice but to deal with the alert. She is unable to move on until the magical OK button is clicked.

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.

Instead of relying on JavaScript alert messages, for example, designers have been creating floating inline dialog boxes that serve the same purpose. It's as though everyone heard that users hate JavaScript alerts and decided they'd cure the issue by moving the confirmation messages and such into the page instead.

In one example I stumbled across recently, a message appeared that looked like a JavaScript alert, but it was displayed in the page itself as a floating box, complete with drag behavior. I could drag the error message around all I wanted to, but I couldn't move past it without clicking OK. This was a document-modal message. I could still interact with the browser itself, but not the application.

This faux JavaScript alert is disappointing. All it does is a nice job of redesigning rude behavior.

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.

Listen up, fellow designers. The issue isn't that the errors come in the form of separate controls, like JavaScript alerts. The issue is that the messages are modal. Making the messages document-modal isn't any better. Yes, document-modal messages still allow the users to interact with the browser or leave the page, but these messages still interrupt workflow, prevent users from working with the rest of an application while dealing with the message, and do so unnecessarily. A new spin on the same old trick is not the answer.

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.

For example, we can implement undo functions instead of relying on implementation-model, application-modal JavaScript alerts or document-modal errors and confirmation messages (especially ones that act like faux JavaScript alerts). Undo functions have been around for a long time in desktop applications, but somehow this behavior wasn't translated for the Webthat is, until Google decided to create undo functions for its popular Web-mail application, Gmail.

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.

I know, I know, building this functionality isn't always going to be easy, but it will definitely be worth it. And hey, someone's bound to release a JavaScript framework one of these days that makes implementing undo features really simple. (Someone, steal this idea and run with it. Please.)