Over the last ten years or so, a new metaphor for saving data has slowly developed in some applications such as iTunes, Apple’s Address Book, iCal, and Eudora: the automatically saved document. In this model, the user rarely even sees the document as such. They simply open the program, enter new data, and close the program. There is neither an explicit open nor save step. They do not distinguish between the program and its documents.



Mostly this metaphor appears in programs that are effectively small databases. That’s probably not a coincidence. In databases, it’s customary to commit data per entry rather than per file. Another characteristic of most of these programs is that there’s one default file/database that any given user uses most of the time. You can switch to a different address book/mailbox/calendar if you like, but in practice we rarely do that. We almost always work with one master database which is, if necessary, subdivided into categories by tagging individual entries.

The complete version of this interface metaphor doesn’t fit all programs. For instance, a typical user can easily have thousands of different word processor documents and may work on dozens in a single day. Here the choice of document to edit needs to be upfront and center. However, perhaps some improvements can be made. For instance, the program could remember which documents were open when the application last quit, and reopen them automatically. Even more importantly, saving should be automatic. Why do we have to save and then close? Why not just close the document? Why is there a save step at all?

Some may object that the user might not want to save the document; they might wish to discard the changes. OK. That’s possible, but it’s not what they want to do most of the time. This is, in fact backwards. Probably 90%+ of the time the user wants to save the changes. We should make that the default. The user should have to take a special action to avoid saving changes, since they’re very rarely going to want to do that. Probably the action they should take is merely Undo. Or there could be a “Rollback” command somewhere in the menus to revert the state of the document to when it was last opened; but either way failure to save is not a substitute for undo.

To truly understand how much of an improvement this simple approach is, you have to try using such a program for a couple of days and then switch back to a more classic document based program. The reverse transition is jarring. For instance, one program that should work this way and doesn’t is the CiphSafe password manager. Every time it reminds me that I have unsaved changes, I’m jolted.

Simson Garfinkel’s SBook address book is even worse. Not only does it not save the changes unless you tell it to. It doesn’t even remind you that you have unsaved changes when you’re closing a document. It just silently throws away all your new entries! Update: that seems to be a bug in one particular path through the application that I was testing. It does confirm a close without save on most paths through the application; but I still maintain that it should simply save everything as soon as an entry is modified or added, and never bother the user at all.

There is no reason users should have to worry about saving files. Applications should save all data automatically. When a document is closed, it’s saved. When it’s opened all the changes are still there, just like when it was last closed; and the user can pick right up where they left off. It’s not that hard to do this. There’s nothing stopping us from implementing this except habit. Maybe there used to be a reason for File/Save but if there ever was, there isn’t any more. Stop annoying users with pointless dialogs and start saving files.