August 7th, 2012 • 5:16 pm
As people who (unlike me) have already upgraded to Mountain Lion (OS X 10.8) have discovered, while the new system brings back the “eliminated in Lion with the introduction of the Auto Save feature, it actually does so in a way that is rather misleading (at least to people used to the traditional meaning of the command) and can actually lead to data loss if you are not particularly careful.” command that was
It is a pretty sad state of affairs, but I cannot say that I am surprised about it. History had shown us that, once Apple’s engineers have made a decision about an essential part of the UI in OS X, there is just no way that they are going to track back. The reintroduction of the “” command in Mountain Lion appears to be a concession to traditional users of the command, but it is in fact a poisoned chalice, because its new behaviour will force users to adjust their own behaviour anyway, in ways that are not all that much different from the adjustments imposed by the use of the “ ” command that replaced “ ” in Lion (and is still the default command in Mountain Lion).
If anything, you cannot accuse Apple’s engineers of not following their own logic. With Auto Save (and the influence of iOS), their clear intention is to rid the world of the “” command altogether. Their apparent reasoning is that users should not have to worry about whether their work is saved or not.
The problem is, of course, as usual, with the implementation. Not only does Auto Save do things that the user does not control and that cannot be turned off (even with the use of the “” command), but in fact the ability to revert to previous states is limited to the current volume that you are using for storing your files. If you move a saved file to a different volume, its previous versions do not travel along with it. And so if you are not careful, you can easily lose these previous versions without realizing it, and so, if you used “ ” and thought that your original document had remained in its original state when it had not, and you only realize this later, after having moved that original file to a different volume, you will be screwed.
I find this highly problematic myself, and so do many traditional users of the “” command, but there’s obviously very little we can do about it, because it is quite clear that Apple will never, ever go back to a system without Auto Save. And so, perhaps those who say that, even in Mountain Lion, one should forget about trying to use “ ” and embrace the new model with Auto Save and “ ” have a valid point. There is little point in trying to pretend that things can go back to the way they were when they cannot, and if you keep using “ ” in its new meaning thinking that it has the old meaning, you are just increasing your risk of losing important data. At least with “ ” the need to revert to the original state in the duplicated original is made clear in OS X’s UI:
With “” in Mountain Lion, as far as I understand it, the need to revert is still there, but it is hidden, and this just makes you more likely to forget to do the required reverting.
Still, I would be much more willing to embrace the “” model more fully if Apple’s engineers put some effort into maintaining some of the advantages of the “ ”-based approach that can and should be transferred to the “ ” model.
As I wrote in a previous post, I have nothing against the concept of Auto Save per se. But there are improvements to the behaviour of the “ ” command that are badly needed.
For one, it’s highly problematic, in an OS that supports very long file names, to have the command automatically append the word “copy” at the end of the file name in a dialog box where the end of the file name is hidden by default unless the file name is very short, because the “” text field still remains, after all these years, of a fixed length, no matter how wide the “Save As” dialog itself is made by resizing it from one of it corners.
Take the following example. I have an existing file called “IP2222 2012-08-07 Government of Nova Scotia.pages”. It’s not such a long file name, is it? Only 43 characters… when the system supports up to 255 characters. So I open this existing file and hit “ ”, and then press “ ” to save the duplicate file under a new name. And here’s what I see on my screen (click on the picture to view it in full size):
No matter how wide I make the “Save As…” dialog, the “Save As:” field at the top remains so narrow that I cannot even see the “copy” word that OS X has automatically added to it. And so inevitably half of the time I edit the beginning of the file name and forget to edit the end part of the file name, and I end up with all kinds of files that have the undesirable “copy” word appended at the end of their file name.
It’s a regular annoyance. The traditional “Save As:” field wider, by resizing it along with the rest of the dialog box. (I submitted an enhancement request to this effect several years ago. Obviously it fell on deaf ears.) It could also add the “Copy” word at the beginning of the file name, where it is more visible and noticeable. It could even not add anything to the file name, since the file is not actually saved with the name that appears in its title bar until the user elects to do so (another rather misleading behaviour if you ask me). When attempting to save the file with the same name in the same location, the user could simply be warned that there is already another file with that name, as he already is now.” command did not trigger such a behaviour. Now, with “ ”, I am forced to deal with it on a regular basis. There are obvious solutions to this: Apple could make the “
Another annoyance associated with the “” command is that it behaves in unpredictable ways when it comes to the position of the window for the duplicated document on the screen. More often than not, when I duplicate an existing file, instead of putting the window of the duplicated document right next to the existing document window, OS X puts it all the way to the middle of my 30” monitor, or even sometimes in the middle of my secondary 30” screen! It’s absolutely maddening. And of course the traditional “ ” command never had this problem, since it saved the current document under a new name without changing the size and position of its document window.
My point here is that there are ways for Apple to make the new paradigm more palatable to users that are used to the conventional “”-based approach in their work without abandoning the new paradigm. But restoring a fake “ ” command that is not really a “ ” command is definitely not one of them.
Personally, I have created a Keyboard Maestro macro that automates some of the tedious steps that the “ ”-based approach now requires. But even Keyboard Maestro cannot do anything about the annoyances introduced along with the “ ” command, such as the ones described above. If Apple could fix these annoyances, it certainly would make it easier for a traditional “ ” user like myself to embrace the new paradigm and forget about the “ ” command altogether.