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.<p>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.<p>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.)<p><i>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. </i><p>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?)<p>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:<p><i>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><p>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.<p>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?<p>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.