The Very Model of a Modern Mountain Lion Document
In the recently released OS X 10.8 Mountain Lion, Apple has done something I thought they’d never do: they backtracked — sort of. They heeded the objections of users to a major feature of 10.7 Lion, and took steps to meet those objections. They didn’t remove the feature — that, I suppose, would be asking too much — but they changed the interface and provided an increased range of user choices and capabilities.
In this article, I’ll sketch out how Mountain Lion is different from Lion with regard to this feature, and why, therefore, I personally like Mountain Lion much more than Lion. For more detail, and for lots more about Mountain Lion, see my book, “Take Control of Using Mountain Lion.”
The Lion Situation — The feature in question, which Apple calls the Modern Document Model, is the way documents are saved and handled by applications that have been appropriately rewritten to adopt certain technologies introduced in Lion:
- Auto Save, the heart of the Modern Document Model, means that documents open in these applications save themselves automatically as you edit them. You can still save a document explicitly; but you can, in theory, work with a document in a Modern Document Model application without ever saving it explicitly — except, perhaps, at the outset, when you save a new untitled document to assign it a name and a place in the folder hierarchy.
In Lion, the black dot in the document window’s red close button, familiar to users from years of previous Mac OS X systems, never appears; a document is never “dirty” (in need of saving), because it is always being autosaved. Moreover, for the same reason, when the document is closed, no “Save changes?” dialog appears. (There’s one exceptional situation where such a dialog does appear in Lion, which I’ll describe in a moment.) The word Edited appears in the title bar of a document that has been changed since it was opened or explicitly saved, but many users don’t find this a sufficiently strong cue.
- Resume is the capability of an application, when launched, to reopen automatically all the windows (especially documents) that were open when that application was running previously. Lion allows you to toggle this behavior globally or when quitting a particular application (though, as I pointed out in “Lion Zombie Document Mystery Solved,” 23 May 2012, under certain circumstances an application’s windows might be resumed on launch even when you’ve set them not to be). Resume is tightly integrated with Auto Save; with both of them operative, Mac OS X is clearly trying to imitate iOS, where ideally one should not be able to tell the difference between switching to an app
and relaunching it after it has been terminated.In Lion, if you quit a Modern Document Model application with a new untitled document still open, that document is automatically saved (Auto Save) and automatically reopened the next time the application runs (Resume), regardless of your Resume settings. But if you close a new untitled document explicitly (with File > Close or by clicking the window’s close button), a dialog appears (“Do you want to save…?”) where you can either save the untitled document or dismiss its unwanted contents once and for all.
-
Versions is the capability of the system to record the current state of an autosaved document so that you can later retrieve that state. To some extent, such states are maintained automatically. Additionally, in Lion, once a document has been saved (so that it is no longer a new untitled document), the File > Save menu item is replaced by File > Save a Version; the document is being autosaved constantly, of course, but choosing Save a Version not only saves, but also causes this particular state of the document to be stored in the Versions database.
In Lion, access to the Versions database is chiefly through the File > Revert Document menu item, which brings up a Time Machine-like interface showing all saved states of the document. One particular document state — the state of the document when last opened or last saved — might also be accessible by choosing from the document’s title bar menu.
-
The File > Save As menu item, to which users have been accustomed since System 6 (or before), is absent in Lion. In the case of a new untitled document, it is redundant, since File > Save performs the same function, giving the user the opportunity to assign the document an initial name and folder location. In the case of a previously saved document, its functionality is replaced by that of File > Duplicate, which copies the current document’s state into a new untitled document, without closing the original document. The user can then save this new document (giving it a name and folder location).
The Trouble With Lion — Lion’s Modern Document Model constituted a revolution in how users had to work with documents through applications, and for many users, it wasn’t a revolution they liked. Unlearning the habit of saving whenever you think of it, lest your work be lost if the application crashes, was easy; the heart of the problem had more to do with accidents.
Who hasn’t quit an application, supposedly without having altered a document, only to see the “Save changes?” dialog appear unexpectedly? It turns out that you did alter the document, but by mistake; you thought you were copying, perhaps, but you cut instead, or the cat prodded the keyboard while an important paragraph was selected. That dialog warned you, and rescued you, letting you cancel those unintended changes. Under Lion, there is no dialog and no warning; your accidental changes are saved without your knowledge and possibly contrary to your desires.
Auto Save in Lion, users objected, was thus a potential trap, an invitation to cause the very thing it was supposedly designed to prevent — accidental data loss. The data might not really be lost, since the Versions database might hold an acceptable earlier state of the document; but finding that state in the clumsy Time Machine-like interface wasn’t easy. And what if, after saving a problematic change that you weren’t even aware of, you closed the document and didn’t return to it for days, perhaps weeks, opening it later only to be horrified and confused? Would Versions help you understand what had happened? Would the database still contain the desired document state? It all seemed so backwards, somehow: first make a
drastic accidental mistake, then later discover it (if you’re lucky) and scurry around trying to fix it — whereas, prior to Lion, you would have been alerted before making the mistake of saving the faulty document in the first place.
Then there’s the matter of experimentation. Who hasn’t deliberately played with a document experimentally, knowing that no harm would be done if things went wrong, since you could easily close without saving at the end, or spawn off your unsaved changes into a different document with Save As? Now Lion comes along and saves your experimental changes behind your back and against your will. Lion doesn’t really prevent experimentation, of course; all you have to do is choose File > Duplicate, and now you’re working in an unsaved copy of your document, which you can ultimately close without saving. But here again, things seem to be backwards, since you must remember to choose File > Duplicate before you
experiment; you might easily forget to do that, or you might not realize, until it’s too late, that your changes are undesirable.
Mountain Lion to the Rescue — What Mountain Lion brings to the Modern Document Model mix are two checkboxes, in the General pane of System Preferences, that affect the behavior of applications when documents close, along with some new menu items. Let’s start with the two checkboxes:
- “Ask to keep changes when closing documents.” If this checkbox is unchecked, Mountain Lion behaves like Lion. If checked, though, Mountain Lion behaves more like Snow Leopard and before: The close button’s “dirty” dot returns! The warning dialog appears when you close a “dirty” document! So, in Mountain Lion, the chances are not as great as in Lion that you might accidentally keep unintended changes in a document.
Note, however, that this checkbox does not turn off Auto Save; your document is still being saved automatically behind the scenes! The warning dialog asks “Do you want to save the changes…?” and its default button is labeled Save; but in fact the document has already been saved, and what you’re really deciding is whether to keep those saved changes or to revert the document to an earlier state (preserved, of course, in the Versions database). So Auto Save is still operative, but the
interface gives the illusion that it isn’t. -
“Close windows when quitting an application.” This second checkbox is a little tricky, in that it actually does two things: (1) it determines whether Resume is turned on or off globally, and (2) it determines whether quitting an application counts as closing its documents, as far as the first checkbox is concerned.
To see what I mean, suppose first that this second checkbox is unchecked. Then when you quit an application with open document windows, those windows just vanish with no warning dialog, even if they represent “dirty” documents. In a way, by unchecking this checkbox, you’re saying: “Quitting an application is different from closing its document windows one by one. When I say quit, I mean quit now, without waiting around for any dialogs.” This is true even if the first checkbox (“Ask to keep changes when closing documents”) is checked — because, according to this second checkbox, quitting an application doesn’t actually count as closing its documents! Instead, the state of those documents is automatically saved
(Auto Save), and the documents will be opened again automatically (Resume) the next time the application launches. (Note that if the first checkbox is checked, then when these documents are automatically re-opened, their “dirty” state is remembered from when they were closed: if they were “dirty” when you quit the application, they reopen with the “dirty” dot still present in the close button.)If, on the other hand, this second checkbox (“Close windows when quitting an application”) is checked, then when you quit an application with any “dirty” document windows open, those windows fall under the power of the first checkbox (“Ask to keep changes”). So, if the first checkbox is also checked, then when you quit an application with a single “dirty” document window, you’ll see the “Save changes?” dialog, and when you quit an application with multiple “dirty” document windows, you’ll see the familiar Cocoa dialog asking: “You have … documents with unconfirmed changes. Do you want to review these changes before quitting?”
Moreover, if this second (“Close windows”) checkbox is checked, Resume is globally turned off. But let’s say that you hold Option while quitting. This turns on Resume temporarily, and things then work as if this checkbox were unchecked: you’re saying, “Quit now, darn it!” So the application quits instantly, even if the first checkbox is checked, and even if some open windows are “dirty” documents (and, the next time you launch the application, those windows are reopened automatically and their “dirty”
state is remembered).
In addition, Mountain Lion’s Modern Document Model provides the following menu items:
- File > Save is now always File > Save; it doesn’t change to File > Save a Version. Of course, saving a previously saved document does still save a version; but the unchanging menu title simplifies things.
-
In addition to File > Duplicate, which is still present from Lion, the File > Save As menu item is back; in fact, the latter is an alternative to the former (hold Option to see it). This gives users a choice of working in whichever way feels comfortable and appropriate to the circumstances. File > Duplicate copies the current document as a new untitled document, leaving the current document open behind it; File > Save As, similar to pre-Lion systems, lets you create a copy of the current document with a new name and location, with the document window showing the copy rather than the original.
-
File > Revert To (instead of Lion’s File > Revert Document) is now a hierarchical menu item: its subitems, depending on the circumstances, may include Last Opened, Last Saved, and Browse All Versions, thus focusing on the most common use cases and clarifying your options.
-
Last but not least, there are two completely new menu items in Mountain Lion. File > Rename lets you rename a document in place; File > Move To lets you move a document to a different folder. These are actions that previously you might have performed on a file from the Finder; now you can perform them on a document directly from within the application that has the document open. Both these menu items are so useful that one is left wondering how we lived without them in previous systems.
All of these menu items are present not only in the File menu but also in the document window’s title bar menu — except, oddly, for Save As, which is thus unfortunately reduced to second-class status and is unnecessarily difficult to discover.
(I should also mention one further change. In Lion, a document would be locked automatically if it wasn’t edited for some amount of time, such as two weeks; in Mountain Lion, this autolocking behavior has been withdrawn. You can still lock a document by choosing Lock from the title bar menu, but this is no different from the capability the Finder has always had to let you lock a document.)
Conclusions — For me personally, these changes have made Mountain Lion usable and acceptable in a way that Lion was not; and I expect that many users will feel the same way. I’m particularly impressed with Apple’s willingness to provide users with options, something that in the past I’ve frequently called upon them to do. The two General preference pane checkboxes enable users to make Mountain Lion either keep on behaving like Lion or simulate the pre-Lion document behavior with which they may feel more comfortable and confident. Similarly, I like being able to choose File > Duplicate or File > Save As, depending on the nature of the task at hand. And I think
Apple’s rejiggering of the File menu items, especially the new Rename and Move To items, is just splendid.
Please note, though, that I’m not claiming to be entirely happy with the Modern Document Model. Actually, to be quite honest, in my view, Auto Save is itself a massive mistake, an utterly erroneous pretense that the desktop is like iOS. Its deeply flawed nature is well revealed by what happens when you edit a file on a mounted remote disk: you get Auto Save without Versions, which even Apple has admitted is troublesome; see Adam Engst’s article on this topic, “Beware Lion’s Versions Bug on Network and Non-HFS+ Volumes” (8 September 2011).
Also, complications are added by the presence in Mountain Lion of “Documents in the Cloud” — the capability of some applications to save their documents where iCloud can synchronize them. I don’t want to get into details here, but suffice it to say that if an application is iCloud-savvy, its various Modern Document Model warning dialogs and its Open and Save dialogs look different from those of an application that isn’t iCloud-savvy. We thus end up with a three-way “Balkanization of the desktop”: applications that don’t subscribe to the Modern Document Model, those that do but aren’t iCloud-savvy, and those that do and are iCloud-savvy. Each of these looks and behaves differently from the others (see my “Take Control of Using Mountain Lion” for details).
While I’m in a complaining mood, I’d also like to mention my reservations about that second checkbox, “Close windows when quitting an application.” As I’ve said, this really does two things — it toggles global Resume on and off, and it changes whether quitting causes a document window to fall under the rubric of the first “Ask to keep changes” checkbox. But those two things, while related, aren’t strictly identical, and the title of the checkbox doesn’t describe either of them very accurately. The result is that it’s hard to understand just what this checkbox does; even the usually scrupulous John Siracusa seems to miss its full significance in his technical review of Mountain Lion, and I myself accidentally omitted part of the story in my Take Control book.
And Apple hasn’t quite implemented the first checkbox correctly, either. It says, “Ask to keep changes when closing documents,” but if you open and edit a document and then choose File > Save As (surely the most common use case for Save As), the original document is effectively closed without asking you about those changes; the new file contains the unconfirmed changes, which makes sense, but so does the old file, which is clearly a violation of your request to be asked about changes. Oddly, this is something Lion did somewhat better than Mountain Lion: in Lion, when you chose File > Duplicate on an edited document, you got a dialog offering a chance to revert before duplicating; that dialog no longer appears in Mountain
Lion.
However, all of that aside, I would still submit that the changes to the Modern Document Model in Mountain Lion are welcome, ingenious, and extraordinarily significant. I would still prefer a way to turn off Auto Save altogether; but if we stipulate that Apple will never allow that, they have bent over backwards to make Auto Save acceptable to a lot more users, even if they still haven’t got everything quite right. I cannot sympathize with an attitude like that of David Pogue, who, in his New York Times article introducing Mountain Lion, rightly calls Lion’s Auto Save “baffling”, but then
dismisses the Mountain Lion changes to the Modern Document Model as consisting only of a couple of menu items and assigns them a negative value. Those changes are the main reason, I argue, for preferring Mountain Lion to Lion, and might even entice users who never really updated from Snow Leopard to Lion (in which number I include myself) to make the switch to Mountain Lion more or less full-time.
I have followed this issue as commented about by several authors. While I am a David Pogue fan, I agree with your take on saving in Mountain Lion. More importantly, this article is the best synopsis I've read of what's going on and how to live with it. Thank you.
Thank _you_, since that ("the best synopsis") is exactly what I was aiming at here. All judgments aside, what I'm really trying to do is clarify how Mountain Lion behaves in this regard, since I haven't seen it described correctly anywhere else.
Ok, I'm confused. You might try a flow chart or table to explain the effect if the two check boxes.
Note that by using System Preferences->Keyboard Preferences->Keyboard Shortcuts->Application Shortcurs->All Applications, you can make 'Save As…' replace 'Duplicate' in the File Menu by redefining the Shift-Command-S as 'Save As…' and Option-Command-S as 'Duplicate'.
This doesn't change what appears in the drop-down menu from the title bar.
That would also change the shortcut for duplicating files in Finder and the one for duplicating objects in Pages.
The command to duplicate files in the Finder is Command+D.
If you don't find it challenging to save your documents yourself, here's how to disable Auto Save and Versions:
http://apple.stackexchange.com/a/52390
Risky; I can't advise doing that.
I must be unique in having been very pleased when Lion introduced Auto Save. That finally brought back to me, as a long-time user of computers (since 1969) a feature I had last seen in Digital Equipment's VAX/VMS of 1978, which included both automatic saving (at a user-settable interval) and file version numbers (new version each time the document was explicitly saved). Nice to see a good idea re-implemented.
That said, I also understand the confusion that could result from the three different behavior sets (local auto-save-aware, iCloud-auto-save aware, remote auto-save aware) and appreciate your pointing out that such different behavior exists. Thank you for a very clear summary of the evolution of the Auto-Save-related feature set.
Let me guess, computer users could think for themselves back then, so it was... o p t i o n a l ?
No, saving versions was the default behavior on VMS. You had to take pains to turn it off. Don't know how many times my users (I was a VAX admin as a side job in our do-it-yourself modeling center) exceeded their disk space quotas because of copies of files made by the O/S
If I remember correctly 'purge' was the command to remove all but the most current version. Something well used in my CompsSci 101 days to keep within my quota.
I think you are being a bit optimistic here. VMS file names had a version number as part of the name. Each time you edited a file, the default was to save a new file with the same name and the version number increased by one. So you did have versions, but only from the end of each editing session. You couldn't go back to part way through an edit.
Secondly, the autosave behaviour was a feature of certain text editors. It was not built into the operating system and did not apply to all editors or any other applications.
But you are right that VMS had features that are still missed.
Good article, but it seems absurd that it takes 8 pages of text to try and make some sense of Apple's new document model. Just give us 'Save As' back!
Yes; what ever happened to "Macintosh-the computer for the rest of us."?
I continue to be baffled by how much people get their panties into a bunch over the small behavioural adjustments required by Lion. How hard is it to first use duplicate if you don't want your changes to affect an existing document?
And who in his right mind would do experimentation on an existing document? Any crash and all your experimental work would be gone. Always create a new file before any real experimentation and save that file regularly. And for minor experimentation, multi-level undo was invented about a decade ago. And who did not compulsively hit cmd-S every couple of minutes already long before Lion?
In short, if one used good practices before Lion, not much changed conceptually (if you wanted, you could bind cmd-shift-S to Duplicate to get over that live-altering change more easily).
And regarding accidental changes, most of the time when confronted with the 'There are unsaved changes', I would not be able to remember whether I actually had made real changes or not.
Absolutely!
Regardless of OS, or platform, the best practice for Save As... is to *duplicate* the file first; then edit it. To do otherwise is a terrible habit (and one that took me a long time to break).
Once a user has mastered that logic, the Duplicate metaphor, and the complaints about its behavior, melt away.
In fact, the best way to duplicate, or "Save As...", is from within the Finder using Command-D (or right-click to invoke the contextual menu). Then simply open the "copy" document. And now with Mountain Lion, you can even rename the "copy" section of the filename with your own version number, date... from within the title bar!
"How hard is it to first use duplicate if you don't want your changes to affect an existing document?"
Precisely this hard: to accomplish exactly the same thing, Duplicate = 6 steps; Save As = 2 steps.
"And who in his right mind would do experimentation on an existing document? Always create a new file before any real experimentation and save that file regularly."
I consider myself in my right mind. Your problem is that you assume that everyone in the world works exactly as you do. I often reach a point in making changes to a document at which I say "I think this is better, but the boss may not; I better call this something new, but preserve the old form in case that version prevails." I can do this AT ANY TIME with Save As — I cannot under the new system.
"Who did not compulsively hit cmd-S every couple of minutes already long before Lion?"
EXACTLY. For responsible users, the new paradigm fixes something that wasn't broken. Please allow us to opt out of "Saving for Dummies."
(1) In ML, the Save As command requires exactly the same number of steps as in Snow Leopard (it just requires that you select before you do any changes that you want to end up in the new document).
(2) Nobody should type away without regularly saving. Which is what you just described in your 'Boss' scenario. If you had hit cmd-S every couple of minutes, your scenario for Save As would not have been possible. What you want is right to continue to behave irresponsibly because your habits are formed around that behaviour.
Well, my initial comments were bowdlerized by the mods, so I will try to make the point more civilly that my method for using Save As has worked very well for me for 24+ years, and neither you nor Apple can rightfully tell me I must do things your/their way.
In choosing these practices, I balanced functionality against the possibility of losing data and concluded that the small risk was more than worth it.
Characterizing my work methods as "irresponsible" from your distance is something that I personally would not presume to do about yours.
My "habits" have been formed around "behavior" that made working on a Mac a very pleasant and productive experience. I needn't apologize for being upset that this is now no longer the case.
1) You asked a specific question about Duplicate. I gave a specific answer. What's the problem? Save As in Mountain Lion does not function in the same way it does in Snow Leopard (and earlier...a total of 27 years earlier, to be exact). The larger point is that I (and millions of others) had a perfectly functional workflow for all those years, and it has now been taken away from me by those who think they know better than I do how I should work.
2) My methods have worked quite well for me in 24+ years of Mac computing. I consider myself to be quite able to determine the saving intervals that work best for me. And if I have ever lost data due to not saving, I blame myself, not my operating system. Where is your disdain for the bozos who are "not in their right mind" and who are so Save-challenged they need an Apple nanny to do it for them? THAT'S irresponsibility.
OK, guys, let's keep the discussion on the topic of the feature, without personal comments one way or the other.
"In Lion, the red dot in the document window’s close button, familiar to users from years of previous Mac OS X systems, never appears"
Just a minor thing... The thing that's missing is the black dot that appears within the red 'Close' button, right?
Yup, that's right, thanks! Fixed.
Thank you for this very good explanation. However, I can't say that I agree with the conclusion that Auto Save is fundamentally a mistake. All the "gotchas" you mention are fixable with software or UI tweaks, and/or are a result of things being in a transitional period, where support for MDM (and iCloud) is mixed based on the app and the storage volume in use.
I can't imagine that the future isn't filled with computers that save everything without having to be told constantly to do so. Stepping back from accidental changes is the proper job of Undo, Versions, and Time Machine or other backup tools (with increasing time scales and decreasing resolution, in that order). Relying on an archaic distinction between volatile RAM and persistent storage is most definitely not the natural way to provide such a capability.
Thank god I use vim. This seems way to complicated and very "Microsoftesque" (it looks like you want to save a document. Can I second guess your intent?)
My problems arise from using ios and Mountain Lion to share documents. I can save a TextEdit file to the cloud, but how do I retrieve it on my IOS device via icloud? So, I try Pages. But I can't easily email a Pages icloud file from OSX. I cannot drag/drop the file picture in the menu bar to my email program when it is saved in icloud. Also, the ever present share button, is not in Pages. The Pages menu bar Share button, gives an iwork.com error message. The Pages icloud Open Document menu Share button, does not have email as an option (I'm using Sparrow, not sure if it would if I used Mail.app). I can select "attach a file" and navigate to it under the "All my files" section of finder, but that is difficult with 100s of similarly named text documents. So I must move the file out of I cloud, so that I can drag and drop it or select it traditionally. Now, I no longer can use it on ios via Icloud. FWIW, the Pages on iOS Share button works as expected. Am I missing something?
I agree with this completely. I "get" the walled-garden approach for apps, wherein the app "owns" its documents in iCloud. They're trying to make all apps like iTunes, or iPhoto, which work in those contexts. But I don't see the utility in having TextEdit's iCloud docs only being accessible by TextEdit. Hello, iOS doesn't have TextEdit, so how the hell are you supposed to access those docs? For this reason, I can't see myself EVER using iCloud for the purpose of saving documents. I can use Dropbox and have access to ALL of my docs no matter where I am or what device I'm using.
The fact that you had to write a 3000 word item on how OS X saves files shows just how broken Apples politics are these days.
I agree. And frankly, I like the "old" saving behavior, which is part of why I'm still on 10.6
I think part of the problem under discussion here is that Apple shot themselves in the foot by bringing back a "Save As" menu item which behaves differently then the original. That menu item name comes with a set of expectations for anyone who has used a Mac for any period of time. Apple should have invented a new menu item name for this similar but not identical functionality.
"...if you open and edit a document and then choose File > Save As (surely the most common use case for Save As), the original document is effectively closed without asking you about those changes; the new file contains the unconfirmed changes, which makes sense, but so does the old file, which is clearly a violation of your request to be asked about changes."
This to me is the most outrageous aspect of all of this. It seems almost cruel to offer Save As and then radically alter the behavior. How is it different from Duplicate in any meaningful way? You still have to perform the operation before any changes are made in order to avoid data loss, so anyone used to doing it "the old way" is still screwed. I wish more attention were paid to this in the Apple press.
update: I see John Gruber gives this issue its own blog entry. Kudos!
To avoid any data loss, you should not have brought yourself into a situation where you have significant unsaved changes. Anybody who is typing away and then selects Save As, is putting those edits at risk.
As in my first comment, I remain struck by hard it is for people to change their behaviour. If you adapt your behaviour to a situation where everything is auto-saved, you have much less data at risk than with the traditional method.
"Save As" has worked the same way for as long as I've been using computers, which is a long time. One develops muscle memory for doing certain tasks. You can't just change overnight. Also, how many applications use this new paradigm? A small fraction, I'd venture. So now we have two entirely separate paradigms for document saving and revisioning. Pardon me for vocalizing how inconvenient this is.
Its pretty stupid. I didn't even notice but automatically compensated. Very confusing for new users.
Thanks a lot for this article. Bottom line, a "functionality" that takes this heap of reading to try and understand let alone incorporate it in a new workaround, is not a good one by far. User friendliness hits rock bottom - I hate it big time. Apple should really stop iOS'ing the Mac!
Again, inspite all this: congratulations for your manual. Never thought I'd need one for using the macOS!
Bottom line: new functionality that requires the user to change his or her behaviour will annoy 90% of all users because 90% of all users are incapable of any behavioural change. [/end sarcasm]
And there it is again. I've been fighting this war ever since the introduction of Lion, and I've heard this same tired argument over and over again.
Your statement implies that ALL change is good, and should be embraced blindly -- and that there must be something wrong with those who don't automatically do so.
This is nonsense, and you know it's nonsense. Those of us who are complaining about the new paradigms are doing so because this "change" has rendered what was once a productive and pleasant computing experience considerably less so.
We make this evaluation based on our own very personal experience with our own personal workflows, which by definition aren't the same as yours.
To look in from the outside and tell us we're wrong -- that's there's only one possible correct view -- is the height of hubris.
Mike, thanks for this. "El Aura" seems to be one of these Apple loyalists who will brook no criticism, as if 100% of what Apple does is completely perfect and anyone who voices a concern is just a bone-headed whiner who can't keep up.
"Bottom line: new functionality that requires the user to change his or her behaviour will annoy 90% of all users because 90% of all users are incapable of any behavioural change."
Again I point out -- you give us grief when we complain about functionality *being taken away* by the new saving/Save As paradigm.
And yet, you give a pass to the legions of irresponsible Mac users who were so "incapable of any behavioral change" when it came to saving regularly that a nanny system (Auto Save) had to be put in on their behalf.
The rest of us responsible Mac users wouldn't have a complaint about this if its implementation hadn't taken functionality *away* from us in the process.
IMO, the key for using Save As properly is to always make sure you first do a regular Save, so the current document is truly saved. Then, and only then, Save As under a different name. This worked perfectly well from System 6 through Snow Leopard. So when Lion introduced Versions and AutoSave, I immediate disabled them. I was happy when Mountain Lion put Save As back for us old-timers. The only time I ever use Duplicate is when I'm in the Finder (using Command-D), although I suppose I might eventually start using the File menu to invoke it.
"So when Lion introduced Versions and AutoSave, I immediate disabled them."
May I ask how you accomplished this? I would be overjoyed to find a method for disabling Auto Save and Versions that did not play havoc with the rest of my system.
I've seen reference to Terminal commands that can do this, but they've been accompanied by warnings that they screw up other aspects of the system's operation.
As I've said from the moment Lion was introduced, Apple could make 100 percent of its users happy if they retained Auto Save and Versioning as the default, but gave experienced users a simple means in Preferences to disable them. (This assumes that when they're disabled, true "Save As" as it has always worked is automatically restored.)
In all my running debates on this subject in many forums, not a single soul has advanced a rational argument as to why this would be a bad idea.
The rational argument is that Apple likes to keep things looking as simple as possible to the end user, and this includes having the bare minimum of preferences. A new preference here, a new one there... they all add up.
Notice how the Recent Items preference was coalesced from 3 settings to 1? Apple's annoying a few power users (not me), but the strategy is working extremely well for them.
If Auto Save and Versioning are the default, as I propose, then the "end user" has to do exactly nothing for them to work exactly as advertised.
Your fears about "complicating" the Mac experience are unfounded. Why would an inexperienced user go mucking about in Preferences in the first place, or even know to do so? And even if they did, any changes made to this default behavior could be put into effect only after the user clicks through one or more warning dialogs that clearly articulate what he/she is about to do (e.g., "You are about to turn off Auto Save. You will have to manually save your files from now on...otherwise you will be at risk for losing your data. Are you SURE you want to do this?").
Of all the items currently in Preferences, none controls an aspect of the everyday Mac experience more profoundly that the way in which data is saved. I think there's more than enough room to add this one.
Sorry...yours is NOT a rational argument.
I'm surprised Apple managed to create a stupid autosave, since there are several very useful and rational models for autosave in professional, but often expensive software.
One model for autosave is that autosaves are never done to the original document but to a separate trail of autosave copies that can be reached when needed. The original document is only changed when an explicit save is done by the user.
Another model is the session model where a document is always copied on opening and autosaved as long as its open, effectively creating session versions. Usually a session can also be saved explicitly in this model anytime a document is open.
It's a mystery how the current version of autosave managed to pass apples usability lab without complete rejection.
Agreed. This has to be the most ignorant thing Apple could have ever done. It's the equivalent of switching the brake and gas pedals and telling your users to "get over it"
I've held off of upgrading to Lion or ML for the very reason that the "save" function has been crippled. The idea that I first of all have to save a duplicate copy BEFORE doing any possible changes, out of fear that the original will be auto-saved and thus corrupted, is so asinine as to beggar belief. I've been in IT for well over thirty years and this is the most idiotic thing I've seen in all of that time.
Apple should have left everything exactly as it was but have the document autosave for versions, that's all. And the option to turn it on/off... and when enabled the save item would be greyed or something. Instead they went crazy.
Having not upgraded beyond Snow Leopard, I cannot choose a side in this debate yet. I have however been reading numerous articles on the issue in an attempt to prepare myself. I'd like to commend and thank Matt for being the first to explain the issues clearly enough that I believe I understand things. Kudos!
Thank you, Matt, for such a vital article!!
I commend Apple for restoring “Save As . . . ” (and adding the two System Preferences/General prefs) as a means to honor the dictum:
“Never alter a user’s data without their permission.”
Imposing auto-save upon users violates this dictum to an extreme degree, thus the restoration of “Save As . . . ” is critical.
As Matt has so painstakingly noted, the glaring flaw in the current (OS X 10.8.0) implementation is that edits to a file, in an app that allows auto-save, are ALSO saved to the original file when “Save As . . . ” is selected from the “File” menu.
This is absolutely unacceptable and must be remedied ASAP. Until then, OS X 10.8 is unreliable and thus unusable in a production environment.
Apple needs to be relentlessly (lovingly!) impressed upon about this, and the means is via: http://www.apple.com/feedback/macosx.html
Whoah! The rest of this article made my head spin, which is, by no means, the author's fault. Methinks I'll stay with Snow Leopard a little longer after all:(
OMG! I never noticed that black dot in the red close button before. After how many years? It's so useful, so unobtrusive and so frustratingly Apple - elegant to the point of obscurity:| It's like their whole user interface is composed of Easter eggs.
I read this nicely thought out article. Now my head hurts. Where's my coffee?
Mountain Lion's document handling is a solution in search of a problem.
I was also concerned about the Save As behavior. Having read your excellent article I understand what's going on. Thanks!
Now please tell me if I am missing something: When I save a doc via Save As… and give it a new name, the "old" document is closed. Unlike before, it is saved in the state it has at the moment I perform the Save As… command. This seems to be a problem because unwanted alterations are kept and not, like before, discarded.
BUT NOW: When I open the "old" document again and select "Revert to…/Previous Save" in the File menu I get the last version of the document before I did the Save As…, don't I? So, nothing of the functionality is really lost, isn't it?
It seems that way as you suggest, if autosave continues to function the way you would expect (save your "old" document when you do "Save as"), so you haven't really lost the "old document" when you quit.
I'm not 100% sure if autosave would save your "old document" when you do "Save as" though; I guess you can do a test to check it.
I have already tested it and it seems to work this way.
I just discovered that, with the "Ask to keep changes when closing documents" option checked, if I edit a file on a network volume, as soon as I make a change to the file, the black dot appears, as you'd expect. However, the dot doesn't disappear when I do a File > Save, as happens when I'm editing a local file.
You can return the Save As… command to the File menu with it's traditional key command by adding it as a Keyboard Shortcut. By using the traditional key command I am not aware that it effects other commands.
1. Open System Preferences from the Apple menu and go to Keyboard/Keyboard Shortcuts
2. Choose Application Shortcuts from the list on the left
3. Click the plus button [+] at the bottom to add a new shortcut
3. Type Save As… with the ellipsis for the Menu Title
4. Use the traditional Command+Shift+S (or anything to your liking) for the Keyboard Shortcut
5. Finally, click Add
You should now see Save As… in the File menu in apps throughout OS X. It should push Duplicate farther down in the File menu rather than replacing it, as it did using the Option key.
Very cool! That does seem to work in TextEdit, Preview, and Pages here.
Thanks, Peter Waslowski, for keeping attention on the major change in SaveAs: it no longer discards changes to the originally opened document since the last Save.
Thanks, Slim, for calling attention to the work-around.
The work-around ain't easy.
To get back the behavior we have been relying on for decades--separating a changed document from the original--which was accomplished in one step by using SaveAs without first saving the open document, the process is now: don't Save; SaveAs; reopen the original; invoke Versions; find the version that is the last explicitly saved version; Save.
Won't that be error prone? Or is the last saved version easily found using Versions?
See now http://tidbits.com/article/13284. This problem is solved.