Wednesday, February 10, 2010

Modal dialogs are evil

I find it endlessly fascinating (and perpetually frustrating) that 26 years after the introduction of the Mac, all of us -- on Windows, Mac, Gnome desktop, pretty much you-name-it -- are still suffering with the same tired UI metaphors in our desktop apps, some of which continue to serve us well, but others of which continue to serve us shoddily, day after frustrating day. The UI metaphor that serves us most shoddily of all, arguably, is that of the modal dialog.

I'm starting to agree with Aza Raskin and others who have pointed out that modal dialogs (dialogs that won't go away until you deal with them) are basically evil. They're not dialogs at all. They're more in the nature of monologs. A programmer has decided that you need to stop what you're doing and focus on (and make a decision regarding) whatever it is the programmer has decided you need to focus on, before you can move on to something else. This is done for your own good, of course. God forbid you should defer a decision, or decide to go on working while making a decision.

Some modal dialogs are necessary, of course. After all, if it is a requirement that you enter a license string before using a product, then you damn well better enter the license string. But most modal dialogs don't have to be modal -- and shouldn't be, IMHO. Most modal dialogs are modal because it's easier for the programmer if you work that way; maintaining a consistent program state becomes messy and difficult if you have a bunch of dialog boxes open at once. It's a matter of convenience. Not your convenience; the convenience of the people who designed the program.

"Modal" is not how people like to work, though. People tend to be extremely ad-hoc in their working styles (to match their thinking styles), tackling little bits of a job in random order, working a little on this, a little on that, until the job is done. Few people tackle a job by working it linearly, in rigid stepwise fashion, step by step until it's done. That's why wizards are (as UI devices go) generally odious. They don't match the way people work.

In my day job, I have the (dis)pleasure of using Adobe products intensively. The three I use daily are Acrobat Professional, Photoshop, and FrameMaker. Of these, the one I use the most -- and that causes the most heartburn -- is FrameMaker. Ironically, Adobe has learned a great deal about good UI design over the years, but they've applied the knowledge haphazardly. Photoshop, in particular, has become much less modal (as has FrameMaker); you can work ad-hoc now through a combination of always-open dialogs (palette panels), always-visible contextual toolbar buttons, and hotkey combos. However, image filters (plug-ins) are still modal: You work with one effect at a time and can't leave them open while jumping back and forth between them, much less chain them. Ironically, Adobe After Effects does let you work with filters that way (pipelining them; playing with multiple filter settings simultaneously, in non-modal fashion). You'd think Adobe would apply what it has learned from After Effects to Photoshop, for the benefit of the much larger Photoshop audience. But no.

With FrameMaker, palette-style operations are (thankfully) much more the norm now, but there are still far too many modal dialogs, and the ones that are most intrusive (for me) happen at the worst time: when I am opening a file. It so happens that I work with a lot of files that have missing graphics (graphics that are on someone else's machine) and/or unresolved cross-references. It's in the nature of what I do that I'm always encountering such files, which means that when I open them, I always have to dismiss 3 dialogs. The first dialog asks me to locate missing graphics. After I dismiss that dialog, I'm confronted with the following dialog (monolog):

Once I dismiss this monolog, I am confronted with yet another warning:

My question to Adobe is, why do I have to dismiss 3 dialogs in order to open a file? (And go through the same process every day, every time I open the same file?) Why can't you just put this information in a status-bar message at the bottom of the window, or flash it in a tooltip at the appropriate time (when I hover over a missing graphic), or at least put a checkbox on these dialogs that says "Don't show me this again"?

Better yet, give me a global config setting somewhere that turns off all "informational" alerts (see the little 'i' icon in the box?) and converts whatever those alerts (monologs) were going to tell me into log messages that I can look at whenever I want? Why put a modal dialog in my face and make me dismiss it 20 times a day?

But then, maybe I ask for too much. After all, it's only been 26 years now. These things take time to change.


  1. You know, I dislike modal dialogs in the interfaces I use too, but it's a little facile to just brand them "evil." There are two things that make (well- and thoughtfully-designed, of course) modal dialogs important, at least for transactional web applications.

    Irritating as they may be to people like us who know how all this stuff works, they've taught users that there are three steps to performing a transaction via an application: announce your intention; provide inputs; confirm that you're ready for the operation to take place. Now, in the absence of modal dialogs, a web application is left with moving to an "implicit save" model, or at least one that acts like Photoshop and collects an overall "save" into a single global virtual "document." Imagine what that'd be like for your Home Banking application. You click and type and pay and transfer for a while, and then you're presented with a "Save changes?" button. So people are going to keep track of their interactions like that? I find it dubious.

    For a transactional web app, which presents not only the tools to make changes, entries, deletions, etc., but also hooks to navigate away to new pages, modal dialogs make it possible to focus the interface on a single operation - one which the user initiated, preferably. I've had experience with applications that stick forms in the middle of a web app, with a little "Save" button, and what happens is that people fill in the form and then navigate away. It'd be possible to make everything be "implicit save" with some good client-side code, but it'd be complicated *and* I'm not sure it wouldn't cause as many problems as it'd solve, usability-wise.

  2. I am one of those lazy developers who prefers to stick to easy modal dialogs over non-modal ones. Other than for the super-optimizing user, having complex code to support non-modal dialogs is not worth the development trouble -- specially when all the functionality is there and the modal dialog only forces you to wait a bit. Making most things non-modal would actually confuse most users specially when they go off doing multiple things.

  3. Anonymous12:56 AM

    Modal windows might not be evil -- but Adobe's software design on the other hand...

  4. Anonymous8:53 AM

    Disagree. At least up to a point, modals serve the purpose of what Japanese industrial designers call poka-yoke or "mistakeproofing". Examples - lockout-tagout on dangerous machinery (you can't start the machine until you've locked the guard in place; if you try to move the guard the machine stops), a rifle whose magazine is shaped so you cannot insert it any other way than the right way round, the air/ground switch in an aircraft flight control system that stops you from deploying the thrust reversers and spoilers until the wheels touch the ground and stops you from pulling up the wheels until the plane takes off.

    If you have a critical step in the process, it makes perfect sense not to proceed until you have a complete set of valid inputs.

  5. A true evil: model boxes that cause the invoking application to steal focus from other applications (such as a chat program) in which the user is hitting the space bar or enter frequently.

    I think that the modal form of mistake proofing is pure laziness, it is not that hard to: add another wizard step, add an additional web page in the form chain, use jquery to make non-modal 'are you sure' confirmation divs.


  6. There are programs that can take care of that for you somewhat:

    I'm sure there are free ones, but I don't remember any by name.

  7. here's an example of the *evil* use of modals. some fuck was passing this link around in fb.
    WARNING: Open in a new WINDOW (not tab) so you can kill the damn thing with taskmgr.

  8. Anonymous4:40 AM

    Most commenters stop on the 'evil' word without understanding that what is evil is the abuse of the modal dialogs. One thing that irritates me too is when I try to copy a large number of files. I do my drag'n'drop then I go to my meal, knowing the operation will take a long time. When I go back, I see 5% of the operation only is done, because Windows shows me a dialog indicating there is a problem with a file and stopped there, while it could have continued with valid files...

    In a similar vein, there are these messages: "You should input only digits in this field" in a message box, while it is easy to restrict the kind of data.

    I disagree with Grok2, making a software more usable is important and worth some work. And it can make a difference with concurrents...

    Lastly, Charlie has a point, you can use a (free) tool like AutoHotkey or AutoIt to detect the dialogs and dismiss them automatically.

  9. Jason1:21 PM

    What bugs me is when a modal dialog is present, but not in focus. I can't see it! My system seems to have frozen, but really all I had to do as Alt-Tab a couple times until I found the hidden modal. Bugs the heck out of me.

  10. I find it ironic that there's a modal dialogue that blocks all the content on this page to ask you to subscribe.


Add a comment. Registration required because trolls.