Last night, I was enjoying one of my favorite snacks, peanut butter on a spoon. Not the salmonella-infested peanut-flavored Crisco that you buy at Wal-Mart, but the good stuff: organic natural creamy peanut butter with nothing but peanuts and salt. And I looked at the label and saw the following warning: "This product was manufactured in a facility that processes nuts". Now I know the placement of this absurd warning has something to do with legal liability, otherwise it would make sense. This bears a certain similarity to the way we handle homeland security in 2007.
What would the world look like if we put these warnings on software?
In a sense, I guess that's what the modal dialog box was created for. Sometimes you actually do need a warning if there is a side effect to the desired action. If I want drop a database table, I want to know before I clobber a bunch of related stored procedures and program code. More often than not, though, it is for some patronizing reason that we "interrupt the proceedings with idiocy" (as Alan Cooper puts it). "We can't just let the user do that", I've heard from marketing types. I recently had the displeasure of executing an old VB app that someone had written. It always prompts with a modal dialog whenever one decides to change MDI child windows. Why? The data had already been saved in the database - you could reboot the computer and the data would still be available. These dialogs were totally unnecessary.
The key to avoiding dialog boxes ad nauseum is reversibility. Any action needs to be undoable, or a group of actions taken as a whole need to be undoable as a group. While at Conic Systems (now Tadpole Technologies) our software implemented an "Undo Stack". This was a pretty sophisticated approach for the 1990's. You can use a design pattern called "Command" to partially implement this. Unlike the IDbCommand implementers in .NET, a good Command object has the ability to reverse itself. You place all the Commands on the undo stack, so the user can undo anything.
Undo a database record - Make sure the command object has all the information it needs to perform the delete after add, the add after delete, and the data from changed field values.
Undo a file deletion - don't delete files! Rename them and send them to the Recycle bin programmatically. That way you can get them back upon undo.
Undo a graphical operation - use the State pattern to incrementally change the state of the drawing surface and roll back to the previous state.
OK, enough of my soapbox rant. I don't care if people think I'm nuts.
Remember Me
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.