MRR Software

There was much ado on Twitter today that warnings within an application are, at best, passé.  It has come to pass that many developers feel warnings have become so ubiquitous that users no longer read them, regardless of content.  I was nearly alone in my conviction that warnings not only have a place, but can be necessary within an application.  Apple’s Human Interface Guidelines suggest: “Warn users when they initiate a task that will cause irreversible loss of data.”  I’ve taken that thought a littler further.  My ardent belief is that a user should always receive a warning dialog if the following three criterion are met:

1. Data is lost
2. It takes non-neglible time to manually recreate the lost data
3. The lost data will affect future runs of the application

All of these criteria deal with data.  Nearly all applications exist solely to process and store data.  When a user enters data into an application it, and by extension the developer, becomes the guardian of that data.  It is up to the developer to ensure that the data is safe, that we keep it from harm.  And the same time the user must be allowed to create, destroy and modify their data as they choose.  Every operation that a user performs on their data involves a certain amount of risk.  Here risk will be defined as a situation invloving exposing the user’s data to danger.  Most interactions have very low risk, including creation, modification and viewing of data.  Conveniently these are the most common types of interaction with data.

Deletion is the odd man out, for all his low risk brethren, deletion has significant risk.  It is the complete loss of data.  Some applications will allow deletions to be undone, a very effective catch all for accidents, or for rectifying a misunderstanding between user and application.  But the ability to undo a mistake is not a replacement for preventing it to begin with.  An ounce of prevention is worth a pound of cure.

Many have suggested that Undo is a magic cure-all for deletion, this is a fallacy.  Undo is only good until the program exits.  In the case of accidental deletion, where the warning dialog truly shines, the user will not know they need to undo it.  Maybe they thought a different window had focus, maybe they fumbled a keyboard shortcut, or maybe their cat had a nap on the delete key, doesn’t matter.  Once that application is quit, that undo memory is gone, as is the user’s data.  At this point Time Machine or backups (either user or program initiated) are the last hope.  If any part of your application’s workflow relies on the fact that there should bebackups, you have failed.  This is why my second criteria states that it takes non-neglible time to manually recreate the data.  Don’t rely on backups and undo.

It is important to realize that not every deletion require warning, as not every deletion has the same level of risk.  I have adopted both approaches in my applications.  NameChanger’s toolbar prominently displays Remove and Clear buttons.  Remove deletes the selected filenames from the table and Clear removes all entries from the table.  Neither of these deletion operations spawn a warning.  Isn’t data being lost, why not warn the user?  Let’s see how it matches up to my criteria.  First there is no true loss of data, a filename is removed from a table, nothing more.  Second it would take longer to warn the user then for the user to manually re-enter the data.  Thirdly, nothing is persisted between runs, so quitting after removing a filename has no impact on future runs.  The data, in this case a filename, is only a short file browse away.  The risk is not great enough to warrant an interruption of the user’s workflow.

Now the other case: the next release of Syrinx will contain a List management window.  A Twitter list is a user-defined set of Twitter friends.  A user can have multiple lists each containing up to 500 members each.  When attempting to delete a list Syrinx presents the user with a warning.  Why give a warning?  Back to the criteria.  First actual data is being lost, those lists and members are deleted from Twitter’s servers.  Second, it can take a significant amount of time to recreate the list and it’s contents, assuming the user can remember it all.  Third, since the data is persisted, the deletion affects future runs of the application.

I challenge developers to apply these criteria to their own applications to determine when and where warning dialogs are appropriate.  Don’t jump on a UI bandwagon just because it’s rolling through, determine what is right for your application.