Autosave Considered Helpful
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.
October 3rd, 2006 at 12:29 pm
Emacs is a text editor that does automatic saving every few minutes (seconds?) or keystrokes. But it does it with a different file name, so the original version is not clobbered through this automated process.
Also, it can rename the previous version on manual saving, so you can keep all the different versions of a file throughout its life, if you wish. Or only the last n versions, if you prefer.
And emacs has been around for decades, so the concept is not new. But it takes elbow grease to implement all this, so I can understand why is not more widely done.
What would be nice is to have a packaged solution. So, if you write in Java, you could delegate all the file interaction to an external jar that would have all this functionality already built in.
October 3rd, 2006 at 1:04 pm
What you describe emacs doing is autobackup, not autosave. The user still has to explicitly choose or confirm the saving of the actual file. What I’m proposing here (and what some applications already implement) is removing that task from the list of things a user must do. This requires two things:
1. The application never bothers the user with the question, “Do you want to save?” or gives the user any sort of Save command. Save As is different, less common, and OK. Sometimes the user will need to tell the application where to put a file, usually just the first time a file is saved, and maybe in some other unusual circumstances such as editing a file on a read-only disc. But in general the application should assume the user wants to save the file and not even ask them.
2. The application must save when a document is closed or the application exits, not merely at some predetermined time interval. The SBook bug I described above appears to be a problem with an autobackup scheme not kicking in fast enough.
October 3rd, 2006 at 2:24 pm
> 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.
Or we could just have the application version-control it’s saved files (this and the ability to diff would be invaluable in word processors, and is one of the reasons why I use LaTeX instead of a “regular” word processor)
(and yeah I know that there are diff tools for MS Word files, but still…)
October 3rd, 2006 at 7:54 pm
Actually, of all the Word and Excel documents I open in a given week, I only want to modify about 5% of them. I’m only opening them to view, but it’s not as easy to open them read-only as read-write. In those cases, I don’t want changes saved. And with MS apps, it’s all too easy to make “changes” to a document just by opening them, say with a different printer (since font metrics are printer based).
Undo isn’t the ideal way to handle this, because we don’t yet have an effective interface for document-lifetime undo. On the programs that do autosave right now, there’s basically no undo to worry about. But how would you negotiate then undo of several days (let alone weeks) of changes on a Word doc?
October 4th, 2006 at 2:43 am
I tend to disagree. If you make saving automatic you give the impression that changes are written to disk as they happen. This leads to two possibilities:
1. Changes /are/ written to disk as they happen, or with some small amount of performance caching. I (and I imagine many other users) prefer to have the disk-based version in a consistent state. I want to save every time I make a significant, meaningful change. I *don’t* want to save in the middle of a change when my document is inconsistent.
2. Changes /aren’t/ written to disk as they happen. Thus, changes are only ever saved on shutdown. If the application should crash, I lose everything I have done today. If autobackups are made (as in emacs), I’m back to the previous problem where the last saved document may be in an inconsistent stage in the middle of an edit.
This article also assumes that you are editing a document rather than the input for another application or tool. For example, if I’m writing source code I may want to run it without the changes once and then immediately afterwards with the changes to ensure that I haven’t broken anything. This requires some measure of control over the saving process.
Part of a software user’s responsibility is ensuring that his data is in the state he wants it. By removing the ability to save data as and when required, we disempower the user. Sure, it may be great for the common case, but I am not the common case. Dumbing down my software to “make things easier for the newbie” and *preventing* me from doing what I want to do is far worse than requiring the “basic user” to learn to perform a fairly trivial operation and making him responsible for his own data.
Oops, I seem to have slipped into something of a rant at the end there. I just see way too much software out there that favour slick, dumbed-down interfaces that are impossible to automate and frustrating to use beyond the basics.
October 4th, 2006 at 4:09 am
The e text editor does kind of a hybrid approach of this. All changes are persistent so if the computer (or the program) should crash while you are editing, it will just resume where you where when you start it up again.
But most people like to have full control over when their changes are saved to the actual file on disk. There are a few valid reasons for this, but almost all of them would be satisfied if the app made it really easy to “revert to last saved”.
It would arguably be better if the applications just handled saving for the user. But the main reason that they do not, even though it has been promoted by lots of usability experts, is that people are creatures of habit. The have gotten used to apps always asking them if they want to save their changes. So if there suddenly is a singular app that does it silently, they get uneasy. Wondering if their changes was actually saved.
To change peoples habits would probably require some really popular app to lead the way.
> Undo isn’t the ideal way to handle this, because we don’t yet have an effective interface
> for document-lifetime undo. On the programs that do autosave right now, there’s
> basically no undo to worry about. But how would you negotiate then undo of several
> days (let alone weeks) of changes on a Word doc?
I have written an article on how undo can be improved so that it is useful for the entire document lifetime here: http://e-texteditor.com/blog/2006/making-undo-usable
October 5th, 2006 at 6:48 am
Hi,
I’m pretty much with you on this one Rusty.
In the world of IDEs IDEA does just that and it’s truly good.
But I believe it is good mainly because it internally stores a history of all modifications made on the files so that you can go back in time if needed
October 8th, 2006 at 6:13 am
I agree totally with Elliotte Rusty Harold but at the same time have the “Word problem” described by Alan Shutko. But the problem is with Word not the Elliotte Rusty Harold scheme.
I am terribly annoyed every time Word asks “Save changes?”. What changes? I did not change a bit. I just viewed. Or did I? Grrrr. With the Elliotte Rusty Harold scheme and some sort of automatic revision control it would be much better. The editor should be able to guess when I started the last major edit and be able to revert to that.
When I edit documents in Word Ctrl-S is in the fingers all the time — I do not even notice it anymore.
October 18th, 2006 at 9:28 am
Digital’s EDT text editor (1970s and later – http://en.wikipedia.org/wiki/EDT_text_editor) would auto-save, AND after an auto-save, every keystroke would be logged to disk. I think this was called the “journal” and would go into a .jou file. I can’t remember if it would log after every single character, or dribble them out when CPU wasn’t being used.
So in case of a crash, the auto-saved file would be re-loaded, and the keystroke stream would be applied; so, typically, you’d be within a character or two of where you left off.
It was routine to set EDT to re-open the last open file. So the file opening / saving would be virtually transparent.
October 18th, 2006 at 10:23 am
Google spreadsheets autosaves. I lost several hours of work because of that feature when undo failed. Also, there’s no history so there is no way to go back to previous versions and even if there was, they save per cell entry so some list of 1000 edits on a 2 hours span would be useless if I want to go back to the version just before I started working on a certain part. Unless I get to choose “save version” and add a label to that version then the autosave.
My suggestion though is try it. At least all the MS products as well as most programmer editors are scriptable so go and add autosave and see how you like it.
October 18th, 2006 at 5:07 pm
Hypercard for the Mac, back around 1987, had auto-saving. That was somewhat like a database, in that data was segregated into small chunks. If you wanted to save the document’s state, you would save a copy of the document. If you wanted to make the document read-only, you did it via the file system’s read-only bit.
It was pretty easy to learn new habits to work with this model. You just save a copy before embarking on major changes. I tended to save a lot of copies when I was working on something. It may have had some kind of naming feature to put the copies into a sequence, but, I don’t recall. Overall, it was superior to saving files.
For most sitautions, auto-save is totally correct. The feature people really want is “save this version”, which saves the present version. People in offices already do “save this version” in an ad-hoc way, by using “Save As…” and renaming the file.
October 19th, 2006 at 2:16 pm
Simson Garfinkel
Worst. Name. Ever. What’s his middle name–“And”?
“Well, we just loved Bridge over Troubled Water so much…” –Mr. and Mrs. Garfinkel.
November 20th, 2006 at 6:37 am
My colleague, Brian Donohue, just posted on Google spreadsheets vs. Microsoft OneNote and the different approaches to auto-save. Worth a read
December 30th, 2008 at 10:05 am
[…] particular I want to enable autosave instead of confirmation. This is a really useful, nice free product. It just has that one annoying […]