Worst. Name. Ever. What’s his middle name–”And”?

“Well, we just loved Bridge over Troubled Water so much…” –Mr. and Mrs. Garfinkel.

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.

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.

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.

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.

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

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

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.