A user spends an hour working on a document. Because he/she is stressed, or under duress, they don’t remember to save their document, and when closing Word, reach the familiar dialog box: Do you want to save the changes to Document1? Still harried, they accidentally click the ‘No’ button, and lose their document. Because the software can’t decipher the user’s intentions, they simply obey what they are told, and don’t save the document.How can we address this problem? And is it a problem? I imagine so - as much fun as it is to blame the user, telling them they should have saved their document at the beginning, or telling them to save religiously every 10 minutes or so, this problem can be approached from a few directions in the areas of interface design or software design.Note that this post is not to address autosaving documents that already exist, as most text editors, as well as Word, already have excellent functionality in this regard. On the HCI front, we have:
Tinted Aid
Imagine this one simple change - tint the colors of the buttons on the dialog box. Green for yes, red for no. This one thing might give a user pause enough to consider their option more slowly. After repeated use, the colors may help to guide the user’s cursor, to enforce the habit of saving.
Second Action Aid
This change adds another button to the dialog box - making it more complex, but not an impossible change. The new button is a lock icon that sits next to the No button, and controls the enabled/disabled state of the No button. In order to click No, the user must first click on the lock. Unfortunately, this has the potential to become the same problem that we are trying to fix - namely that users who get used to taking a certain action will think about it less in the future. An absentminded user could just as easily make a mistake by clicking two things without thinking as clicking one.
Some other changes that might help, but would increase the complexity of the software:
- Adding a Firefox-like race condition timer to the dialog box, of 3 seconds or so, that would not enable the ‘No’ button on the dialog box until the timer runs out.
- Attaching a specific gravity to each button on a dialog box depending on its function. The Yes button here may physically pull the cursor to it with a stronger amount of resistance compared to the No box. I imagine, however, that users do not want their computers telling them what to do to that degree.
In terms of non-HCI concepts, we have the backend. Word utilizes AutoRecover, which is useful for accidents—power loss or the like. However, if a user never saves a file and exits Word without saving, the chances are very low that they’ll be able to recover that document. So what are our options?
- Individual incremental version control for all saved and unsaved documents. Every 10 minutes or so—or if a minute goes by without a keystroke—a commit is made to version control with that document’s changes. If the file is not named, it is provided with an identifying filename - such as its time of creation and the name of the user and computer.
That’s the only thing I can think of at the moment. Of course this sort of idea comes with enormous privacy concerns, and even if we explained to the users exactly what was going on, they may still be used to being able to open a document, write a nasty letter to their bosses, then close it without saving, thinking their secret is safe :-) The other disadvantage of this approach is that is users become accustomed to that kind of behavior in one program, they might be very surprised to find that other programs do not have the same functionality, and end up losing data over that misunderstanding.
I would be remiss if I didn’t mention how Linux users have been dealing with this problem for ages. In Emacs, a buffer is named before it is ever edited, since the command to open a file can also open files that don’t exist yet. It’s at that point that Emacs begins saving backups of that buffer. In vim, quitting and quitting without saving are two different commands: q and q!, respectively; or qa and qa! for exiting all documents. Since it would be extremely difficult to make the mistake of typing an exclamation point—at least in terms of a typo—the only issue here is that of muscle memory, and I imagine most programmers do not usually type the latter enough for it to become ingrained to that point.