Aza Raskin explains why warnings should never be used when you mean undo. Warnings make the user cautious about the action, which takes more time to resolve and can be frustrating for the end user. A guarantee of undo can provide a sense of security and let the user take direct actions. If required, the user can undo to the previous stage. A warning introduces decision points and puts the responsibility on the user, and the undo gives post-event facility to rollback and puts onus on the software. No wonder warnings are technically easier to code for than undos.
A very good article, however I felt the discussion was incomplete because it only gave examples and no conceptual guidelines. How can a designer decide when to use undo? When to use warnings? I am sure it is true the other way too, do not use undos where warnings are required. How do we decide what to do when?
I feel that all workflows have a point of no return, where the user commits to the action, at which warnings are necessary for the user. The consequences of errors at these points of no return are more damaging and the software has to make sure that the user is doing so consciously. Using Aza’s example of a trashcan, there is a point where the user can or has to empty the trash can. This is where the data gets purged and is a point of no return. Another example is buying something from an e-commerce site. You can go on adding and deleting the contents from your shopping basket, but the checkout is a point of no return. Of course there are return policies, but that is not an undo of the transaction, it is a separate transaction.
Undo is not just a matter of rolling back the task, it is about rolling back effects of the task. That is the reason a checkout is not allowed to be rolled back, even though an email deletion can be. On the other hand, a version control system too can be considered as a undo mechanism where a user can rollback a set of modifications by going back to an older version of choice.
I have tried to use this practice of identifying the points of no return in the workflow. As a good practice, I try to use buffers, like the trash cans or the shopping baskets or the undo stack for as long as possible so that the point of no returns are minimized and postponed.
One of the biggest problems of using computers is that they cannot understand whether a user really wants to do something. Warnings and confirmation messages can be one way of making sure of that, but they are intrusive. Using undos and warnings in the right places can help reduce the friction.