Why yes, i would like to fill your dialog out, and yes, i need data immediately behind it on my computer screen to finish filling out your dialog. Oh, wait I can't get to that data because you're modal :(
Modality is easier to create because it lets you write more batch-processing style code and less "synchronize all widgets on every change" code. The latter can massively increase the scope of performance tuning if a lot of processing is involved to do synchronizations. Hence if the UI is in a "supporting" role(e.g. an internal tool) rather than the core of the product, going modal at key points may be appropriate for a version 1. You can always iterate on it.
They are indeed evil, but sometimes a necessary evil. Browsers apart (you shouldn't block a user from going to check info on the web), some parts of your applications are simply not meant to be modified/run at the same time.
The author is just piling on against an unsatisfactory technique that used to be the least bad choice and which now thankfully has a chance of being displaced by new and better techniques.
There are a lot of reasons to hate on traditional modal dialogs. Their scope isn't flexible enough. Their association with different parts of a program isn't clear enough. It's unclear what should happen when more than one modal dialog wants to be open. Some of these problems are being mitigated by newer techniques. Modal dialogs that pop over (internal to a component) instead of popping up (external to a component) are a godsend for tabbed applications, for example. Users are also becoming more sophisticated, reducing the need for modal dialogs. It's a good time to start shaking ourselves out of the old habit of relying on modal dialogs.
So the author's timing is good, but he misunderstands why modal dialogs became so common in the first place and why they can become much less common in the near future. Half the reason for the latter is new GUI techniques; the other half is user sophistication. The author doesn't mention either of these factors. (The solutions the author proposes have been known for a loooong time; when modal dialogs are used instead, it is after the author's preferred solutions have been considered and rejected.)
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.
This is the opposite of true. In a GUI application, components work independently and asynchronously. Click "Open" twenty times, and I'll happily throw up twenty file choosers for you, or just open a single file chooser and raise-and-focus it nineteen times. The programming frameworks make it easy to let your user open a zillion tabs and windows, and hey, the programmer doesn't have to remember which dialog goes with which tab. That's the user's burden. (This should be pretty obvious. What's better at remembering the states and relationships of dozens of different GUI components: a computer or a human being?)
In fact, a programmer's natural tendency is to make GUIs way too unconstrained. If the user decides to open a wizard in each of his ten documents simultaneously, he must have a good reason for it, right? Don't want to insult the user's intelligence. Programmers naturally imagine Gimp-like interfaces with windows floating everywhere. Navigation from feature to feature can be modeled as a completely connected graph -- perfect efficiency! No artificial flow imposed! Which should be wonderful, because:
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.
I see you've made it to common sense. Next stop: real users. Real users are the reason programmers resort to modal dialogs. Real users ignore everything, even if it pops up and flashes at them. (Forcing users to at least actively dismiss the dialog provides a little CYA for the programmer.) Real users can't look around and find the reason their current action is blocked, even if it's visible on the screen. Having it flash every time they click on another part of the application actually helps a lot.
Real users can't keep track of many GUI components. They "lose" things with alarming regularity. They file bug reports about "disappearing" components that turn out to be windows stacked behind the main application window. They click "don't show me this dialog again" for a warning about data loss and then don't understand why they're losing data all over the place. You think that before a critical job they'll double-check their preferences configuration and see which errors and warnings they've suppressed?
So yeah, it's been 26 years, but programmers haven't been ignoring known solutions for 26 years. They've been catering to real users and employing known techniques as best they can. This isn't a process of programmers slowly pulling their heads out of their asses. It's a process of users slowly becoming more sophisticated and new GUI idioms emerging at a frustratingly slow rate. Lack of appreciation for the limitations of traditional solutions is not the problem.
Why the downmod? I'll trust the author's account of his experience using Adobe products, and the kludginess of modal dialog boxes is generally accepted, but in my opinion, he got everything else wrong. As a user gripefest about Adobe products, I'd accept it, but as a a Hacker News link, I want to see some insightful generalizations.
Also, I'll add that the first article he links to (on Aza Raskin's blog) condemns modality without sufficient feedback and explains how hidden state causes users to make dangerous errors. How that applies to modal dialog boxes is not explained. Modal dialog boxes, if anything, rub the user's nose in the application state. If he had taken Aza Raskin's warnings about hidden state to heart, he would have known what's wrong with allowing users to suppress error messages about missing or invalid data.
(His suggestions would be acceptable in an IDE, but in a commercial application for non-programmers... he shouldn't be so sure the modal dialog isn't the best solution. Putting error messages in a status bar or other predictable place might be acceptable, but only if it's impossible for the user not to notice that something is wrong.
(Programmers, probably because of ego or professional pride, tend to take a lot more responsibility for their usage errors than non-programmers. Not coincidentally, they tend to design UIs that cause non-programmers grief. Annoyed users are better than users going through the stages of grief, because when they get to Anger it's going to be directed at you.)
The second post he links to is just a list of ways modal dialog boxes can be abused or done poorly. For example, modal dialogs may contain poorly formatted text, or have redundant buttons, or poorly labeled buttons, or buttons that appear active but really aren't. They may have error messages that can't be copy and pasted. In other words, it's just a checklist of mistakes programmers should avoid when writing dialog boxes. Most apply to GUI widgets of any kind (poorly formatted text? c'mon) and only a few apply specifically to modal dialogs.
So where's the beef? I've written and deployed GUI applications to real users, and I was hoping to see something here I could make use of in the future.
