Josh wrote: “Windows (and OSX) would likely benefit from testing a graphical enhancement to throwing things away by animating the icon representing the file being deleted moving to the recycle bin”.
Please, please, please don’t provide any more cutesy little animations. Those are even more annoying than the dialog boxes, in my humble opinion. Any animation screen that some UI specialist deems must be there should have a check box saying “Never show me this annoying stupid thing ever again”.
I think Adam and Reed have hit the proverbial nails with: “The Windows dialog boxes are often nothing more than liability transfers more than information. Infected? Hey, you chose to run the code.” and “Some of these options might demand a shift in how we program. For example, if a dialog is to be non-modal, you can’t just call Show() or whatever and have it block until the user makes a choice, you need to set up callbacks or use predicate programming or some other more complicated thing.” respectively. However, these are, IMHO, merely symptoms.
Having been a developer and a requirements writer I believe the problem with message boxes popping up is many fold (or is that manifold?). Requirements writers are often too lazy or lack the technical expertise to think through all the possible use case paths - we write about the main success scenario [see Alistair Cockburn in “Writing Effective Use Cases”] and maybe one or two alternate outcomes. We then naively hope that the developers, with their skill for detail, will spot the missing outcomes. Unfortunately, the developers either don’t spot them or do spot them but don’t raise the issue having been conditioned by us to not do that through years of us whining to their managers about nit-picky developers who have pointed out “nit-picky” little errors in the spec. Then, when the code is being built and the path that nobody thought of arises, all too often we, the developers, (note: I’m changing roles here) are too lazy to get up out of our chairs and go discuss with the requirements writer what to do in this situation. We may have already invested a lot of time hacking out the code that we never really designed and we don’t want to have to rewrite that so we solve the problem by inserting a message box and then explain it to QA and the product managers as necessary or by design or too expensive to fix.
The problem is not the use of message boxes; it is the fact that in altogether too many projects, error handling and scenarios other than the main success scenario are ignored until the code is being written. The result is that unusual paths through the code are handled in an ad hoc manner that is annoying to the end user or brings the product crashing down or logs some informative message like “Unable to open Window handle. Consult your administrator” which may accurately describe the problem but doesn’t actually describe the problem.