When are modal dialogs truly necessary?

问题:

Modal dialogs are evil, but I keep reading "You should remove modal dialogs when possible"

When isn't it possible to remove modal dialogs? I mean, what are some truly modal tasks that force us to use evil modal dialogs?

The most common given example is the "Do you want to Save?" I think this is the problem of the concept of having the user hit Save instead of remembering that user input is sacred. If you just saved automatically with the ability to "undo" or have revisions, then you don't ever need ask the user if they want to save.

• "Are you sure you want to delete?" Undelete
• "Are you sure you want to quit?" Why would you ask that? Are you that vain?

Why do we ever need modal dialogs?

EDIT

Webs app don't count in my books, unless they write their own UI windowing system within the browser. Web apps don't have the same tools set as desktop apps.

EDIT 2

My question is slightly different than the one labeled as duplicate. I feel that there is no case that modal dialogs are the best solution. The referred question assumes there is such a case.

Duplicate of: When Is Modal UI acceptable?

回答1:

Use Cases for Modal Dialogs

• blocking the application flow until information required to continue is entered, as for example a password in a login process.
• collecting application configuration options in a centralized dialog. In such cases, typically the changes are applied upon closing the dialog, and access to the application is disabled while the edits are being made.
• warning that the effects of the current action are not reversible. This is a frequent interaction pattern for modal dialogs, but it is also criticised by usability experts as being ineffective for its intended use (protection against errors in destructive actions) and for which better alternatives exist.

(Source: Wikipedia)

When I use them

In instances where stopping them from doing something stupid is absolutely mandatory. My company has a web app where Users sometimes leave the page before finishing their work. We prompt them with a Modal (the standard onbeforeunload JavaScript function) if they haven't saved their work.

Otherwise, I don't use Modals if I can help it, I hate it when an app steals focus from what I'm doing.

Edit: We don't save their work automatically for them when they leave the page. We do at other times, but not when they leave the page, hence the Modal. I did write could that could go in and save their work when they left the page, but it wouldn't be a 'great' idea to implement it, especially if they accidentally deleted their work and didn't want it to automatically save.

回答2:

The only thing more sacred than user input is any file I known about. You should never modify any file that an implementation detail unless I have told you to. Thus boxes like "do you want to save?" at exit are a must because I may want to not save.

回答3:

Imagine an application which needs to open a dialog for some actions. Now imagine that these would be non-modal dialogs: while one dialog is open, you could change the selection or even worse - invoke a different command which itself opens another dialog. Now imagine the these dialogs would be modal: then you would have to close the dialog to proceed - you can't get in the state where the selection changes under a dialog or where two commands are waiting for input.