Mosuki blog

The modal dialog was once the overused bane of desktop software users. A window is modal if it prevents any other actions while the window is up. Good uses of modal dialogs do exist: For example, asking the user “Save this file before quitting?” should be modal; if it wasn’t modal, the user could move the dialog off to the side, close the file without saving it, and then click “Yes” in the dialog — and what would the app do? The file it’s just been told to save is no longer open.

But overuse of modal dialogs just ends up forcing the user into very particular sequences of action. For example, if I have a “find” dialog that’s modal, and I want to copy and paste some search terms into it, I have to think to copy the search terms first, or I have to cancel the find dialog, copy the search terms, and re-open the dialog. That’s three clicks + a copy and paste, compared to one click and a copy and paste.

The worst part was, this overuse of modal windows ended up training a whole generation of computer users to just click “Yes” or “OK” on every dialog that popped up. This tendency makes the appropriate use of modals irrelevant and it’s now taken advantage of by designers of malware and annoying ads on webpages.

Fast-forward to The Happy Shiny Web 2.0 days. Some enterprising individuals have figured out how to create modal windows with CSS and JavaScript. While their solution is very clever, I think modal dialogs are even more rarely needed in web applications than in traditional desktop software. I’ll explain why.

Assume, for the sake of argument, that your web application does have some actions that require intermediate user intervention but should lock up the rest of the application while that action is in progress. A modal dialog might seem like a good way to lock up the entire app. But since your entire application is running inside a page in a web browser, it can only lock up that page. There’s absolutely nothing to stop the user from opening a second view onto your web application in another tab, another window, another browser, or even on another computer.

So, if you have some action that must be modal; that must lock your web application while that action is in process, then your web application is broken. And making a modal window with CSS & JavaScript won’t fix it. There’s nothing you can do to prevent the user from performing simultaneous actions in different windows.

There’s another way to say what I’m saying here: HTTP is stateless. The only real state in your web application is your cookies - and even those are specific to the particular browser; some modal action that involved cookies could still be circumvented by launching a different browser.

With this in mind, I hope the all the Web 2.0 application designers out there aren’t seduced by the sexy CSS and JavaScript modal window technique. If they do, they’ll just be repeating the mistaken, annoying, and ultimately damaging modal dialogs fad from the ’80s and ’90s.