Given how important Mountain Lion — the latest version of OS X, available today — is to Apple’s ecosystem and unification strategy, its announcement was rather unusual. For the past decade, Apple has been relying on media events and developer conferences to serve as the stage for official introductions to major new versions of its desktop operating system. At WWDC 2002, Steve Jobs famously kicked off the event by giving a eulogy for Mac OS 9 as part of the transition to OS X; in 2009, Snow Leopard — the last version of OS X before Apple’s rebranding of “iPhone OS” to “iOS” — was officially unveiled at WWDC in front of over 5,200 developers; and in October 2010, Lion, the eighth major release of OS X, was formally announced and demoed at Apple’s self-hosted “Back to the Mac” media event.
But as Phil Schiller told Daring Fireball’s John Gruber, with Mountain Lion Apple has started “to do some things differently”. On February 16th, 2012, Apple fans and industry watchers checking their Thursday morning news witnessed Apple’s most surprising OS X announcement to date: instead of being unveiled to the press at a media event, Mountain Lion roared into existence as dozens of blog posts were published simultaneously by selected journalists, who had been given “product briefings” and demo copies a week in advance. With Mountain Lion, Apple decided to let the OS speak for itself, saving a proper introduction for WWDC 2012 where a near-final version of the OS was demoed (alongside some new features) and released to developers.
The way Apple handled Mountain Lion’s announcement may have felt unusual at the time, but in hindsight, it made perfect sense given the nature of the upgrade and the way Apple has encouraged letting its mobile and desktop operating systems coexist and benefit from each other.
Mountain Lion Review: PDF Version
Support MacStories and get a beautiful, DRM-free PDF copy of all our Mountain Lion coverage, including this review and exclusive Tips & Tricks.
More details here.
Cover image by ehtesham/Shutterstock.com
Mountain Lion Review - Table of Contents
- Everything Else
- Mountain Lion and the Power User
The key to understanding Mountain Lion — which is available for $19.99 ($10 less than Lion) on the Mac App Store — is the rapid pace of development that Apple now sees as the cornerstone of familiarity and user experience across iOS and OS X devices.
Lion, a major change in terms of underlying technologies and visual presentation, was announced in October 2010 and released nine months later in July 2011 (almost two years after Snow Leopard). Mountain Lion, unveiled only seven months after Lion’s release, has been made available to the public 12 months after its predecessor — which, according to official numbers from WWDC 2012, has been downloaded over 26 million times. Despite the new faster-paced schedule, Apple has managed to help developers get their apps ready for Mountain Lion in a scant five months.
Now the most powerful (and wealthy) technology company on the planet, the Apple of 2012 isn’t the same Apple that had to delay the release of Leopard in 2007 to shift resources to the development of iOS (née iPhone OS). With enough engineers and designers on hand to keep the two software pillars of the Apple ecosystem updated with major revisions every year, it should come as no surprise that Apple is now “doing things differently”. iOS has profoundly impacted the company’s (indeed, the whole industry’s) economy and stability over the years, and by bringing much of its functionality and philosophy back to the Mac, Apple has infused some of its essence into OS X as well. No longer a second class citizen, the Mac may not generate as much revenue as the iPhone or iPad — but Macs, and thus OS X, are still essential to Apple’s ecosystem.
So: how does Mountain Lion fit into this picture?
Solitary by nature, the mountain lion — also known as the cougar, puma, panther, and mountain cat, depending on the region — holds the Guinness World Record for the animal with the highest number of names: over 40, according to recent data. While most names would typically be dismissed as simple marketing — a brand slapped atop technical release notes and new features for the sake of public perception and labeling convenience — I think OS X’s latest monicker tells us a bit more about the OS than previous cat-based choices did.
Minutes after the original announcement back in February, many were quick to point out that “mountain lion” had already been used by Apple — on multiple occasions, even — as a name for its desktop operating system. We’ve still yet to see an OS X Cougar hit retail shelves — or more appropriately, the virtual shelves of the Mac App Store — but Puma and Panther (other name variations of the mountain lion) have been used by Apple before with OS X 10.1 and 10.3. Even if the “big cat” branding only went public with Jaguar (previous versions of OS X were only known by big cat names internally at Apple and among its developer community), it seems as if Mountain Lion carries more history than its predecessors for the name alone too. The Lion → Mountain Lion transition is reminiscent of the Leopard → Snow Leopard one that occurred in 2009, further hinting at the evolutionary nature of this latest OS.
Conversely, in spite of what may look like a recurring theme in Apple’s branding and “feature release” updates, Mountain Lion is actually a rather unique revision of OS X for a number of factors, among which include new apps and features, a fundamental reassessment of iCloud integration on the desktop, and the first steps towards a new, user-friendly implementation of document browsing and sharing. At the same time, whilst standing out in the history of OS X releases (especially for its announcement and timing), Mountain Lion does feel like just another piece of the puzzle in Apple’s ecosystem, rather than a distinct product isolated from other Apple offerings.
Mountain Lion is all about the differences between previous versions of OS X and the contrast between familiarity with, and changes to, the classic OS X experience. Unsurprisingly, the most visible change — indeed, the very core of this update — is iCloud.
Since its public launch in October 2011 with iOS 5 and OS X 10.7.2, iCloud has become the central part of Apple’s ecosystem: the backbone of a growing collection of devices, apps, and services aimed at providing a reliable and seamless experience across platforms. Announced by Steve Jobs at WWDC 2011, iCloud in its initial form was clearly meant for iOS devices. With a focus on freeing iPhone and iPad owners from the need for USB cables and syncing with iTunes, “iCloud 1.0” went hand in hand with iOS 5, which even got a complete makeover to its setup experience with iCloud-based instructions to associate a device with an Apple ID, set up iTunes Store accounts and Find My iPhone, and document storage for Apple apps.
Lion, on the other hand, seemed to be an afterthought in terms of iCloud integration, with many stopgap solutions to make up for an experience that wasn’t built into the operating system from the get-go. Lion was released in the summer of 2011, while iOS 5 was still in beta for developers to test their updated apps. To enable iCloud integration on OS X during that period, Apple released a standalone package to manually install a panel in System Preferences in order to let users sync with iCloud instead of MobileMe. By the final version, Apple had to release a new version of Lion entirely (10.7.2) to address the lack of iCloud integration, forcing Mac users to migrate from old MobileMe configurations to the newer iCloud syncing technology in medias res.
With Mountain Lion, iCloud is now deeply integrated into the operating system, touching almost every part of the OS that used to work with MobileMe and adding support for new kinds of information and data to store in the cloud and push down to users’ devices. This kind of integration has allowed Apple to come up with a first-run experience that doesn’t disrupt a user’s existing workflow and data library (such as the 10.7.2 update did for some users) but instead places the Mac on the same level as iOS devices right from the initial installation process.
In Mountain Lion’s new Setup Assistant, users can now login with an existing Apple ID associated to iCloud to start pulling in settings, accounts, and content from other devices (such as an iPhone or iPad) to find it already available once logged into OS X for the first time.
After activating Location Services, the next step in Setup Assistant is the new Apple ID setup screen, which explains how your Apple ID “is used to set up the iTunes Store, the Mac App Store, iCloud, and more” on your Mac. The key role of iCloud in this new experience is exemplified by the central position of its icon, sitting in between iTunes and the Mac App Store. If you’re using a single Apple ID for iCloud and iTunes purchases, you can log into your account from this window and proceed to the next step. If you’re not, Mountain Lion offers some extra options to further customize the way OS X will “talk” to your Apple ID.
To start, Mountain Lion enables you to use separate Apple IDs for iCloud and iTunes — a welcome option, considering how many users created Apple IDs for iTunes years before iCloud existed, or who liked having a fancy new me.com address without losing iTunes history and previous purchases. Of course, iOS 5 has been offering separate logins for iCloud and iTunes (as well as FaceTime and iMessage) for months now, so Mountain Lion‘s new Apple ID separation is far from a surprise. Still, while settings and logins can always be changed later, it’s nice to have options available from the start.
If you don’t want to use your Apple ID right away in Setup Assistant, you have two other options: skip, and “create a free Apple ID”. The latter enables you to create a new Apple ID by following a series of instructions to enter your birthday and personal details. As usual, you can choose between using an existing email address to set up the new ID or getting a new iCloud email address directly from Setup Assistant. Apple goes out of their way to remind you that if you have already purchased music, apps, or books from Apple, you should sign in or update your ID instead of creating a new one. Regardless of the kind of Apple ID configuration you eventually pick, Mountain Lion neatly indicates the accounts connected to it by slightly dimming the icons of inactive services.
Once set up, Mountain Lion will ask one more time if you really want to “set up iCloud on this Mac”. With a nice animation depicting content moving back and forth between devices and the cloud, this is the last step before choosing to activate the final iCloud-based functionality of OS X: Find My Mac. Once that’s done you’ll be brought to the new Mountain Lion desktop (sporting a fresh coat of space pixels with the new default wallpaper, Galaxy) and you’ll be able to start using your Mac.
To say that the new iCloud-based setup process is easier to use than the old Migration Assistant would be an understatement. While the old options are still there (and virtually unchanged from last year; see our Lion Installation Guide and Q&A for more details), the new Setup Assistant finally lets you get ready to go with your Mac in minutes instead of hours, as your data is already available in a place that doesn’t require tedious (and often prone to failure) migration processes and file transfers. But more importantly, setting up a Mac with iCloud serves to welcome Apple’s new Mac customers — those who, thanks to the “halo effect”, purchased an iPhone or iPad years ago, have all their documents and data on those devices, and then decided to get a Mac. For those customers, transitioning from iOS to a Mac with Mountain Lion should be a relatively frictionless and, dare I say, pleasant experience, as iCloud takes care of everything without demanding the user get involved. For longtime Mac users who have been keeping separate work environments across Apple’s device lineup, things will obviously get a bit more complicated; as usual, a full backup of your documents is recommended.
Overall, the convenience of having iCloud built into the OS from the first screen you see is indisputable, and I think the majority of OS X users will soon start seeing the advantages of Safari sync, Notes, Calendars, Reminders, and accounts in the cloud as well. This was already partially true with Lion; with Mountain Lion, it’s simply more consistent, better explained, and more cohesive all around. Surprisingly, it’s also more present in the operating system itself now that Apple has, for the first time in decades, altered a key element of OS X to make room for iCloud: the Finder.
Finder + iCloud
Back in the day there used to be an ongoing argument among members of the Apple (read: Mac OS) community in regards to the role of the Finder and the issues with the transition from the Classic environment to OS X. Those arguments went on for years — some people even continue to have them to this day — but to sum up, they posited that the new “browser-inspired” Finder of OS X was a fundamental step backwards from the classic Mac OS’ “spatial Finder”. These arguments and terminology sound like echoes from a distant era today, but the underlying discussion is still worth considering when taking the evolution of the Finder into account.
John Siracusa, well-known among Apple enthusiasts for his in-depth OS X reviews at Ars Technica, used to be one of the most prominent evangelists for bringing the spatial Finder back to OS X. He argued that its windows, which could be “permanently, unambiguously associated with a single folder”, and the way its “files, folders, and windows [would] go where you move them, stay where you put them, and retain all their other ‘physical’ characteristics”, made for a more direct, engaging, and powerful file management experience — and he wasn’t the only one. In fact, Bruce Tognazzini, founder of the Apple Human Interface Group himself, employed spatial interface principles to ensure that classic Mac users would be able to recognize a window “based on its size, shape, and the layout and coloring of the objects within”. These principles were so crucial that they would come to define the Mac, its spatial approach to file management, and the Finder, which for a long time was the single most important and influential application in the Mac OS user experience.
But somewhere around 2008, the Finder stopped being the most important application of the OS X experience and started becoming an alternative, often unnecessary extra layer to get files and documents into apps.
With the release of the iPhone in 2007, the opening of the App Store in 2008, the maturation of OS X with Leopard, and new releases of database-centric apps like iTunes and iPhoto, Mac users became progressively more accustomed to the concept of managing documents inside the apps they belonged to, rather than through an abstract second layer between “the computer” and “content”. And by hiding core structures like the file system from the user on iOS, Apple turned a design choice into a philosophy: your apps, not your memory, should be responsible for managing your content.
This choice had several far-reaching consequences on the Apple ecosystem landscape. It spurred the proliferation of single-purpose apps on the App Store in addition to traditional document-based ones; it further relegated the file system manager, spatial or otherwise, to a relic of the past; and it enabled Apple to position iCloud as an app-oriented push feature, rather than a hierarchy-based syncing product to stash away in the Finder like they did with iDisk.
The ongoing declassification of the Finder to a low-level file management role is a reflection of the tremendous growth of iOS devices, the App Store, and the “Back to the Mac” trend. Apps are closer to the cloud.
With Mountain Lion, the Finder isn’t going away. But it is getting an app-inspired makeover in the area that likely matters most to users: opening and saving files. Now, instead of presenting you with a miniature Finder window every time you wish to open or save, Mountain Lion shows you a simple app-like database of all the files in your iCloud Document Library. By doing so, Apple has made the Finder both less important and more usable by reducing the time spent looking for the document you want.
iCloud Document Library is an iOS-like extension of the Finder that shows you your documents stored in iCloud. It is native, so developers won’t need to custom-code alternative interfaces for iCloud file management anymore, and it lives in the Open/Save file dialog that has been almost totally unchanged for the past 28 years of Mac OS.
iCloud Document Library
iCloud Document Library resembles an iOS Home screen: it’s got a linen background, large, unresizable document icons, and iOS-like folders you can create by dropping a document onto another in the same way you would for apps on an iPhone or iPad. You can see this new simplified interface for browsing your iCloud documents in TextEdit and Preview, and third-party apps like Byword and iA Writer are already using it as well.
The iCloud Document Library can be accessed with the File > Open… menu available in the OS X menu bar, and it is the new default location for saving files with Save or Save As. You can also open the iCloud Document Library by clicking on the Dock icon of an iCloud-ready app that doesn’t have an open document or window.
The iCloud Document Library’s UI is extremely simple and, again, inspired by iOS. A single click on a document opens it; a click on a folder expands that folder with the same animation seen on the iPhone and iPad; documents can be renamed by clicking on their filename; and folders can be renamed by opening them and clicking on the folder’s name. A minor gripe I have with the iCloud Document Library window is that it can’t be closed with the Command-W keyboard shortcut; you need to click the Cancel button.
Functionality-wise, the iCloud Document Library supports some of the same interactions as the regular Finder, but not everything. For instance, while you can hit the space bar to preview files, you can’t tap with three fingers (a new feature in Mountain Lion) to activate the Quick Look preview (though to be fair you can’t do that in the traditional Open/Save interface either). You can right-click on a text file in TextEdit’s library to rename it, move it to the trash, duplicate it, preview it, and share it using Mountain Lion’s new sharing features (text files come with Email, iMessage, and AirDrop; pictures in Preview add Twitter and Flickr as well). Documents display the date they were last modified under the filename (extensions aren’t displayed in this view); folders, unlike iOS, scroll horizontally, with the same carousel-like interface that was first introduced in Lion’s Finder last year.
While consistent with the Finder’s behavior, I found this way of scrolling folders a little disorienting at first, especially because coming from iOS I was expecting folders to expand vertically. I suspect that in order to take advantage of widescreen displays (which nowadays come with every Mac sold except the mini and Pro), Apple chose to let folders in the iCloud Document Library scroll horizontally because, unlike iOS, they support unlimited documents.
Another point of inconsistency between the iCloud Document Library’s OS X environment and iOS-like appearance is that, even though it gives you lightweight file management options, it doesn’t give you the ability to nest folders. Again, this is possible when managing files in the Finder, but the same drag and drop action doesn’t work when trying to nest folders in the regular “On My Mac” view (accessible from a tab in the iCloud Document Library’s title bar). Similarly, even though the iCloud Document Library supports right-clicks and gestures, it won’t let you use such common actions as Copy, Cut, Paste, and Undo from the menu bar on a selected document. To move a file from the iCloud Document Library to, say, the Desktop, you’ll have to either drag and drop it onto the new location or, if you want to copy it, drag it over while holding down the Option key. The opposite is also true: you can drop or copy supported file types from the Finder onto the iCloud Document Library. In case a file with the same name already exists, a standard Finder alert will ask you if you want to replace the existing document in iCloud.
If you wish to move a file from iCloud to the Finder, however, the alert sheet is integrated into the iCloud Document Library, notifying you that moving a file away from iCloud will also delete it from all your devices (the same alert changes “Move” to “Delete” when you try to delete a file with Command-Backspace).
Overall, while simplified and distinct in terms of looks, the iCloud Document Library is essentially a glorified Open/Save dialog, and as such it conforms to the rules and technologies Apple started using with sandboxing in Lion last year. Let’s take a look at the iCloud Document Library in Mission Control:
As you can see, iCloud Document Library appears as a separate app called “com.apple.security.pboxd”, which is the daemon process associated with Powerbox. Introduced in OS X Lion, Powerbox is a security technology that enables an app’s sandbox — a collection of Apple-sanctioned operations called entitlements that define which parts of the operating system an app can make use of — to access the file system. Any app that’s been updated for Lion and sandboxing (and thus Mountain Lion, which also adopts sandboxing) will use Powerbox when using the standard NSOpenPanel and NSSavePanel classes — the very ones that control the Open/Save dialog. This explains why the process’ name in Mission Control or Activity Monitor appears as it does: because the dialog is handled by Powerbox, not AppKit. Thus, in Mountain Lion, the iCloud Document Library is a glorified Open/Save dialog not just visually, but technically as well.
At first glance, the “iCloud” tab in the Document Library may look like some sort of “directory in the sky” that the Finder is reading files from directly. That is certainly the illusion Apple wants to maintain for less tech-savvy people who don’t want (or need) to play around with the Mac’s file system, but it’s not what it actually is. Despite its different design and iOS-like interface, the iCloud Document Library is still just a simple folder that, with a few tricks, any user can easily access and manually modify. And because it is just another folder (albeit one with a pretty skin), it adheres to the aforementioned Powerbox rules, which mainly revolve around the concept of specific user intent.
As a handler of app-to-file-system communications, Powerbox has to interpret a user’s input and provide the file or folder they want to open to the app’s sandbox. For instance, while iCloud is the default initial location for opening and saving documents, an app like TextEdit is also capable of opening .txt files from the Desktop or the user’s Home directory. As I mentioned above, the iCloud Document Library is managed by Powerbox, which interprets the user’s click on the Open menu as a clear sign of intent to pick a file from another location and pokes a hole in the sandbox. What about other scenarios where the iCloud Document Library may not be displayed, with a file located outside the sandbox being directly forwarded to the app? Try this: leave TextEdit running with no iCloud Document Library displayed, drop a .txt file onto its Dock icon, and you’ll still see the Powerbox process handling the communication between TextEdit (sandboxed) and the file system. Powerbox has been handling these kinds of operations since last year, and now with the iCloud Document Library it’ll get a little more visible in places like Mission Control.
As I said earlier, the iCloud support Apple shipped with OS X Lion was half-baked compared to Mountain Lion’s tight integration, but the seeds for the service’s future had already been planted. As I detailed in two separate articles last year, it was possible to manually access app documents stored in iCloud by visiting the user Library folder, and by opening an app’s iCloud container (technically called a “ubiquity container”) located in Mobile Documents. This is a local representation of iCloud storage, and it’s where apps store their iCloud-based “documents and data”. Third-party iCloud-enabled apps like GoodReader, for instance, have effectively implemented their own hierarchical file system within Mobile Documents, allowing power users and tinkerers to access their containers and move files around by hand.
On Mountain Lion, the front-end interface for Mobile Documents is now the iCloud Document Library. But manual access is not only still possible, it’s even better presented through the Finder.
On Mountain Lion, try looking for a document stored in iCloud through Finder search. If you have chosen to display the path bar (in Finder, select View > Show Path Bar), select that file — say one stored in TextEdit’s library — and look at its path. Notice the iCloud icon? To understand the actual location of that file and the trick Finder is pulling to masquerade Mobile Documents as simply “iCloud”, go to Users/yourusername/Library and scroll to the letter “M” in the list of folders. Click on “Metadata” — see the full path bar? Now click on Mobile Documents below it. Notice anything strange? In both the path bar and Finder’s title bar, Apple is rewriting “Mobile Documents” as “iCloud”, giving it a custom 16x16 icon in the process. Unlike other folders inside Library, double-clicking on “iCloud” in the Finder’s title bar doesn’t reveal the full hierarchy of the folder because OS X treats it as a top-level location (likely because of the way it appears to the end user through the iCloud Document Library); furthermore, you can’t preview this folder with Quick Look or add it as a Favorite to the Finder’s sidebar. However, if you open Mobile Documents you will see the familiar collection of folders, documents, and data, including .txt files for our beloved TextEdit.
Here’s a fun trick: because iCloud Document Library is entirely folder-based (which further explains how Powerbox can work with it), you can open multiple instances of the Document Library at the same time and move files around them just like you can in standard Finder windows. For example, you can keep TextEdit and Preview open in the iCloud Document Library side by side and drag and drop files between them; in this case, iCloud Document Library won’t ask for permission to move and the process will be direct with no alert sheets displayed. You can also move multiple files at once, and just like a regular move operation Finder will group document thumbnails together with a nice stacking animation, along with a red badge that displays the number of documents being moved.
You can also move folders between multiple iCloud Document Libraries. Inside the Document Library, the folder’s icon will keep its iOS-like appearance; when dragging from the Library to anywhere else in the Finder, the iOS-like folder becomes a standard Mac folder during the moving process.
More importantly for power users, files can be manually moved to a Document Library folder inside Mobile Documents, and changes will be reflected in the “normal” Document Library. For instance, you can copy PDFs into Preview’s own folder, then find them sorted by date inside the app’s Document Library. Because of this folder-based access, it is actually possible to build automated workflows based on Folder Actions or third-party apps like Hazel to automatically copy files between multiple Document Libraries, mirror them to other locations, and so forth.
Mountain Lion’s iCloud Document Library doesn’t do much to overcome the limitations of iOS. While it’s possible to manually copy documents between various instances of Document Libraries or by heading to Mobile Documents, you still can’t share them between iCloud-ready apps through the new Open panel even if they can be opened by multiple applications. Because every iCloud app have its own entitlements and, by default, is only capable of accessing files saved with that application, .txt files saved with, say, TextEdit won’t appear in Byword’s Document Library, and vice versa. Even if there are several file types that can be accessed by different apps, iCloud still behaves like a “data silo” for app-specific documents.
In thinking about this design choice — as a Dropbox user myself, I am accustomed to using many different applications to open the same files every day — I have come to the conclusion that Apple is embracing this philosophy to cement the idea that apps, not the user, should be responsible for the location and state of content. To avoid confusion and establish a model where a user associates a document with the app that created it, the iCloud Document Library — the only file-related interface most users will see on a regular basis — enforces a direct connection between an app and its documents. Shying away from file extensions and attributes, Apple wants you to forget about .txt files and start thinking about them as TextEdit documents. The same goes for PDFs in Preview, or your .jpegs in iPhoto. The app, not the file manager, defines the experience.
This decision has been made at the expense of more advanced users, who would like to see the benefits of a pretty interface combined with more options to share documents across apps. Wouldn’t it be nice to open Byword files directly from TextEdit? Or save changes to a document into another app’s container?
In fact, this is something I have written about before:
You might argue that Apple is trying to eliminate the concept of the filesystem altogether by embracing the app model with data silos that are self-contained and user-friendly. As iTunes File Sharing seems to be suggest, though, I think that Apple knows the app model and iOS only solve so much when it comes to file management — Apple has to deal with the fact that many people still work with files and folders, export them, move them around, and manage them. I believe the real winning scenario for Apple would be to make the management process as lightweight and intuitive as simple by relying on iCloud. Thus, iCloud File Sharing would serve as a better solution than iTunes File Sharing, and it would strengthen Apple’s offerings requiring no or little effort from developers, ultimately providing an accessible way to manage files atop of Apple’s existing free 5 GB of storage for every iCloud account.
Pierre Lebeaupin had a more drastic take on Apple’s recent approach to document filing on iOS:
When I see the absence of a user-visible traditional file system in iOS being lauded as some sort of brilliant new move, I’m scratching my head. It is a bold move, for sure, and not having something does represent accomplished work in the sense that it is a design decision, but honestly not having this feature is the easy part, creating a worthwhile replacement is the hard part, one that Apple has not shown even an interest in tackling. Moreover, the absence of a user-visible filesystem is nothing new.
Also in regards to iOS, I have written about the possibility of a “universal save” feature for documents:
And then there’s the conceptual issue of an iOS device being the app that you’re using. When you use Pages on an iPad, the iPad is a word processor. When you browse the web with Safari, you’re holding the web in your hands. On a technical level, this app console model is represented by sandboxing and one-way “Open In” menus, and soon iCloud-based documents that allow multiple versions of the same app to access files. Would a “universal save” option somehow break the illusion that you’re holding an app, reminding us that we’re using a device with multiple layers of abstractions including a filesystem?
Technical hurdles aside (putting a document in a “shared state” would require an exception to the sandboxing model), as someone who manages lots of documents in multiple applications I would argue that, especially on the Mac, I’d like an app’s visual Document Library — not just the Mobile Documents folder — to display files from other apps that can be opened and edited. It would enable me to use an elegant interface without giving up on the filesystem-oriented nature of the Mac, which, as much as it may be hidden by default in some areas, is still there and still part of my daily workflow.
On the flip side, I recognize how the majority of users don’t see this option as a must-have. The average user doesn’t fiddle with dozens of text editors, nor do they try 10 different PDF apps to see which one has the best support for annotations (I am guilty of this too). Still, I think there could be some edge cases in which those users would miss “shared iCloud documents” — for example, they could be using TextEdit on the desktop, but another text editor on iOS — so once again, I restate my hope that Apple will someday consider the possibility of making iCloud documents app-independent…as an option if nothing else.
Document Library Search and Sorting
From an interface standpoint, the iCloud Document Library offers various options to sort documents and find them.
At the top of the window, two tabs are displayed by default to switch between iCloud view and the Finder’s regular Open/Save dialog. At the right of the app’s name, a search field lets you look for documents and folders across All locations, iCloud only, and “On My Mac”. Search supports tokens and updates results as you type. From our review of Lion last year:
The new geeky features of Finder pertain to search — tokens in Lion allow you to build text-based keywords specific to names, file types, and dates in order to better locate files. I’ve never been a big user of specific search functions like this in OS X in the past since Smart Folders and Spotlight took care of everything, but the swiftness of tokens has opened up some new use cases for me. Tokens aren’t a terribly new concept, instead presenting a quicker way to build rules with simple text. Too, tokens can be quickly dismissed without need for building a Smart Folder or rule sets.
Tokens are predictive in that as you type something, Lion will make a good guess as to whether you’re looking for part of a file name, date, or downloaded file by association with its domain name. If I start to type “ap” for example, Lion assumes that I’m looking for a file with those characters in the file name, Applications, or an Apple icon image. Under the token headings, I can either click or use the down arrow and press return to make a selection. I can then continue typing to add another token. Date tokens in particular are extremely helpful. If you type ‘Thursday’, Lion asks if you’d like to only look for files you worked with last Thursday.
Support for search tokens is unchanged since last year, only it now works in iCloud Document Library as well.
One questionable decision with the Document Library pertains to sorting options while in icon view. Located at the very top of the Document Library’s linen background, tabs to switch sorting between date and name are only displayed if you scroll down — otherwise, there are no hints or interface clues pointing at their existence. I only discovered them by accident, as I assume most other people will too. And while Apple did decide to make these two options available by right-clicking anywhere on the background as well, it has no connection whatsoever to the two tabs displayed at the top.
The sole precedent I could find for this behavior is Apple’s logo in iBooks’ wooden library; an “easter egg” of sorts that only appears if you scroll down further than necessary.
Sorting options are much more accessible in list view, which is available through tabbed controls in the Document Library’s bottom toolbar. List view displays the typical columns for sorting by name, date modified, and size. As far as I can tell there is no way to sort icon view by size.
In an episode of The Talk Show from last year Daring Fireball’s John Gruber argued that iCloud wouldn’t feature any form of user-facing merge features or conflict resolution dialogs, and that it would instead figure out the most recent version of a file in the cloud on its own. From our transcript:
Apple won’t reveal it but iCloud, on the server, will determine the truth when it detects a conflict that will never be published. It will act like a “black box”. Most cases it will go by the most recently implemented change — it will be undefined. The key is that if there is a conflict, they will remember the different conflicting versions. If it picks the “wrong truth” it will be able to go back and get the right one. That’s what I mean when I say no more merging or conflicts. iCloud will make its best guess at merging and conflicts other than having you pick it.
While Gruber was right for key-value data stored in iCloud (small amounts of data like preferences, game states, or bookmarks, for which cases Apple advises to make the most recent change “the winner”), iCloud on Mountain Lion works differently for document-based apps like TextEdit and Preview. In fact, the iCloud Document Library does feature a dialog that helps users resolve conflicts when they open a document that was changed on another device.
As Apple explains, “a conflict arises when two instances of your app, running on two different devices, attempt to change a document”. Because iCloud is (theoretically) enabled on multiple devices, it’s possible that a document may not be saved to the cloud due to a lack of Internet connection, or that a user makes changes on more than one device and then reconnects them to the network at the same time. When iCloud detects different copies of the same document, it will ask users to choose if they wish to keep one version or both versions. Choosing “both” from the conflict resolution dialog will create a duplicate that the user will have to choose to save.
One feature originally introduced with Lion that benefits from the added convenience of iCloud Document Library is Auto Save. Working in combination with Resume and Versions, Auto Save allows any app that supports it to keep track of changes made to a document automatically, in the background, without losing those changes if the document is closed or the app quits. Designed to prevent data loss, Auto Save is visible through the title bar via features associated with its functionality, such as the aforementioned Versions — a Time Machine-like tool to revert to previously saved versions of any document.
In Mountain Lion, Auto Save has been integrated with iCloud and gained more features to boot. For starters, unsaved and untitled documents are now auto-saved to iCloud Document Library and synced to all your devices. Auto Save automatically saves untitled documents in iCloud as soon as the user begins editing, but if an app doesn’t use iCloud untitled documents are saved in the user’s Documents folder. For apps that do want to use iCloud, Auto Save is a requirement.
Conversely, any existing document can be moved to iCloud thanks to a new Move To… item available in the File menu. And while Auto Save will keep saving changes in the background or after an accidental quit, a new “Ask to keep changes when closing documents” preference available in System Preferences > General will always prompt you to keep or discard changes when closing a document.
Speaking of saving changes, one of the most glaring omissions in Lion was the removal of the Save As… item from the File menu. With their new focus on auto-saving changes, creating duplicates, and maintaining multiple copies of the same document, Apple thought that moving beyond the classic Save As behavior would be a good idea. This prompted some smart folks to create custom hacks to bring Save As-like functionality back, usually relying on automation tools like Keyboard Maestro or AppleScript. Fortunately, it seems that even Apple must have noticed that Save As was actually quite handy because they are bringing it back in Mountain Lion, albeit in a somewhat limited fashion. Now, Save As is back as a keyboard shortcut (Command-Shift-Option-S), but it isn’t listed as an available option by default in the File menu.