Why are modal dialog boxes evil?

Question

Re the recent question at when are modal dialogs truly necessary?. WHY are modal dialog boxes evil? Is it because people don't read them anyway? Because they are often implemented so poorly? Something else?

Answer 1

People don't read them, and that's a good thing. You want people to form habits around your UI, but having an important choice in popup is just going to make the user hit OK.

They interrupt the user, they prevent the user from doing other things.

What if you wanted to copy and paste something off the main window? What if you wanted to copy the message in the modal dialog? What if you don't care.

Just compare IE's Find dialog vs Firefox

Compare IE's "Do you want us to remember this password for you?" to Firefox

Answer 2

One of the reasons that I don't like them is because they are showing information in serial(one lot of information at a time) and not parallel(all the information you need to see at once), parallel will allow the user to choose what they want to look at where as in serial you are pretty much forcing them to pick an option.

Plus also the fact that they break a users flow of control(eg steals focus from the object you working on) which I really don't like doing. So in effect from this the user will just hit OK so that they can get back to what they where doing and ignore the information in the dialog box.

Mind you you still need them in some cases.

Answer 3

In a consumer style application, they are more or less useless; users don't read them, learn to dismiss them, and when they DO read them, usually end up being confused. I think a Yes/No/Cancel dialog is downright lazy UI design. The "buttons say what they do" dialog is slightly better, because the user doesn't have to read much.

That being said: In data-critical intranet/"enterprise" applications, they are more or less necessary to confirm destructive actions or to sanity check non-standard workflows that may be allowed but not recommended.

So, I don't think they are conceptually "evil", but more often than not, the result of bad UI design.

Answer 4

They are evil because they violate the basic principle that the user is supposed to be able to direct the software's action. Modal dialogs (the evil form of dialog boxes in general) constrain the user to only one action.

Some answers seem to misapprehend that it's any popup that asks for e.g. user confirmation. This could be accomplished without tieing up the entire app or computer; it's this behavior that people object to.

In some environments, modal dialogs only constrain the user in the context of a single application (or maybe less). Really bad modal dialogs prevent the user from doing anything else in the entire operating system (say, Windows).

Answer 5

Personally I think it depends entirely on how it is done.

Try copying 10 files where every file exists in the target directory, do it using Windows Explorer.

Is a single modal dialog for each file really the correct answer in such an operation. I know you have "Yes to all", but the entire loop system should've been built differently. It should've gathered all the files that exists into one big list and asked once "What do you want to do with these files", and then let me decide for each file down the list what to do before clicking OK and resuming the operation.

And lots of times dialog boxes just interrupt the normal workflow.

And yes, people don't read dialog boxes. So a golden tip if you must use a dialog box is to reword it.

Instead of "Do you want to delete this row in the database?", try wording it so that you're asking (but this isn't worded right) "Do you want to not delete this row in the database?" This way, if they just hit Yes, which is the typical response from a user who just wants to get on with it, they'll end up doing nothing.

Answer 6

The Wikipedia article has a good summation of the complaints.

Answer 7

I don't remember where I saw this first, but a better approach to a modal dialog is often to allow an easy to find and use "undo" capability. Windows Explorer actually does both when you delete a file. It asks for confirmation (modal dialog), then, immediately after deleting the file, the Edit menu has an "Undo Delete" option. just a simple way to access the Recycle Bin, for sure, but in this case, Microsoft really could have just done away with the dialog.

The point being, you can often do without the dialog with a bit of thinking, and perhaps a bit of extra code, but it's just too easy an option for a lazy, or perhaps, more generously, a time-constrained developer.

That said, sometimes you really want a dialog. Think about all of the options on a typical Print dialog. Which printer? All pages, or just a few? How many copies? I don't know how you'd do that without a dialog box...

Answer 8

The best UIs are modal. As are the worst.

A modal UI - regardless of whether it is built from dialog boxes, toolbar buttons, or text prompts - is only desirable so long as each mode matches the expectations of the user transitioning to it. When the program transitions into a mode unexpectedly... or the mode requires the user to possess information he does not have readily available... then it will cause the user hardship, either forcing him to revert to a previous mode or guess at the proper action with potentially undesirable results.

A non-modal UI is a complete set of tools. Some are relevant to the job at hand, some are not. A user must have sufficient skill both to choose the correct tools, and to apply them in the correct manner. While a non-modal UI can therefore never be as optimal as a good modal UI (the right tool for the current task already in hand), it can also never be as sub-optimal as a bad modal UI (the wrong tool for the current task slamming into your careless fingers).

Designing a good modal UI can be a fiendishly difficult task for non-trivial applications, especially for general-purpose programs intended to be used by a wide variety of users for an even broader range of purposes. Menu systems and dialog boxes attempt to bridge the gap, allowing small, task-specific modal sections in a larger, non-modal application. Neither one scales particularly well however, and mis-use and overuse have left them with a bad reputation, often seen as the first refuge of the lazy programmer. Dialog boxes in particular are often used more as a means of forcing users into a programmer's (or designer's) idea of how an application should be used, or punting difficult design decisions and tricky error handling at the user, rather than for their namesake goal of communication.

Indeed, the rise of web applications has brought such tendencies to the surface in numerous forums, newsgroups, and Q&A sites such as this one, as programmers accustomed to writing ultra-linear logic which prompts users for input when needed by the program rather than when available to the user... are forced into a system where users can navigate non-linearly, and may well view any attempt to restrict this freedom as a quaint annoyance to be subverted rather than a necessary evil. The plaintive wails of these poor coders echo around the 'Net as their attempts to force this crude modal behavior onto a non-modal system come crashing down around them. For those of us who have long suffered under their cruel "dialogs", it is a lovely tune indeed.

Answer 9

Noboy reads them, and they interrupt the program flow. Often when used as error notification they are the precurrsor to a program failure. By the time the user realizes what is going on, the message is gone and they are left to recall or invent the message as best they can.

Answer 10

Before you get to read my answer, you must carefully read the following message in it's entirety. All processes, subprocesses, tasks, and threads are suspended indefinitely pending your answer. And, once you completely understand the message, and possibly agree to some legal stuff, and all the implications of all of this, then and only then can you proceed.

Answer 11

About half of the answers so far are addressing the flaws of confirmation dialogs, not of modal dialogs. While the vast majority of confirmation dialogs are modal, this does not mean that the two terms are synonymous.

A modal dialog is one which puts the program into a specific mode and does not allow you to do anything which doesn't correspond to that mode while it is open. In the most common implementation, this means you can't access any other windows.

This is evil.

Consider an address book application. Suppose you have an existing person in the address book and you wish to add their roommate.

• If the "add person" dialog is non-modal, you can flip back and forth between the old record and the new one copying and pasting your data.
• If the "add person" dialog is modal, you can't do anything with the old record while the add dialog is open. You can select something to copy before selecting "add", but just one thing. Everything else has to be manually retyped.

On rare occasions, you run into something which truly must be done in one piece without allowing the user to diverge from that task until it is complete. Modal dialogs are appropriate for such cases. But these cases are very rare! Which is basically the point of the other thread referenced by this question.

Answer 12

For a work-around, you can add a Transparent image (separately stored in your media library) to your Form that can be shown in the Dialog or you can use solution model to dynamically add an image to the form before the form gets loaded. Make sure the transparent property of the Image has been set to true. Now, you can set the height and width of the image to the height and width of the Dialog to create the same illusion for showing a busy indication. But, this will not block the user intervention. User can still interact with the form’s contents. To Block the user Intervention, just attach a blank method to the image on its on-action event- just a blank method! So, when a user clicks on any of the form content, s/he ultimately clicks on the image and method attached with the on-action event will get fired, which will do nothing, but prevent user intervention.