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.