When is modal UI acceptable?

Question

By and large, modal interfaces suck big rocks. On the other hand, I can't think of a better way to handle File Open..., or Print... and this, I think, is because

• they are occasional actions, infrequent and momentous, and
• they are atomic in nature; you either finish specifying all your print options and go through with it, or you cancel the whole show.

Let's put together a little style-guide. Suggest any use-cases in which a dialog is the preferred presentation and why it is preferred. Can the dialog be non-modal? If it is, how do you mark transactional boundaries, since Cancel ceases to have a clear meaning. Do you use an Apply button, for example?

Answer 1

In my experience, there are very few things that should ever be modal in a UI. One of the best examples of this, and probably one very familiar to the users of the site, is Eclipse. Although it has some modal dialogs, and I'm speaking only of the core IDE here, they largely fall into three categories: File operations, preference dialogs and parameter dialogs.

Preference dialogs, while modal by tradition, need not be modal either. All you have to do is look at the Mac OS preference model, where configuration changes take place immediately, with modal behaviour introduced only in cases where the change might be disruptive to work in progress.

In short, here's what I would say is a good summary of what should be modal. Exceptions to this set should be well-justified by the usage.

• Parameter entry dialogs (example: refactoring wizards. anti-example: find dialogs)
• File operations
• Confirmation of an action that will take immediate disruptive effect

Answer 2

I think the distinction is that if there is anything at all that a user might be able to do in the application while the dialog is shown, then it should not be modal. This includes copy/paste actions. Personally I would prefer it if file/open and print dialogs weren't modal either. I think modal dialogs are a sign of weak design, a necessary evil to get code out the door quickly.

Answer 3

IMO, modal interfaces should only be used when you HAVE to deal with whatever the dialog is doing or asking before the application can continue. Any other time, if you're using a dialog, it should be non-modal.

Answer 4

When doing non-modal windows, you might want to ensure they are unique: you don't really want two identical toolboxes (in a graphical program for example) or two identical preferences dialog (I saw this in a product), which can be confusing at best.

On the other hand, I appreciate when a Search/Replace dialog is non-modal: I can go back to the document and cancel last change, skip elsewhere, etc.; without losing the current settings.

Somehow, modal dialogs tell the user to "stop everything else and finish what you are doing", which has its uses, as pointed out in Stephen Wrighton's answer.

Answer 5

How about a user login window, you cannot (or should not) use the rest of an application until you've logged in, assuming security is necessary.