Best Practices for Dialog Box Interactions

The interactions between a user and a computer interface ideally should feel natural and delightful. The theory of The Media Equation states that people subconsciously tend to treat computer interfaces as if they were real people—thus, comparing personal interactions with user interface interactions is a useful sanity check when designing user interfaces. In this post I’ll apply these comparisons to dialog boxes.

Dialog boxes are a crucial component of complex user interfaces—they help you through decisions and prevent you from making mistakes. Based on the Media Equation, most interactions with a computer interface should correspond to the feeling of a casual, relaxed conversation with another person. Dialog boxes, on the other hand, correspond to a serious, urgent conversational tone: sometimes necessary, but often jarring and awkward. User interface designers and developers should be judicious in their use of dialogs in order to delight, rather than frustrate users.

Prefer an Undo option over confirmation dialogs when possible

Dialogs are frequently used to confirm actions, but often this is unnecessary. In many cases, you can provide users with an Undo option instead. That way, you make an action take fewer steps, while still giving users a way to recover from occasional mistakes. Similarly, in personal conversation, you sometimes misspeak and have to correct yourself, but this is much more efficient than asking the other person for permission every time you hesitate about something.

This works great for lightweight actions that are easily reversible with an Undo option, such as upvoting or downvoting content, adding friends and connections, and editing text and photos. By making actions take fewer steps, or reducing friction, you encourage users to take more such actions, which can be valuable to optimize an interface’s usage.

As an exception to this practice, there are two scenarios where dialogs should be used for confirming actions:

  1. When the user has never performed the action yet, and the action has consequences the user should be made aware of, for example, if the action shares information publicly, notifies other users, or requires the user to wait a long time. In that case, the dialog should only show up once, or should provide a option to “don’t show this again”, since it’s no longer valuable to a user who has learned the system.
  2. When the computer system can’t Undo the action, because the action has some effect outside of your system. For example, a system can’t Undo launching missiles, or buying something online, or sending an email. Although that hasn’t stopped Google from building an Undo feature for emails in Gmail, which actually works by having the server wait a few seconds to send the email out. This Undo option is unconventional since it times out after a few seconds, but it still provides some value for preventing mistakes.

Use dialogs when the user forgot to do something

The above rule shows how dialogs aren’t necessary for many scenarios of “Are you sure you want to do something?” However, they can be really valuable for scenarios of “Are you sure you don’t want to do something?” or “Aren’t you forgetting something?” This comes into play when you take an action, but there is a step involved that is (a) recommended to take and (b) no longer possible after the action. In this case, the interface is keeping the user from losing work or making a mistake, so it is prudent to prevent the mistake even if it entails interrupting the user.

Continuing the personal conversation analogy, this is akin to remembering to give your friend back their umbrella you were borrowing before they step into the subway to go home: in all likelihood they won’t mind the interruption and they’ll appreciate your thoughtfulness.

Some examples of this in interfaces:

  • Showing a save dialog when you close a document with unsaved changes. You can’t save the changes after closing it, and it’s likely that you want to save the changes.
  • Similarly, showing a confirmation dialog when you close a webpage where you started filling out a form.
  • Showing a warning dialog when you try sending an email without including an attachment that you referred to in the email body (this feature got a shout-out in the Facebook comments of my last post)

And a counterexample:

  • If your application is already showing a dialog and the user tries quitting the application, dismiss the dialog if it’s no longer useful. For example, the Network Connect VPN client will show a warning dialog if the connection fails, and will not let the user quit the program unless the user dismisses the dialog (or force quits). Since the user is trying to quit the program, they aren’t interested in recovering the connection, so the dialog should be dismissed automatically.

Design dialog interactions around the user’s mental model, not the system model

Good user interaction designers will distinguish between mental models—how the users understand your interface—and system models—how the the interface is programmed. This can come into play with dialogs.

For example, most users’ mental model for a word processing file is that the file consists of content that they can edit and format directly. When you edit the text of a document, your file will have unsaved changes, and the application will warn you with a Save dialog if you try to close the document. This makes sense to the user and is a helpful interaction.

In reality, files also contain metadata that the users aren’t aware of, and that aren’t part of the user’s mental model for files. If actions only change a file’s metadata and not its content, the user won’t think the file has any unsaved changes. If the interface says they have unsaved changes, this conflicts with the user’s mental model and they may get confused or annoyed. Microsoft Word violates users’ expectations by showing you a warning dialog if you close a file after you simply print it or get its word count, neither of which change the file’s visible content.

Don’t interrupt the user if they’re not taking an action

When a user takes an action, like pressing a button, they expect that they may experience a dialog or other interruption before continuing. However, if the user isn’t expecting a dialog to appear, it’s usually a bad idea to interrupt them. For example, they will be annoyed if the dialog steals their attention when they are reading something, or if it steals the focus from the keyboard when they are in the middle of typing. Similarly, in a personal conversation, you don’t interrupt another person in the middle of a sentence, you wait for a lull in the conversation or wait for the attention to turn naturally to you.

Some examples of bad dialog interruptions are:

  • Mac OS X Lion’s version of TextEdit, which would interrupt you with a dialog to unlock a file for editing, as soon as you you start typing
  • iOS’s “Ask to Join Wi-Fi Networks” feature, which will show a full-screen dialog whenever it detects Wi-Fi and you’re using an app that needs a data connection
  • The Adobe Updater, which seems to sporadically appear a few seconds after you load a webpage that has Flash enabled.

Here are some better ways to get users’ attention without interrupting them:

  • Show a non-interrupting system notification, such as a banner
  • Show a non-modal, contextual dialog that pops out of the relevant toolbar controls
  • Change an ambient display, such as the Wi-Fi signal icon in the system status bar