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.