I'm confused. All it does is make the "bad" behavior the default, but give you the option to revert it if the original file exists somewhere on disk? That's an improvement?
Versioning (and allowing reverts) is awesome, but changing a decades-old idiom to something that suddenly destroys data is...well, scary, to say the least.
Edit: Someone further down the thread suggested that the function be renamed to "Duplicate and Save". That would totally fix the problem - this is a new interaction mechanism, totally different from what we've all been training on for the last thirty years, and it needs a new name. The feature itself is fine, but hijacking an existing operation's name for it is not cool. It violates the principle of least surprise.
I'm not sure there was a way to introduce auto-save while maintaining the "principle of least surprise". I'm astonished, myself. I figured that, thirty years from now, we'd still be losing changes to periodic crashes of unsaved documents rather than force any customer to alter a decades-old workflow.
The problem with "Duplicate and Save" is that it implies that saving is an action that you can take, rather than something which has already happened. As arrrg said, that's not true: in Lion apps, every document which has a name is always saved. There is no longer a state of "changed but not saved".
Change the label to "Duplicate and Save" and us old folks, trained for thirty years to be constantly seeking and pressing "Save" lest we lose everything, will be complaining that there's no way to "Save" without also "Duplicating". Which would not promote understanding, either.
Don't worry, if you and the OP miss the old world of unsaved documents you can always find some old-school applications that preserve the old behavior. Join us Emacs users in the land of hoary UX paradigms! ;)
Sure, you can have auto-save without surprising the user. Auto-save to something that isn't the file they opened, and the commit those changes when they invoke "save". The UI itself can show whatever the latest version it has (and offer nifty things like "compare with what's saved"), but the file itself isn't written until the user asks it to be.
I'm not sure what word processing software you've been using for the past decade, but periodic backups and automatic restoration is more or less the norm, now. Heck, even my code editor persists unsaved buffers between sessions.
I think the last time I lost unsaved work in a due to a program crash was probably last millennium. That's the root of my surprise here; there are proven solutions that don't break existing workflows. Why did Apple decide to break them now?
I figured that, thirty years from now, we'd still be losing changes to periodic crashes of unsaved documents rather than force any customer to alter a decades-old workflow.
Huh?
Word and Open Office have been recovering crashed documents, including unnamed, never-saved-documents, for quite a while. When that happens, it is a little confusing since you have to overwrite the existing document with the later version. But it also only occasionally happens whereas I often use the save-as functionality.
Versioning is always happening. It’s not possible for you to be not able to revert.
Also: “Save as …” is a deprecated feature (basically). You can’t even see it in the menu. There is only a keyboard shortcut for it – for those traditionalists who can’t let go. It’s not going to make the new document model worse (which is a massive improvement over the past) just to keep “Save as …” working.
Documents always save. They never not save. You can easily revert or access versions. You can easily create new versions (for example by clicking “Save” in the menu or by pressing Command+S). You can easily duplicate and immediately rename documents.
Versioning (and allowing reverts) is awesome, but changing a decades-old idiom to something that suddenly destroys data is...well, scary, to say the least.
Edit: Someone further down the thread suggested that the function be renamed to "Duplicate and Save". That would totally fix the problem - this is a new interaction mechanism, totally different from what we've all been training on for the last thirty years, and it needs a new name. The feature itself is fine, but hijacking an existing operation's name for it is not cool. It violates the principle of least surprise.