Disks used to be slow, and saving all changes made to disk was untenable. The solution was to force the user to explicitly save, and we all got used to manually saving every 5 minutes.
Now, especially with SSDs, saving every single change as it’s made is viable, and so Apple are pushing ahead with that paradigm: what is on screen, is what’s in the document.
This is a pretty big change of paradigm from the traditional model, and change is hard. But it makes a lot of sense.
However, that means ‘save as’ doesn’t do what’s expected. In OS X Lion if you want to make changes to a document without losing the original, you have to ‘duplicate’ (which is the menu option that’s replaced ‘save as’), and then make your changes. This completely makes sense if there’s no need to ‘save’ anymore; if you don’t want to change this copy of the document, make a new copy to make your changes in.
This year, in Mountain Lion, Apple added back a semi-secret ‘save as’ command, and there was much rejoicing. But then everyone realised it doesn’t have the old behaviour, and the howling increased.
But how could it have the old behaviour? There’s no staging of changes that your making on screen, before they’re committed to disk – that abstraction has been taken away. As soon as you start changing a document, those changes are committed. If you want to go back, you have to revert to the old version (and there’s a menu option to do that). Selecting ‘save as’ doesn’t pull those changes back off the disk; that would be confusing.
I think the daft thing Apple did was adding ‘save as’, as if it’s different to ‘duplicate’, especially since it doesn’t work like ‘save as’ did in the past.
Many are framing this as a ‘consumer-focused’ change; poor consumers can’t understand the save model, and are used to their iOS and Android devices that don’t have ‘save’. I don’t think this is the case at all, and it’s knee-jerk reaction to change. The fact is, hardware has matured to the point where we don’t have to worry about some stuff we used to worry about.
