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.
Here, the ever-useful Option modifier key comes to the rescue again: in the File menu, hold Option, and Duplicate (which also has a new shortcut in Mountain Lion) becomes Save As, while Close turns into Close All. Although Save As no longer has the same shortcut it used to in the pre-Lion days, its existence will undoubtedly please everyone who missed being able to select a different name and location for their documents.
In Mountain Lion, the Duplicate menu now allows you to enter a name for a document copy. If a duplicate document is closed with unsaved changes, Finder will ask whether you want to keep the copy, or delete it.
As for old documents, several users complained Lion was a little too aggressive with “locking” documents older than two weeks. Specifically, Lion would display an alert every time you tried to open a document that hadn’t received any changes in two weeks as the OS “locked it”. In Mountain Lion, the default setting that controls this behavior has changed from on to off, so the alert won’t appear unless the user tuns on the setting in Time Machine’s preferences.
Two additional updates to Auto Save can be found in the title bar. Like a similar option offered in the new Safari bookmarks bar, documents can now be renamed from the title bar without leaving the app. Simply mouse over the document’s name in the title bar, click on the triangle that appears, select Rename, and type away. If you have Finder set to show filename extensions, the extension will be selected as well when you hit Rename.
Finally, you can now revert to the last saved version of a document to undo all changes you have made since saving it. Located in the title, the Revert To menu (also accessible from File) has added a new option to revert to the last saved version of a document alongside all versions. If changes have already been saved, Auto Save will also offer to revert to the “last opened” version of a document, as previously seen in Lion.
Changes Apple made to the Finder environment don’t stop at iCloud Document Library though. While the Finder may not have gotten the same visual and gesture-driven improvements seen in Lion (and we did call the Finder a “refinement” last year) Apple has quietly worked to fix a couple of longstanding annoyances (and made some very minor changes as well).
The sidebar, which Apple de-emphasized in Lion by draining its icons of color, now allows you to completely customize its categories. In Mountain Lion, the Devices category can be placed at the top, and you can move the Favorites to wherever you want. Categories can still be selectively shown or hidden from the Finder’s Preferences, and the possibility of rearranging Categories and their contents should definitely help to provide a more versatile Finder experience to the user.
Last year, Lion introduced a three-finger tap to display a pop-up Dictionary definition on any word lying underneath the cursor. In Mountain Lion, the same gesture on any file, folder, or drive in the Finder will now open Quick Look too.
Speaking of drives, Mountain Lion’s Finder offers simple encryption for those times when you want to make sure your data is really safe. Using FileVault disk encryption, you can now encrypt a drive by right-clicking on it and selecting the new “Encrypt” option from the contextual menu.
From a visual standpoint, Mountain Lion’s Finder sports two minor additions: a share button in the toolbar and contextual menu, and inline progress for downloads and file copies. The latter is a particularly welcome option in my opinion, as it offers more context next to each file, folder, or archive that is being downloaded from the Internet or copied to another location.
Though available in every view of the Finder, icon view is the only one that displays an icon to cancel a copy in progress. The other three views only show a progress bar next to the file’s name.
The Finder in Mountain Lion refines what was already a refinement over Snow Leopard’s Finder, but it doesn’t change the tweaked experience Apple introduced with Lion, suggesting the company is mostly fine with the current state of operations outside iCloud Document Library.
The Future of the Finder
At this point, it’s clear that it’s not in Apple’s plans to work on a major reconsideration of the Finder that takes into account the historical debate on spatial orientation and browser-based navigation. Apple appears to be satisfied with the touch-oriented features they introduced in Lion and is now giving users more flexibility over the items and categories displayed in the Finder sidebar — which, while it may not sound like a big deal, is actually quite relevant, as it is the primary element of interaction with the Finder for many users. Features for power users remain unchanged in Mountain Lion, and while not substantially improved or re-imagined over the last version, it’s safe to assume the Finder is not going away.
That’s not to say the Finder will stay this way forever, of course. A first hint of possible changes down the road is the iCloud Document Library, an interface that leverages the existing Finder and iCloud features of OS X to offer a simplified view consistent with the way users manage documents on iOS. I suspect we will see more of this in the future — app-inspired interfaces and features that use the Finder and file system to provide alternative views and experiences that break free of old schemes and dogmas.
It’s possible that we may someday see a unified interface for browsing iCloud documents without using their respective apps (as I proposed in the past here), but today, iCloud Document Library is app-driven and folder-based with no general UI to access documents from Finder. The user’s Library — where those iCloud files are located — continues to be hidden by default as well.
Apple really wants you to have an iCloud account in Mountain Lion — this is clear from the initial setup process — and looking ahead, I believe deeper iCloud integration with the Finder is to be expected. I don’t want to speculate too much on what Apple might introduce, but I imagine the regular Finder experience will be progressively de-emphasized — though not removed — to leave room for fresh takes on the concept of file management and search as well as iCloud-based functionalities. For instance, it is still possible to manually launch apps from the Applications folder in Finder, but it was Launchpad that gained Mac App Store integration with inline progress and fancy loading animations.
I don’t think the Finder will be going away in future versions of OS X, but I do believe Apple will use its foundation to rethink interactions and designs that have been stagnant and lacking in innovation for decades. The next Finder will be more connected with iCloud, and the first step towards such (r)evolution is Mountain Lion’s iCloud Document Library.
Often purported to be the “iOS-ification” of the desktop, Apple has been busy unifying core features and applications across their mobile devices and the Mac in order to make the overall experience more familiar and cohesive. As John Gruber noted in February, Mountain Lion is about removing “cruft” — addressing longstanding complaints from Mac users who wish some things were done differently. The steps Apple has taken to make Mountain Lion a more consistent experience include changing the name of two stock applications (something they haven’t done in years) to match their iOS counterparts, and adding new applications that originated on iOS. iCal is now simply “Calendar”, Address Book has become “Contacts”, and for the first time they are joined by Notes and Reminders.
The new Notes is more or less a direct port of the iPad version that Apple introduced with iPhone OS 3.2 (and which they will further refine with iOS 6 this fall). Keeping the same layout, the same leather textures, and even the same bits of torn paper at the top of each page, Notes doesn’t do much to differentiate itself visually from the iPad app. Basic interactions are the same as well: a sidebar lists all your notes with a search field available at the top, while actual notes are displayed in a panel on the right.
The notes list contains buttons to switch between two different views: the regular one (i.e. “iPad View”) and a new one where you can manage your notes in folders. The latter, called “Folders List”, is accessible from the View menu and displays all of your notes, along with any accounts you have may have added in System Preferences (including iCloud, of course).
On previous versions of OS X notes were synced through Mail. Using either MobileMe, local copies, or a Gmail account, users could set up a special IMAP folder to sync notes back and forth between their Mac and iOS devices without an actual Notes app. On Mountain Lion, Apple decided to make things easier — and to an extent, more visually appealing — by moving the entire workflow into Notes, even for non-iCloud accounts such as Gmail (which you can still configure in System Preferences). Notes can be moved to another folder, but only through drag and drop, as Apple didn’t create a “Move” menu item. If you’re working with multiple notes, folders, and accounts, you’ll want to keep the Folders List visible.
Like all of Apple’s Mac apps, Notes supports full-screen mode. When expanded the app resembles its iPad counterpart even more, adding more leather and relocating the brown texture of the title bar to the typing panel on the right. In my experience, while running Notes in full-screen mode may technically offer a more focused writing environment, it doesn’t offer any meaningful enhancement over running Notes in “normal” mode.
The paradoxical problem of Mountain Lion’s Notes app is that it supports features the iOS version will only gain with iOS 6. On the Mac it lets you insert links, photos, and general attachments, with all the new perks related to support for Quick Look. All attachments work through drag and drop, so you won’t be able to copy and paste an image from the Finder into Notes (doing so will paste a file://localhost/ URL), but you can use the mouse to drop images, text files, videos, and web links. Images will be displayed inline, and on iOS links will become clickable. However, because the iOS Notes app will only be updated this fall, images will currently lose their inline visualization when synced to a device running iOS 5 (only a general attachment icon is displayed in the text; hitting “Copy” on it doesn’t seem to do anything).
Fortunately, other features of Notes are already working on iOS. For instance, Mountain Lion allows you to create rich text, bulleted items, and numbered lists, all of which are synced back to iOS 5.1 even when using a different font. These formatting options, including font selection, are available in the Format menu. Interestingly, Apple decided to put the Default Font options (Noteworthy, Marker Felt, Helvetica) here instead of in the app’s settings like on iOS.
Thanks to the Format menu, you’ll get access to far more rich text controls than simply lists and rich text. With it you’ll be able to choose any font installed on your system, pick a color, set an indentation, and increase or decrease font size. Unlike image attachments, these settings do sync back to iOS (albeit only for fonts shared across the two platforms, such as Futura).
Mountain Lion also lets you pin your notes. To keep a note (or multiple ones) handy on your desktop, you can double-click it to have it open in a separate window that stays open even if you close (not quit) the Notes app. Sticky notes have a simpler window style focused on the legal pad background: when active, even the “traffic lights” lose their typical red/yellow/green colors in order to emphasize the note’s content (though they do get their color back on hover). You can drag and drop media into sticky notes, and if you choose to hide the main Notes application when using them, you can bring back the app at any time by selecting Window > Notes from the menu bar (or pressing Command–0).
The more practical problem with Notes is that its overly skeuomorphic design can sometimes get in the way of the user experience. In the OS X Interface Guidelines, Apple clearly states that “metaphors should suggest a use for a particular element, but that use doesn’t have to limit the implementation of the metaphor”. While not as heavily influenced by physical metaphors as Calendar or Contacts, Apple’s Notes app seems to be driven, rather than enhanced, by its design. It’s not inherently “bad” — I am not discussing taste here — but I am arguing that, for example, the light color of the notes panel doesn’t make the view and compose button “pop” as much as they should. Similarly, the full screen controller in the title bar is somewhat hidden among the brown leather texture, and the lack of color in the sidebar makes it harder to differentiate between accounts and notes.
Still, it’s easy to see why Mountain Lion’s Notes app will be a huge hit among users. With a consistent design that should be easily understandable and approachable by people familiar with iOS, Notes is easy to use, syncs quickly with iCloud, and will get indirectly better when Apple upgrades the mobile version with iOS 6. Power users will likely stick with something else (as of now Notes doesn’t even have a system Service) but with attachments, list creation, sticky notes, and sharing, I predict a fast adoption of Apple’s new desktop note-taking application.
A new stock app on Mountain Lion, Reminders too aims to recreate its mobile counterpart on the desktop. Almost identical to the iPad app in terms of menu and button placement, design, and interactions, Reminders doesn’t suffer from Notes’ “wait for iOS 6” problem that prevents certain features from working on iOS today. For all intents and purposes, it is the same application with the same features and shortcomings.
What we wrote in our Reminders Overview for iOS 5 still applies here. Reminders are organized in lists, with options to search and browse by date. A Reminders account can be configured with iCloud, or any other CalDAV account, through System Preferences. You can choose to be reminded “on a day” by entering a due date, or “at a location” by manually entering an address you can “leave” or “arrive at”. Reminders can have notes and priorities, and they can be set to repeat every day, week, two weeks, month, or year. Overall, Reminders is a very straightforward to-do list application with the added benefit of geofencing support (the technology that determines the “radius” that calculates when you leave or arrive at a location).
That said, Mountain Lion’s Reminders does have some unique features and design choices that, as I discussed above, make it a true Mac app rather than a simple iOS port. In the app’s sidebar you can bring up a dedicated calendar panel to view items by date (you can also invoke it with the keyboard shortcut Command-Option-K). Unlike the iPad app there is no dedicated button to jump to “Today”, but in its place it offers another keyboard shortcut, Command-T.
In the calendar, the current day is selected by default (with a depressed appearance), and you can cycle through months by clicking the navigation arrows next to the month’s name. You can dismiss the calendar at any time and even hide the sidebar entirely, opting to use a simpler card-based layout that highlights one of Mountain Lion’s new gestures: horizontal swiping.
I know what you’re thinking — users have been able to swipe to change views or navigate content for years now. Mountain Lion, however, introduces a swiping method based on the new NSPageController class. For developers, this means faster, more reliable swipes, greater control, and fewer lines of code. NSPageController comes with three transition styles: history (like the one used in Safari), book (used in Preview, and generally recommended for browsing pictures and pages), and strip (used by the OS’ own full-screen mode). The App Store and Dictionary app also rely on NSPageController’s history mode for navigation, and Reminders implements this functionality for moving between “pages” of reminder lists and days in the calendar.
Gesture navigation in Reminders is available regardless of whether you choose to hide the sidebar or not, but it obviously makes more sense when less interface chrome is displayed as it allows you to rely on your fingers and eschew the need for sidebar elements, saving precious pixels on your Mac’s display. In my daily usage I have found this to be particularly useful on my MacBook Air, where I feel the screen’s constraints and try to save as much space as possible. The gesture can only be performed on the upper portion of a page, where a day or list name is displayed. It works with two fingers and the animation is quite smooth, although I’d still like it to be a tad faster. If you keep your reminders organized in multiple lists the gesture will come in handy.
Like Notes, Reminders allows you to open lists separately and “pin” them on your desktop. In Reminders, this is accomplished by hitting Command-Return on a list’s name, with Command–0 assigned to letting you re-open the main app in case it becomes hidden. You can also select a specific day and pin it to your desktop.
Unlike Notes single reminders can’t be dragged onto another list, but you can use a “Move to List” contextual menu that simplifies the process of re-assigning reminders to another list. You can also copy/cut and paste items if you don’t like using the contextual menu.
Single reminders can, however, be dragged to the Finder. Doing so creates a new .ics file with a nice Reminders-themed icon that contains the actual name of your reminder (you can even preview the .ics file, as shown below).
Using “Open With” on the .ics file will reveal options to open using CalendarFileHandler (which opens Reminders and lets you select a different list upon importing), Reminders, and Calendar, although Calendar can’t actually open Reminders-made .ics files (I assume Apple threw in some Reminders-specific code to restrict the importing process to its original app). Why would you want to do this, you might ask? Because it’s an interesting way of manually sharing single reminders with someone else. Of course you can also always export entire lists from the File > Export menu.
Creating new reminders is fairly straightforward: just start typing and hit Enter. While typing, you can use expressions like “today” or “on Sunday” to have the app automatically parse the information as a due date (though don’t expect the same support for natural language input seen in apps like Fantastical). You can edit a reminder by clicking the little “i” icon that appears when hovering over it, or by clicking on “Show Info” in the contextual menu. This action will open a separate popover with options to set priority, attach a note (hyperlinks are supported and clickable), or choose to be reminded on a day or at a location. Location can be set to “arriving” or “leaving”, and you need to manually type the address (or just use the current location) as the app doesn’t have the same kind of integration with your contacts’ addresses that it does on iOS. You can’t even paste Google Maps URLs (which the Contacts app can generate from your addresses) as Reminders won’t recognize them.
As I wrote back in October, Reminders isn’t Apple’s direct answer to GTD apps like OmniFocus or Things, but it should serve as a capable lightweight todo manager for many (and at least spare them from having to use Notes for todos). That said, there are still some shortcomings that even casual users are likely to notice. Location support doesn’t feel as integrated and reliable as on iOS, and there is no way to quickly capture a reminder through an OmniFocus-like system-wide shortcut (though Reminders does come with an AppleScript dictionary, which should make for some interesting scripting possibilities).
With iCloud sync and future web access, Reminders ultimately makes the Mac work better with the iPhone and iPad, and that’s a good thing if you rely on it for task management.
Calendars and Contacts
Brent Simmons, writing about Lion’s iCal last year:
If this rumored new UI for iCal is real and not just a mockup by a misanthropic Photoshop sadist, then I’m going to be distracted forever by the bits of torn paper under the toolbar.
I say “forever” not for hyperbole’s sake but because I already have an example: the trash can. When there’s something in there, it’s not right, and I have to empty it right away.
On Lion, iCal’s real-life leather calendar appearance forced Apple to avoid several features that wouldn’t fit with its look, while Address Book’s new book-like window layout actually made it harder to switch between pages (which is kind of funny for an application that wants to resemble a book).
In Mountain Lion, Apple is trying to set things right without moving away from the skeuomorphic metaphors introduced last year. Thinking that power users will eventually get used to the new interface designs, Apple is, once again, primarily targeting the average consumer, who will find (slightly) improved versions of applications they are already familiar with from the iPad.
When Lion came out last year, one of the complaints leveled against apps like iCal was that they were too confusing to navigate. This year, it seems like Apple has addressed those complaints with sidebars, which they seem to think are a one-size-fits-all remedy to all such navigational challenges. Just like with Notes the iCal and Address Book apps (now Calendar and Contacts à la iOS) sport a new sidebar on the left to easily access configured calendars and groups.
In Calendar, Apple must have thought that Lion’s popover wasn’t cutting it for users who have dozens of calendars and subscriptions, and thus went all the way to create a Calendar List. Now, in Mountain Lion, pressing a button in Calendar’s toolbar will open a sidebar listing all your calendar accounts and subscriptions, as well as a date navigator at the bottom. Calendars can be scrolled vertically, and the calendar at the bottom can be expanded to reveal more months. While still sporting unnecessary bits of torn paper along the top, the new Calendar List is a decent compromise between usability and screen real-estate.
Apple has also thankfully removed the leather stitching that was wasting around 20 pixels in Lion.
Calendar has been updated to support more search features with suggestions and tokens. Now when you search for an event, Calendar offers live-updating suggestions to make it easier to find what you’re looking for. As you click on a suggestion Calendar creates a token, and you can combine multiple tokens to refine your search. Unfortunately I was disappointed to see you can’t create advanced tokens like “next week” or “birthdays in the next month”; the app seems to be limited to titles, locations, and “title contains” tokens.
Finally, if creating new events in Calendar is your thing (whether by choice or necessity) there is now a simplified date picker that displays a mini calendar.
The “new” Contacts app introduces even less changes: specifically, two. Now, the Groups view (Command–1) displays a sidebar for your groups, and a “unified view” displays information from multiple services in a single card. To be honest, the Groups sidebar hasn’t been all that useful to me, but it’s still a better solution than Apple’s previous click-on-the-bookmark idea introduced with OS X Lion.
The Contacts app remains an unwieldy conglomerate of paper, lists, buttons, and book covers that tries to blend the physical metaphor of the address book with digital aspects like grouping, sharing, and search, failing miserably at both. In the future, I hope Apple will try to simplify it rather than keep trying to force its two opposing natures to work together.
For the past two years I’ve been using Google Chrome as my default desktop web browser. The combination of a fast rendering engine, pinnable tabs, and my browser tabs and settings synced across computers lured me (a formerly devoted Firefox user) into using Chrome for my everyday web activity, which mainly consists of researching, writing, and reading.
With Mountain Lion, I have switched to Safari, and I am not looking back.
For me, Safari for OS X has always been a difficult case to argue for. Its elegance, adherence to interface guidelines, and overall “made in Cupertino” feel clashed with its inexplicable lack of features compared to almost every other browser on the market — namely sync, pinnable tabs, a unified address bar, and autofill for saved passwords and logins. I wanted to make Safari fit into my workflow, but I couldn’t because of the lack of features I had gotten used to that I knew I couldn’t work without — at least, not without altering my well-established browser workflow.
In Mountain Lion, it’s immediately clear that Apple not only wants to make things right with Safari, they want to go the extra mile to deliver a better experience than its competitors.
Apple’s course of action for the latest version of Safari is fourfold: improving performance, smoothing rough edges, adding new features, and enhancing integration with iCloud. Let’s start with the last one.
We now live in a connected era where desktop computers are no longer the only ones we use. We have iPhones, iPads, and iPod touches, each of which can plug into Apple’s ecosystem to sync personal information, documents, and data through iCloud. So why not provide the same kind of seamless connected experience with Safari, the app that millions of people use on a daily basis as their main window into the Internet?
It always sounded like a fairly simple goal to accomplish: the next logical step towards the “continuous client” that many predicted and theorized back when iCloud was only a distant dream. Here’s Joshua Topolsky, writing about the Continuous Client in 2010 for Engadget:
So what is a Continuous Client you ask? Well the premise is simple: when you leave one device, you pick up your session in exactly the same place on the next device you use. Meaning your IM, Twitter, web browsing, applications, even your windows (given the availability of such a thing on the corresponding platform) appear just as they did on the previous device. The situation I describe above would be obviated by this setup, allowing me to move from my laptop to iPad in a seamless manner which would in no way disrupt the activity I was currently engaged in.
More devices inevitably lead to more information to keep synced and available. As our devices and apps move to cloud-based architectures and document storage, it will become increasingly necessary for each app to include syncing that’s both invisible and accessible, transparent and powerful. With iCloud Tabs in Mountain Lion, Apple is taking the next logical step towards that goal: making your browser tabs live on iCloud rather than your computer.
As you would expect from Apple, iCloud Tabs have been implemented in a simple and straightforward manner. Every Safari tab you open on both Mountain Lion and iOS 6 can be viewed and visited through the new iCloud button in the browser’s toolbar. iCloud tabs are listed under each device by their respective webpage title (not URL). By default, clicking an iCloud tab will open it in the current tab, but you can also Command-click them to have them open in a new one. iCloud tabs also can’t be closed remotely, so the way you left Safari on a particular device is the way its tabs will show up on another device. According to Apple, iCloud tabs are pruned automatically after a device hasn’t been seen online for over a week; I would like to see a more explicit way of removing remote tabs in a future version of Safari.
So does Safari send every open webpage to iCloud if you check the Safari box in iCloud System Preferences? Yes, but there is a way — albeit an inconvenient one — to prevent this without going to System Preferences or forcing yourself to remember to close every tab you want to keep local: turn on Private Browsing. Once on, all the Safari tabs on that device will vanish from iCloud and stay that way until you turn it back off. While this may not be ideal — for example, you may want to keep a certain tab in your browser history without sending it to iCloud, which is impossible with this method — it can still be quicker and easier than turning Safari sync on and off in System Preferences.
I think iCloud Tabs is a powerful idea. It helps make palpable the concept behind iCloud — something which, even after nine months, many people still don’t fully grasp — through a feature everyone is used to: tabs. In my testing, iCloud tabs have worked reliably and made switching between my two Macs much easier. Previously, I used to email web links to myself or use something like Send2Mac to share webpages across computers. Not anymore. iCloud Tabs is already extremely useful, and it’ll prove even better once iOS 6 ships later this year.
Next up: Reading List. Another feature that premiered last year, Apple has improved it considerably with the addition of offline support. Now any webpage added to your Reading List (either by hitting Command-Shift-D or opening the Reading List sidebar and clicking Add Page) will be downloaded and saved to your Mac. This way you can read articles, recipes, and any other webpage you’ve saved even when you don’t have an Internet connection. Furthermore, if an article is split into multiple pages Reading List will download and save all of them, allowing you to click through the entire piece when catching up on your reading.
The most visible change to Safari 6.0 isn’t a feature of iCloud or new chrome. Instead, after years of requests and various takes by companies like Google and Mozilla, Apple has finally delivered a unified address bar that accepts both URLs and search results. Dubbed the “smart search field”, the impact this seemingly small addition brings to the Safari browsing experience cannot be underestimated.
In spite of the rise of mobile in terms of web traffic and searches, people still use Google a lot on the desktop. In Google Chrome — the most popular desktop browser around these days, mainly thanks to Google’s relentless push on its homepage and services — the unification of the address bar with search results helps drive more clicks towards Google’s search results, which is where they make most of their profits (with ads). Basically, Google is exploiting a convenient feature for their own interests. And while there’s nothing wrong about that — after all, using Chrome is a choice, not a necessity — it’s important to keep in mind the reasons why companies do what they do. In Apple’s case, why would they want to help send more people Google’s way?
The answer: to provide a better Safari sub-ecosystem across iOS and OS X, get more people to use iCloud Tabs, and let them experience the benefits of having multiple devices plugged into a single account. It’s a clever choice and, at this point, the right thing to do, as smart search fields (at least when implemented correctly) have more than proven their value by now. In fact, I wouldn’t be surprised to learn that Apple themselves found that some customers weren’t using Safari primarily because it didn’t have one. And if people don’t use Safari, they can’t enjoy features such as iCloud Tabs and the offline Reading List, which could be a great way for them to get started with iCloud.
As I wrote above, Apple wants you to have an iCloud account in Mountain Lion. Just as Google’s attention to search is representative of the company’s primary source of revenue, Apple’s willingness to produce a better Safari is instrumental to getting more people to use Safari, and subsequently to hook them on iCloud’s capabilities.
At any rate, regardless of Apple’s reasons for finally implementing a smart search field, using it is a pleasure, and one of the main reasons I have decided to come back to Safari after years of browsing with Chrome. Not only is it hugely convenient, it also learns from your habits, improving the Top Hits results over time as you select items from Google Search, history, and bookmarks. In fact, the new address bar is built so that search results, your bookmarks, and your recent history are all displayed in the same menu, making it easy to find what you want from any of them. In addition to Top Hits, five Google results, and bookmarks and recent history, Safari also offers a button to look through your entire history — useful if you keep Safari set to remember webpages for more than a few months.
That said, there is one aspect to the new smart search field I don’t care for: it no longer displays Google Search URLs after you’ve used it to search for something. So if you want to share a direct link to a Google Search, you’ll need to copy it from the share sheet in either Messages or Mail.
As an aside, it’s worth pointing out that Safari, like all major browsers, lets you change your default search engine. To do so, you’ll have to visit the General section in Safari’s Preferences; once there, you can choose between Google (which is set by default), Yahoo, and Bing. So while theoretically this could result in users searching with another engine, and thus avoid the problem (for Apple) of sending more traffic Google’s way, because most people never change their computer’s default settings — let alone the browser’s — I do believe Mountain Lion will consistently drive more traffic to Google thanks to the new address bar.
One thing missing from the new Safari is the dedicated RSS reader, which is gone in Mountain Lion. Introduced with Safari 2 in OS X Tiger, RSS support in Safari allowed users to read news right in their browser. In 2007 Apple brought RSS to Mail, giving users a way to read news alongside the email messages in their inbox.
The exclusion of RSS from Safari 6.0 is a decision I can’t really explain. While RSS has admittedly never been a mass-market feature, its implementation in Safari was still very useful and got a lot of people who may have never learned about it otherwise to start using it. It never got in the way if you didn’t use it, but if you did it was fun and easy to do so. And even if you didn’t use Safari’s RSS reader, but instead opted to use an app like NetNewsWire or Reeder, the RSS button in its address bar was still great for finding a site’s feed. But alas, in Mountain Lion, RSS in Apple applications is no more. Perhaps Apple sees eliminating this functionality as “progress” — a way to cut resources and support requests from a technology that’s on its way out. Or perhaps they couldn’t find a way to make it work with iCloud, and thus every other device in their ecosystem. Either way, if you want to find RSS feeds in Mountain Lion’s Safari you’ll now have to use a bookmarklet or extension.
Getting back to tabs, Safari 6.0 borrows heavily from the iPhone in a new feature Apple calls “Tab View”. Another feature that has already been implemented in some form or another by other browsers, Tab View provides an elegant way of switching between tabs using a combination of pinch gestures, swipes, and large “card previews” reminiscent of MobileSafari’s page switcher.
To use Tab View, simply pinch in to zoom out beyond the webpage, which will rearrange your tabs into “cards”. If you have multiple cards you can swipe with two fingers to flick between them, much like you would with one finger on the iPhone. Animations are snappy and responsive on my 2011 MacBook Air, and I like how Tab View displays live previews (for example, YouTube videos will keep playing) alongside a webpage’s name and URL. Also, note the tab resizing animation in the screenshots below.
That said, while visually appealing, I don’t know why would anyone use Tab View over regular plain old tabs. Sure they can be a nice alternative for people who tend to keep only a few tabs open — but does flicking through tabs really make that much of a difference? In my experience, while it may be nice to look at, Tab View just doesn’t work for power users who keep dozens of tabs open. And for those who prefer opening windows to tabs, Tab View actually requires more clicks and swipes to switch pages than regular old clicking. At first I was going to call Tab View “the Launchpad of browser tabs”, but even Launchpad is faster and more accessible thanks to its Dock icon, trackpad gesture, and the ability to assign it a keyboard shortcut or Hot Corner. So while Tab View is elegant, and can provide a nice alternative to regular tabs for those who don’t keep many tabs open, I’m afraid it isn’t for me.
Another addition to Safari 6.0 is support for the HTML5 web notifications standard. With a new Notifications pane inside its preferences, Safari can now display alerts in Notification Center for websites that have asked for, and been granted, permission to do so.
In my daily browsing routine I haven’t found many websites that support HTML5 notifications yet (personally, I would love to see Twitter and Facebook support them), but you can get a demo of the technology here. Like all notifications in Mountain Lion, you can tweak the behavior of Safari’s web notifications in the Notifications pane in System Preferences.
As for user-facing improvements, Safari now implements Do Not Track, a new privacy standard that asks websites you’re visiting not to track you online. This can be enabled in Preferences > Privacy > Website tracking. Speaking of privacy, Safari also now has better management for saved passwords. While Safari has long supported automatic fill-in for web forms, now it will also ask to save your password for any website you log into and fill it in for you the next time you visit. Passwords (as well as usernames and domains) you save are stored in the new Passwords section in Safari’s Preferences. If you forget a password, Safari allows you to reveal them with your OS X account password. While this feature is no 1Password, thanks to its search and simplified interface Safari’s Password AutoFill and management will surely get the job done for most people.
If, like me, you keep bookmarks in the bookmarks bar, you’ll be glad to know you can now rename them by clicking and holding their names. This works with folders too, and I have been using this minor feature extensively to adjust the names of my various bookmarklets without opening the bookmark manager.
Safari 6.0 also supports share sheets. Of the ones currently offered I use the email one a lot, as it allows me to easily email links to friends and colleagues or forward them to other services like Evernote and Instapaper. When I first tried the email sheet I was annoyed by the fact that Mail was sending entire webpages rather than their URLs. To change this behavior, you need to change the default “Send Web Content as” option in the Mail sheet that appears after you click the share button in Safari. You can choose between content, link, PDF, or — if the page is already open with Safari Reader — the aptly-named “Reader” setting.
For the first time in years I am excited about Safari thanks to one key word: integration. I was fine with using Chrome because it was faster, more reliable, and even if I couldn’t sync its tabs and settings with iOS at least I could sync them across my Macs. But with iCloud, things have changed: bookmark sync is invisible and fast, and I can now access my tabs across both my Macs and my iOS devices without using a third-party hack or (worse) emailing links to myself. We’ll have to wait for the fall for iOS devices to get iCloud Tabs, but until then, I think I’ll be very happy with Safari 6.0 on my Macs.
Mail may not have received a major overhaul like its 5.0 upgrade in Lion, but it still sports a number of noteworthy additions focused, again, on iCloud and the upcoming iOS 6.
The most visible change in Mail 6.0 is the new VIP smart mailbox. A big part of the iOS 6 announcement at WWDC, VIPs let you “star” the important people in your life — your dad, your boss, your fiancée, and so on — to ensure you will never miss a message from them. For instance, you can set up rules in Mail that check whether or not a sender is a VIP (thanks to a new “Sender is VIP” condition), which allows for lots of new possibilities for customization and priority management. Just to give you an example: you could set up a Mail rule that fires up an AppleScript to start a backup of your Mac every time you receive a scheduled email from IFTTT. It’s not the most “native” solution for scheduled backups, but it works thanks to Mail’s support for VIPs.
To add someone as a VIP, just click on an email address in the message header and select Add to VIPs. Alternatively, you can also click on the star icon next to a sender’s address, though I don’t think you can tell whether a person has been added to VIPs simply by looking at the icon change. Once a contact has been VIPed, the star icon gets added to the message list and replaces the circular unread indicator.
Mail 6.0 also comes with some new navigation options to speed up the process of finding messages from your VIPs. The new VIP smart mailbox, for instance, has been added as a default choice to the Favorites bar, providing an easy shortcut to all the messages from the people you care about. If you’re more of a keyboard junkie (like me), you can navigate to this mailbox (assuming you haven’t changed its default position) with Command–2.
Clicking on the VIP mailbox in the Favorites bar reveals a menu to filter the mailbox by contact. In fact, each contact added to VIPs gets their own mailbox to help you get to those messages faster.
VIPs are also added to the sidebar, though you can’t customize them like you can with Favorites in the Finder. In my own workflow, I have been increasingly using Mail with a hidden mailbox list, relying on navigation between the Inbox and VIP mailbox exclusively through the Favorites bar and the keyboard.
VIPs have also been integrated with Mail’s notifications. In addition to creating rules that look for VIP senders, you can tweak Mail’s new message notifications so that only emails from important contacts will be forwarded to Notification Center (depending on your settings). By default you can choose to receive new message notifications for Inbox only, VIPs, Contacts, All Mailboxes, or messages falling into the smart mailbox “Today”. While it may not be groundbreaking, being able to selectively choose which messages merit a notification (taking care of more particular cases with Rules) is a welcome addition to Mail.
Mail 6.0 also lets you use inline search to comb the contents of your messages. Now whenever you’re looking for a specific word or phrase inside a message, simply hit Command-F and start typing. Mail will then highlight all the text that matches your search terms while dimming the rest of the message using the same highlighting system seen in Safari. The search bar at the top displays the total number of results alongside a “Done” button and navigational arrows; you can also jump to the next result with Command-G, and the previous result with Command-Shift-G.
If you’re looking for a specific message using Mailbox Search but then decide to switch to inline message search, Mail will automatically fill the search box with the search token you were using.
There are a couple of hidden tricks for inline search that you might want to take advantage of to refine or speed up your searches. In the search bar, you can click on the disclosure triangle to bring up options for case sensitive matching and to disable wrapping. You can choose whether you want results that contain or start with a specific term, and you can see your most recent searches as well.
If you want to search for other instances of a particular word inside a message, try hitting Command-E, the shortcut for Use Selection for Find (also available in the Edit > Find menu). Doing so will “copy” the currently selected word to the search field; from there, just press Command-F to start searching and the search field will be populated with your selection automatically.
Also, for those concerned: Find and Replace is still available when you’re composing a new message. I believe Apple made a clever decision in separating inline search from the old Find and Replace functionality, as being unable to replace text in an incoming message was confusing to some people. The new inline search is easy to use and consistent with the implementation in Safari.
Of course Apple didn’t forget to make Mail 6.0 iCloud-enabled. If you’re using iCloud, Mail will push rules, signatures, smart mailboxes, flag names, favorites, and recent senders to other devices configured with iCloud. This includes Macs running Mountain Lion and, as you would expect, iOS devices with iOS 6 (which is currently only available as a developer beta). In my tests Mail synced signatures, VIPs, rules and mailboxes reliably across Macs.
Mail 6.0 is a solid update, but as with other iCloud-based and iOS-inspired features of Mountain Lion many of the new functionalities it introduces will only be fully appreciable when iOS 6 ships later this year. For example, right now VIPs are a neat way to organize your favorite contacts on the desktop, but they’ll be truly useful once I can sync them back to my iPhone and iPad. However, there is one little touch that I’m happy Apple chose to bring to the desktop: like on iOS you can now click the Sort bar at the top to scroll all the way up. While an admittedly minuscule feature, it’s nonetheless a huge timesaver for me.
Apple’s image and document previewer has also received a few additions in Mountain Lion. Like TextEdit, Preview now comes with iCloud Document Library, so any file you save with Preview can always be available in the cloud. While there’s still no Preview app for iOS (see also: TextEdit), you will be able to open your documents on other Macs running Mountain Lion. If you prefer to share your documents or images with other people, Preview has been updated to include share sheets for Messages, Email, AirDrop, Flickr, and Twitter as well.
The other changes touch upon Preview’s annotation capabilities. When viewing PDFs you can now add inline notes. Simply select the area of your document where you want to add a note, type, and your comment will be saved inside a yellow post-it with the text automatically hidden from view. If you click on it, the note will expand to reveal the text.
To add a note you’ll have to bring up the Note menu available in Tools > Annotate. This menu also lets you select the default color for highlights, which can be inserted by selecting text and applying the highlight from the right-click contextual menu. Both notes and highlights can be removed by right-clicking and reverting to the document’s original style.
In Preview 6.0, notes and highlights can be viewed all together, and you can also search for them in PDFs by either author or content. All your highlights and notes are available in a new sidebar that you can invoke by hitting Command-Option–4 or by selecting Highlights and Notes from the View menu. As you select an annotation or note from the sidebar, Preview will automatically jump to it. Items in this sidebar are sorted by page, and you can hit backspace to delete them if you don’t want to right-click on the content.
I keep all my research PDFs in Dropbox and mainly read them on my iPad using PDF Expert, a third-party app that can apply annotations and auto-sync an entire folder with Dropbox. On the Mac I use Preview, and I appreciate the annotation-oriented changes of version 6.0. I do, however, miss the ability to email and export annotations as plain text or HTML — a feature that is available in several PDF-reading applications for iOS. The new Highlights and Notes sidebar is a welcome addition, but I can’t help but wish Apple had added more options for it, especially on the exporting side.
Apple has also made it easier to insert a page from a scanner into an existing document. Choose Edit > Insert > Page from Scanner, and a new interface will come up to let you scan a page and add it to your document. In the page browser on the left you can move the newly-generated blank thumbnail around to tweak the point of insertion. Hit the close button on the thumbnail to discard changes.
Last, PDF forms. On iOS, a number of applications have surfaced on the App Store to let you easily fill out areas intended for text entry. On Mountain Lion, Preview should now be able to detect these areas automatically: in an open document, click on boxes, underlining, or checkboxes to select them and enter your text.
But my favorite new “feature” of Preview isn’t related to annotations, highlights, or scanned pages. Instead, I’m just glad version 6.0 doesn’t crash as often as 5.0 did on Lion.
Mountain Lion isn’t just about the apps that have been added or refined. The operating system itself has gained a number of new features that are directed at making the overall experience smarter and more intuitive.
A major new feature in Mountain Lion, Notification Center borrows heavily from iOS 5 to bring a consolidated system for app and system notifications to OS X. Located at the right side of the screen, rather than at the top as on the iPhone and iPad, Notification Center presents a list of all notifications from apps that have been updated to take advantage of it, such as Apple’s own apps and third-party apps like Sparrow. As part of Mountain Lion’s new Sharing features, Notification Center also displays incoming Twitter replies and direct messages and lets you post straight to Twitter without the need for a Twitter client (these options will also come to iOS 6).
Per Apple’s implementation of Twitter in Notification Center, Twitter replies and DMs are truncated if they exceed a certain length and clicking on them will open the Twitter website, not the official Mac client or one chosen by the user. For this reason, I try to avoid clicking on the Twitter notifications — I don’t like being yanked out of my default client, Tweetbot, to wait for Twitter.com to load — but I have to admire the speed with which they’re delivered.
Now, I’d like to address the concerns regarding Notification Center and the popular third-party notification utility for OS X, Growl. After Mountain Lion was announced in February, many were quick to speculate how Apple’s new integrated notification solution would “Sherlock” Growl. Because Notification Center is built into the system in a way a third-party app can never be, some people argued that it would eliminate the need for something like Growl, which for years provided Mac users with a solid and unobtrusive notification system adopted by hundreds, if not thousands, of applications.
As usual, there’s more to this story than sensationalist headlines and baseless speculation. When Apple introduces a new functionality or application that could theoretically replace a third-party app, there’s always the fear that Apple’s take on the subject will automatically make that app useless or redundant. With Growl, the concern is that it no longer has any reason to exist now that Notification Center is here.
We need to make a distinction about the kind of user base that Apple typically targets with their apps and features. Notification Center is a great addition to OS X: it makes it more connected, and it allows developers to leverage APIs that will make their apps present information to the user in a more straightforward and intuitive manner. However, the user Apple had in mind when they built Notification Center isn’t necessarily the same one that uses Growl on a daily basis. Growl has always offered so-called power user features like network monitoring, app-specific settings, and various customization options that, by design, Notification Center won’t have. Notification Center is all about bringing standard notifications to any app, while Growl wants to provide more control to users who want more from their notifications. In a way, Growl is to Notification Center what Instapaper is to Reading List: a richer, more powerful solution for users willing to look beyond Apple’s built-in apps. That alone gives Growl a reason to live on and prosper.
But that’s not all there is to the story: as it turns out, Growl will support Notification Center. Right now the details are still fuzzy, but apparently its developers have figured out a way to integrate with Apple’s solution without limiting the benefits offered by the Growl API and support for any third-party app. As the Growl developers themselves wrote back in June:
For Growl 2 we’re simply going to add a Notification Center action display as well. This is going to make it easy for anyone who wants to see notifications in Growl, and also in Notification Center. We don’t know of any downside to doing this, and see it as sort of a simple yet powerful way to get what you want done. There may be some caveates to doing this that we can talk about once 10.8 is out, but there may not be. We’ll all just find out together.
The single most important point in this discussion is the fact that Notification Center will only work with apps sold on the Mac App Store, while Growl will support any app regardless of whether they’re sold on the Mac App Store or somewhere else. And because Growl itself is available on the Mac App Store, it has a chance of becoming an Apple-sanctioned solution to act as a bridge between Notification Center and apps sold outside of the Mac App Store, which Apple will support on Mountain Lion thanks to Gatekeeper. So while we don’t know much about the Growl 2.0 update yet, it’s good to know its developers are thinking about ways to combine the advantages of Notification Center with their app’s extended controls and UI modifications — which continue to be the hallmark features of Growl to this day.
As for Notification Center as it stands now, I have found it to be just as worthwhile an addition to my daily workflow as it was on iOS. Not only does it make it easier to check all my missed notifications, it’s also neatly integrated with OS X itself, displaying alerts for software updates, calendar events, and messages. By working with any app, in any view, Notification Center provides a convenient solution for consolidating your notifications and making sure you won’t miss any. In the future, I hope that Notification Center will integrate with iCloud more deeply by allowing me to “sync” read notifications across devices so I won’t have to see (and clear) them again on my iPhone or iPad; and, like I mentioned above, I look forward to integrating it with the notification app I’ve been using every day for the past three years: Growl.
For a complete overview of Notification Center, check out Mountain Lion: Notification Center Explained.
Built into Mountain Lion is a new sharing system that allows users to share different file types and information across a variety of services. These services include Twitter, Flickr, Vimeo, system features like AirDrop, Messages, and Mail, and later this year, Facebook. The new Share menu can be found throughout the OS and works with any Apple application that handles pictures, videos, or web links.
Inspired by the “tweet sheet” introduced with iOS 5 for Twitter integration, Mountain Lion’s revamped sharing mechanism relies on the concept of “cards” for displaying the content you’re sharing. Depending on the service or system function you’re using to share, the card will display different options and controls to let you select recipients, add tags, write descriptions, and more.
For instance, any file or web link can be shared via the new Messages app. Once selected in the Finder or Safari, the file or URL will be passed along to the Messages card (using a simple, beautiful animation) and bring up a pop-up window that will let you enter a recipient, text, and optional smileys.
Similarly, sharing via AirDrop no longer requires opening the standalone AirDrop window. You can now select any file in the Finder and instantly beam it to nearby AirDrop users.
More system features have also found their place in the new Share menu. Reading List, for instance, can now add webpages by right-clicking on any http:// link in apps that have been updated to use the NSSharingService API. Mail too has been listed as a compatible sharing service for files and links, although sharing through it will launch the entire application rather than a sharing card.
But apps aren’t the only way to share things in Mountain Lion: Internet services play a big role as well. Already available in Lion’s QuickTime, Vimeo and Flickr have now received their own dedicated login panels in System Preferences under Mail, Contacts & Calendars.
Each service has been implemented with their own variety of “tweet sheet”, complete with appropriate branding and tweaks to accommodate their different features. Flickr lets you upload images and choose a title, description, and tags while setting access to private or public, while Vimeo lets you do the same for videos. Interestingly, both Vimeo and Flickr use a standard Finder dialog to handle their upload and confirmation process.
YouTube, while still available inside QuickTime, has (unsurprisingly) been excluded from the list of services that got a fancy new sharing card; now Vimeo is the only service for sharing videos that’s available in System Preferences and the new Share menu. And then, of course, there’s Twitter, which is integrated at the system level to let you tweet from supported applications (including Notification Center), send you notifications, update contact pictures, and allow third-party apps to access your credentials using single sign-on à la iOS.
Mountain Lion’s tweet sheet supports photos and links from Safari, iPhoto, and other apps (including Quick Look), but you can also tweet “regular” updates without attaching media by using Notification Center. The tweet sheet includes location support, a multi-account switcher, character count, and username auto-completion.
Speaking of location, apps and services that have requested to use it — such as Twitter — will appear in the Location Services section under System Preferences → Security & Privacy → Privacy. There, you’ll also find apps that have requested to use your Twitter credentials for single sign-on.
By the way, here’s a little tip for you keyboard users: by default, Twitter integration on Mountain Lion doesn’t come with a system-wide keyboard shortcut for posting tweets. However, you can easily create one yourself by going to System Preferences → Keyboard → Keyboard Shortcuts, clicking on Application Shortcuts, hitting the little “+” button underneath the right panel, selecting Safari from the list of applications in the window that pops up, typing “Twitter” in the Menu Title field, and entering your preferred hotkey in the Keyboard Shortcut field. If, like me, you often find yourself tweeting webpages, adding a keyboard shortcut for this can be a great timesaver.
Bonus tip: you can repeat this process for other apps with actions that don’t have keyboard shortcuts assigned to them.
Mountain Lion’s new sharing is a good first step towards making the Mac more connected, social, and better integrated with Internet services. Whilst Facebook integration won’t ship until this fall, once it’s here I believe that it will become many people’s new favorite way of posting to Facebook (much like Twitter integration in iOS 5 increased user sign-ups dramatically). But the real fun will begin when third-party developers will start finding ways to leverage the sharing API to provide their own custom services to users. Imagine being able to send links and images through Tweetbot without needing to keep it open, or sharing a document on Dropbox without navigating through Finder and contextual menus. Mountain Lion’s sharing bodes well for better inter-app communication in the future, and I hope such changes will eventually find their way to iOS as well.
Scrolling and Gestures
When Lion came out last year, one of Apple’s most controversial changes was “natural scrolling”. Taking a page from the iOS handbook of “content follows your fingers”, Apple went against two decades of desktop scrolling conventions when they inverted the default direction in which content moves on the screen.
Before Lion, scrolling content meant scrolling its scrollbar. Move the scrollbar up and the content would go up, move it down and the content would follow suit. But in Lion, rather than manipulating scrollbars, Apple wanted Mac users to directly manipulate the content, and thus changed the scrolling defaults so that scrolling the content up would now move the scrollbar down. While this did prove to be a stronger and, arguably, more natural metaphor, it nonetheless took a while for long-time computer users to adjust.
Despite the time Apple gave developers and bloggers to become accustomed to the new scrolling system (which can still be disabled in System Preferences), when Lion was released publicly the outcry following the “discovery” of this change prompted a number of people to write entire blog posts and deep reflections on the hidden meaning and ultimate goal of natural scrolling.
The truth is, natural scrolling is just another refinement to make the Mac behave more like the iOS devices so many people are now familiar with. In fact, coming from an iPhone or iPad, a new Mac user in the pre-Lion era would likely have thought that the Mac’s way of scrolling was wrong. So with Lion, Apple proverbially skated to where the puck was going and reverted the default scrolling behavior to how most new Mac users would think it’s supposed to work: direct manipulation of the content.
Some people got used to this change quickly. Others (including me) needed time to adjust. But eventually, everyone got over it and started to appreciate the benefits of more direct control and UI consistency across their devices. As Shawn Blanc elegantly put it:
I gave it a second chance. It took me about 10 days to get used to it but now that’s ancient history.
Turns out: scrolling is kind of a big deal. Whether you’re browsing all day or organizing files in the Finder, people expect scrolling to behave consistently and naturally. Furthermore, it has to be invisible so that more content can be shown, but it also needs to provide location context so that users always know where they are. Scrolling, in fact, fills two roles: helping users manipulate content, and understanding their position within it.
In Mountain Lion, Apple has not only tweaked their scrolling technology to address the aforementioned points, they’ve also taken advantage of the fact that more and more people use multi-touch trackpads to provide new gestures and APIs for developers to use in their apps.
Mountain Lion’s overlay scrollbar maintains the rubber-banding effect introduced in Lion (when content is scrolled down past its limits à la iOS), but it’s also received a new look to allow for a better grip. Now when moving the cursor over the scrollbar, the bar expands to become easier to grab. This works for both horizontal scrollbars as well as vertical ones, and the bar also expands automatically if you start scrolling over the scrollbar while it’s still invisible. As before, dragging the scrollbar directly won’t activate rubber-banding.
Another small but welcome change: Mountain Lion’s scrollbar no longer blurs the background, making content much easier to enjoy.
As for context, Mountain Lion now lets you see the scrollbar even when not scrolling. For example, say you’re viewing a long document and you want to know how far along you are. If you’re using a trackpad, all you have to do is place two fingers on it to make the scrollbar appear; no scrolling required. Once there, the scrollbars will stay on the screen as long as you keep two fingers on the trackpad.
Being able to place two fingers to show the scrollbar is, in my opinion, one of those features that makes more sense the more you think about it. One of the major complaints from critics of Lion’s scrolling system was the inability to show context without scrolling, and Apple has tackled that issue with an elegant, unobtrusive solution. Rather than coming up with a completely new shortcut or gesture to show the scrollbar, Apple decided to have the user’s intent to start scrolling act as a trigger. This idea is also reflected by the system event Apple uses to implement this functionality: NSEventPhaseMayBegin, which is enabled in every stock Apple application (even the Finder). Third-party developers will need to adopt new APIs for this feature to appear in their apps.
Apple has also improved the way you can scroll a document quickly without needing to use the scrollbar. On Mountain Lion, if you perform a quick scrolling gesture three times in a row the scrolling speed will ramp up to let you reach the end of a document quickly. Apple calls this tweak “accelerated scrolling”, and, while invisible to the end user in terms of preferences or options, it makes for a more pleasant scrolling experience.
With new AppKit APIs for developers, Apple is also making it easier to adopt new, modern gestures aimed at providing better zooming behavior, dictionary look-ups, Quick Look previews, and page switching animations.
Using the new NSPageController, developers can take advantage of new transition styles to include visually-animated history navigation in their apps. You can see this in action in Apple apps like Safari, Preview, Reminders, App Store, Dictionary, or full-screen mode. Each of them (except full-screen mode) relies on two-finger swipes to display page navigation, albeit with slightly different styles.
Apple has also made a number of other improvements to OS X’s touch capabilities, like its response to taps for smart magnification and Quick Look previews on attachments. Like on iOS, double-clicking on text or an image inside a webpage will automatically center, zoom, and try to present it in the best way possible. When activated, Smart Magnification tries to determine if the content is already displayed at a 100% zoom level, and if so jumps to 150%. If the content is less than 100% it will be magnified to 100% instead. For developers, NSScrollView now comes with built-in support for the smart zoom gesture, and if developers provide a semantic layout of their applications the system will try to zoom the content intelligently. The new NSScrollView APIs are also used to implement the new look-up gesture for the Dictionary pop-up (three-finger tap instead of Lion’s three-finger double tap), which provides near-instant definitions for words, and Quick Look previews for attachments (the latter also works in text views). In apps like TextEdit you can pinch to zoom into a document, and a double-tap on the trackpad will go back to the original zoom level. Unfortunately it seems like Apple didn’t have time to make the auto-correction resolution independent, as shown below in all its pixellated glory.
If there’s one area that epitomizes the convergence of design ideas and user behavior across iOS and OS X, it’s multi-touch. Leather textures, Launchpad, and popovers are often regarded as examples of Apple making the Mac increasingly similar to iOS; some go further and say that Apple’s ultimate “iOS X” convergence goal is to lock down the Mac and embrace an App Store-only distribution model for apps. While I have already discussed these changes as aiming for familiarity and consistency (rather than the result of evil plans or blind copying), there is no doubt that Apple has taken some iOS elements and brought them to the Mac. But multi-touch is by far the biggest and most important one.
Thanks to multi-touch, iOS and OS X now have more interactions in common than ever. Apple understands that, at the end of the day, users prefer software that works to apps that merely look the same, and thus have put real effort into ensuring that touch navigation works consistently across platforms while still feeling uniquely suited to each device.
The idea of resting your fingers on a touch surface to show scrollbars was used first on iOS; now it’s been implemented on OS X as well. The same is true for pinch to zoom, smart magnification, rubber-banding, and, if you’ve turned on multi-touch gestures on your iPad, swiping between apps.
Other gestures are performed the same way but are associated with different functionalities, albeit ones that share the same concept. On OS X pinching with your thumb and three fingers brings up Launchpad; on the iPad the same gesture takes you back to the Home screen. On the iPad you can swipe up with four fingers to show the multitasking tray; on OS X that gesture activates Mission Control, the Mac’s take on visual multitasking.
One last point: some gestures work differently because Apple accounted for the differences that make each platform unique. On the Mac, the hovering cursor allows for three-finger-tap dictionary definitions and Quick Look previews; on iOS the Define action is accessible from the copy and paste popover. On Mountain Lion, Notification Center can be shown by swiping left with two fingers from the right edge of the trackpad — something only possible with tight hardware and software integration, and by leveraging hardware differences as catalysts for an experience that’s equal parts familiar and independent.
Apple has shown us that consistency and distinctiveness don’t have to be mutually exclusive. Touch interaction — again, not how software looks but how it works — is the poster child of Apple’s philosophy that OS X and iOS shouldn’t just resemble each other on the surface: they should work better together too.
If multi-touch represents the importance of familiarity in software, Mountain Lion’s Gatekeeper is Apple’s take on how it should be installed without giving up security.
Ever since software began to be distributed online, Mac users have been able to install apps downloaded from the Internet (usually a developer’s website). Mountain Lion doesn’t remove this ability, but it does introduce a new feature called Gatekeeper that aims to provide the user-facing benefits of the App Store for the trusted Mac developer community. The result is greater control over what software gets installed no matter where it comes from, for both Apple (who gets to decide which developers are trusted and which aren’t) and the user (who is free to turn off Gatekeeper or override it on a per-app basis).
Gatekeeper isn’t an app — it’s a new section in the System Preferences Security & Privacy pane. Essentially, it tells your Mac what kinds of downloaded applications are “trustworthy”. It has three settings, the default of which lets Mountain Lion launch apps both downloaded from the Mac App Store (which is controlled by Apple and theoretically secure) and from “identified developers”.
Software downloaded from identified developers outside the Mac App Store isn’t controlled by Apple, and thus can’t be guaranteed to be secure. With Gatekeeper, Apple has found a solution to combine the advantages of control with the freedom of downloading apps from the open Internet: certificates. “Identified” developers are just developers that have “signed” their software with a certificate issued by Apple. These certificates can be revoked at any time, and an application whose certificate has been revoked can no longer be launched.
But who is an “identified” developer, exactly? Simple: anyone who has taken the time to register with Apple. Once developers have registered with the Mac Developer Program (which costs $99 a year) they will get a free Developer ID that can be used to digitally sign applications, installer packages, widgets, and more. Upon first launching an app Gatekeeper will check to see whether or not it has been signed with a certificate, and if the certificate is valid. If both checks meet Gatekeeper’s requirements, the application will be launched.
Why is Apple doing this? To increase the Mac’s security by fighting malware at a developer level — rather than squashing every malicious app as they pop up individually — without depriving users of the control they have over the sources they can install software from. As Steven Frank wrote on the Panic blog, “trying to make applications free of vulnerabilities (while still an important goal) is to lose the overall cat-and-mouse race”. The Developer ID is, in fact, a remote killswitch that allows Apple to keep letting third-party developers do what they do while having an invisible security measure in place to prevent malware from spreading. If an application’s code gets tampered with, not only will Gatekeeper refuse to open new downloaded versions of it, Apple will also revoke that developer’s certificate, effectively killing every application signed with it.
In a post answering common questions about Gatekeeper, Rich Mogull wrote:
One of the most common ways to get malicious software onto someone’s Mac is to trick them into downloading and installing it. Criminals use sophisticated techniques that often fool knowledgeable users and even security pros, not just less-experienced users. By preventing downloaded software from launching unless it comes from the Mac App Store or a known developer, Gatekeeper closes the door to this approach to infection.
The concept of “first launch” is key here. Gatekeeper only checks for the information and settings it needs the first time you launch a new application; once launched, you’ll be able to keep opening an app regardless of your Gatekeeper settings or the state of a developer’s ID. Gatekeeper is aimed at keeping malware from spreading — it’s not an anti-malware solution that will scan your Mac for threats. All Gatekeeper does is check newly downloaded applications that haven’t yet been launched, and it does so through the industry-standard protocol called OCSP (Online Certificate Status Protocol), which talks to servers over the Internet to identify an app’s certificate. Furthermore, Gatekeeper won’t prevent apps you have already installed from launching: if an app has already been launched at least once, it will continue to work regardless of its digital signature. Software already installed, but never launched, will be subject to Gatekeeper; software copied from external disks, pen drives, or fetched via Terminal using curl or wget will not.
By default, Mountain Lion permits apps downloaded from the Mac App Store and from identified developers. But if you like, you can choose to allow apps only from the Store or, if you know what you’re doing, from any source, just as you do on a Mac today. Gatekeeper accepts any of these settings, but the message displayed will change accordingly.
If the developer isn’t identified, Gatekeeper will tell you it can’t open the app.
If you only allow apps from the Mac App Store, Gatekeeper will promptly notice that you downloaded the app from somewhere else.
When downloading an app from an identified developer, Gatekeeper will still ask you if you want to open it because it’s been downloaded from the Internet using a web browser. This is the default dialog displayed on Lion for software downloaded outside the Mac App Store.
You can also override Gatekeeper manually on a per-app basis. If you’re really sure an app is safe but Gatekeeper won’t let you open it, you can override Gatekeeper by right-clicking on the app and choosing “Open” from the contextual menu or from the Finder’s Action pop-up menu. This will tell Gatekeeper you’re making an exception for that app, but you’ll still be asked if you really want to launch it. In a smart touch Apple put the “Open” button on the left of this dialog, making it harder for users to click “Open” out of muscle memory (since it’s usually displayed on the right). Gatekeeper wants to make sure you know what you’re doing.
Apple thought of all the possible ways a developer might use to share code with others; scripts and Automator workflows can also be digitally signed using the same command line tool that signs “normal” apps. And there’s more: Apple even created a special Gatekeeper dialog for applescript:// URLs that you can find on websites like macosxautomation.com to easily create scripts using AppleScript Editor. Normally, clicking on these links in Safari would fire up AppleScript Editor directly with the code already filled in. With Gatekeeper, there is a new text window that asks if you want to create a script document. Obviously, you can’t run the AppleScript from this window.
Gatekeeper won’t protect a Mac user from every threat out there, nor is it going to make OS X immune to malware per sè. Instead, Gatekeeper is a security feature to prevent malware from spreading on new machines, thus stopping the infection at its roots: new users downloading malicious software. Beyond requiring them to sign their apps, Gatekeeper does not put any additional restrictions upon Mac developers. It doesn’t require sandboxing (though it is still highly recommended by Apple), nor does it prevent developers from using OS X functionalities and APIs.
Gatekeeper also introduces Mac users to the concept of “identified developer” by making the Mac App Store + Developer ID setting the default one. Average users rarely change the default settings, so it’s important that Apple is allowing this choice out of the box, as it confirms the company’s commitment to the third-party non-App Store developer ecosystem — at least for now. Today, it’s obviously impossible to predict if Apple will ever change the default settings for Gatekeeper, but it’s important to keep in mind that a simple radio button can make or break the fortune of third-party developers at this point. That said, it’s hard to believe that Apple will change its stance on Gatekeeper in the near future, given all the work they’ve put into making it so that developers can continue to distribute their apps outside the Mac App Store. If anything, I think it’d be great to see something similar come to iOS. Of course, the difference is the same as it’s always been: whereas the iPhone was born without apps and eventually got the App Store, Mac users don’t want OS X to turn into a locked down platform. Gatekeeper is a good compromise that improves security while keeping the nature of the Mac intact.
Announced at WWDC 2012, Power Nap is another system functionality aimed at making the Mac work more like iOS — in a way that makes sense for the desktop, of course.
To understand Power Nap, allow me to go back to October 2010, when Steve Jobs unveiled the new generation of MacBook Airs at Apple’s Back to the Mac event. He said:
“What would happen if a MacBook and an iPad hooked up?
Just as interesting as what it’s got, is what it doesn’t have. There is no optical drive and there is no hard drive. We have gone to flash storage: complete solid-state storage. Why do we do this? Because we know the benefits from the iPad. Instant on. It’s up to two times faster than hard drives. That’s a lot. It’s much more reliable, especially in a mobile environment. And it’s 90% smaller and lighter; again, very important to a mobile environment. It also gives you completely silent operation. Now, we know a lot about flash: we’ve designed it into our iPhones and we’ve designed it into our iPads. And as you may know, Apple is the largest user of flash memory in the world, so we know a lot about creating flash storage subsystems.”
Deemed Apple’s new “crown jewel” on multiple occasions in the past, the new MacBook Air (which has had two revisions since its 2010 debut) combines traditional Mac hardware and software with the advantages of an ultra-portable machine. It runs OS X, but it runs faster because of flash storage. It’s a Mac, but it’s lighter, cooler, and quieter. It is the result of years of expertise derived from designing mobile devices with high performance and portability brought back to a more traditional computing environment.
But there is a problem: as much as software or hardware engineers try to make iOS users feel more comfortable with a computer — either by tweaking the hardware or the software — it’s really the synergy of both that will drive the Mac’s growth as a modern platform going forward.
Power Nap takes what Jobs described as “Instant On” and turns it into “Always On”, at least in some areas of the OS.
One of the stark differences between an iPhone and a MacBook is that you can close the MacBook and go on with your day. The iPhone may be locked but it’s always close at hand, notifying us of new emails or an incoming @reply. The way Apple built iOS, iPhones and iPads are meant to be easy to unlock but also always available, all the time, thanks to wireless networking and push technology. Why shouldn’t a Mac be able to do that?
Until now, most laptops have been built to save power and be battery efficient when the lid is closed. After all, isn’t that what a laptop is all about — being able to close it and come back to it later? The problem is that our iOS devices, with their persistent connections and notifications, have made us come to expect a constant flow of up-to-date information. And yet a MacBook, just like any other laptop, has to wait a couple of seconds — if not minutes — to fetch the latest updates when it wakes up.
Power Nap doesn’t eliminate the concept of “sleeping” our Macs entirely. It’s more like it forces MacBooks running Mountain Lion to wake up more often so they’ll have the information you need already at hand. Power Nap puts your Mac to sleep and still lets applications like Mail, Notes, Messages, and Reminders stay up to date with the latest content. How is this possible?
One word: “flash”. Because Power Nap is also power efficient, Apple found a way to combine the silent operation provided by flash-storage solid-state drives with networking, so that your Mac will be able to refresh data with its lights and fans off and the lid closed regardless of whether it’s on battery power or plugged in.
Located in the Energy Saver preferences, Power Nap will check for “new email, calendar, and other iCloud updates” while it’s on battery power; while plugged in, it’ll also back up using Time Machine and download OS X system updates from the Mac App Store. In practice, this means you’ll find Mail ready with new messages (including attachments), new events in Calendar, new photos in your Photo Stream — all as soon as you wake up your Mac. In my testing I wasn’t able to try the software update feature, but my 2011 MacBook Air successfully fetched video attachments from Mail, updated Photo Stream, and received (some of my) messages, all while it was “sleeping”. While I didn’t notice a meaningful impact on battery life when I tested without the adapter, I highly recommend turning on the “while plugged in” options — both for the backup and software update additions.
Power Nap is another small feature of Mountain Lion, but a welcome, forward-thinking one. In this case, the entwinement of hardware and software is almost profound in its execution. With iCloud, Apple has built a system that continuously pushes updates down to all your devices, and with flash storage, wireless networking, and advanced battery technology, the hardware can better enable the software to work for us, not the other way around.
That said, for Power Nap to be a real game-changer I believe it will have to offer some sort of API to third parties. Imagine being able to have Dropbox keep itself up to date, or have Evernote automatically download new notes composed on our iPhones and iPads. I suspect Apple could easily create an additional control in System Preferences to let apps use Power Nap, perhaps restricting them to only work while plugged in. It makes sense that, for now, Apple is limiting Power Nap to iCloud, as it’s a technology they control on apps we use almost every day. But someday, I hope that Power Nap will also work with other apps — and when that happens, the line between “mobile” and “desktop” will be blurred even more.
In this section, I have collected minor changes, tweaks, or updates that couldn’t justify a standalone section in the review. For more, see Mountain Lion: Tips, Tricks & Hidden Features.
Not all Macs capable of running Lion will be able to update to Mountain Lion. Here’s a list of officially supported models:
- iMac (Mid 2007 or newer)
- MacBook (Late 2008 Aluminum, or Early 2009 or newer)
- MacBook Pro (Mid/Late 2007 or newer)
- MacBook Air (Late 2008 or newer)
- Mac mini (Early 2009 or newer)
- Mac Pro (Early 2008 or newer)
- Xserve (Early 2009)
General requirements include:
- OS X v10.6.8 or later
- 2GB of memory
- 8GB of available space
If you want to know why some older Macs can’t run Mountain Lion, Ars Technica did some digging to find out. More information is available from Apple here, and Egg Freckles has a list of unsupported Macs by model identifier.
People were surprised when Apple decided to keep Dashboard around in Lion. In Mountain Lion, it’s not only still around, it’s actually been improved too. The 10.8 Dashboard features a new Launchpad-like widget browser to manage, find, and install widgets. Searching for widgets will update results instantly as you type. If you like, you can even organize widgets in folders (just like Launchpad), and you can click and hold (or hold down Option) to enter “wiggle mode” to delete third-party widgets you don’t want anymore.
Surprisingly, the “More Widgets…” button still takes you to this page.
In Mountain Lion’s Launchpad, you can start typing to look for a specific app.
You can hit Enter (or click) to open the app, and navigate with the keyboard to choose from multiple results.
Mountain Lion can now mirror a supported Mac’s display to an Apple TV on the same local network, just like iOS. In the past year a number of hacks and unofficial third-party applications have surfaced with the intent of allowing OS X users to easily mirror the contents of their display to an Apple TV, but Apple’s official solution in Mountain Lion is elegant, integrated, and easy to use.
Inside the Displays preference pane there is a new checkbox to show mirroring options in the menu bar when available. When activated, whenever your Mac finds an Apple TV (2nd or 3rd gen) on your network an AirPlay icon will appear in the menu bar, enabling you to turn on mirroring for that Mac. When active, the AirPlay icon will turn blue and the menu will gain an option to match your desktop size to the Mac or the display connected to your Apple TV.
In my tests, the first time I activated AirPlay Mirroring my Air’s resolution was adjusted automatically to a 16:9 format to match the Apple TV’s resolution — in other words, letterboxed. However, a quick trip to the Display preferences revealed more options to adjust the resolution to the Apple TV, my Mac’s display, or to scale it to a specific value. No matter the setting you choose your entire display will be mirrored to the Apple TV, just like an iPhone 4S or iPad 2 or (3) with iOS 5.
On my local network, performance was good, but not great. On Wi-Fi, while the frame rate was generally smooth and the Apple TV managed to keep up with my Air’s animations and scrolling, I did notice some occasional stutters and drops (especially when mirroring video streaming through Plex). Mirroring graphic-intensive 3D games also caused my Air’s fans to spin faster than usual, and I noticed some sporadic slowdown on my Mac as well. According to Apple, AirPlay Mirroring supports up to 1080p encrypted streaming, and it optimizes your CPU cycles for video encoding.
Performance hiccups aside, I like the convenience of being able to mirror a display wirelessly with no need for a third-party plugin. AirPlay just works with no configuration, and Apple refined its implementation with some thoughtful touches, like turning off notifications when you are mirroring a presentation to the Apple TV so you won’t be disturbed by sounds and alerts. And of course the old iTunes AirPlay (now also part of AirPlay Mirroring) still works as well as ever, so you can also stream audio to the Apple TV using iTunes. Though I haven’t been able to test this, Apple says AirPlay Mirroring already supports audio receivers and stereo speakers.
For users who currently own an Apple TV and have been relying on cables and external projectors to mirror their Mac on the big screen, AirPlay Mirroring on Mountain Lion is definitely worth trying out — if only to know whether or not you have a powerful-enough connection to enjoy lag-free presentations, mirrored videos and photo slideshows, or just your desktop.
Straight from iOS (read: iPhone 4S and iPad 3) Dictation comes to Mountain Lion with an elegant, system-wide implementation.
Unlike iOS, the Mac has no customizable software keyboard, so Apple has decided to assign Dictation to a customizable shortcut mapped to physical keys. Available in the new Dictation & Speech preference pane, Dictation can be turned on or off at any time.
Apple explains why the feature, like on iOS, requires an Internet connection:
When you use the keyboard dictation feature on your computer, the things you dictate will be recorded and sent to Apple to convert what you say into text. Your computer will also send Apple other information, such as your first name and nickname; and the names, nicknames, and relationship with you (for example, “my dad”) of your address book contacts. All of this data is used to help the dictation feature understand you better and recognize what you say. Your User Data is not linked to other data that Apple may have from your use of other Apple services.
And here’s more about the data that gets sent to Apple every time you dictate something:
If you turn off Dictation, Apple will delete your User Data, as well as your recent voice input data. Older voice input data that has been disassociated from you may be retained for a period of time to generally improve Dictation and other Apple products and services. This voice input data may include audio files and transcripts of what you said and related diagnostic data, such as hardware and operating system specifications and performance statistics.
Dictation works anywhere you can type regardless of the app. Bring up the dictation pop-up, start dictating, and Apple’s servers will try their best to transcribe your words into text. As of now only English (United States, United Kingdom, Australia), French, German, and Japanese are supported. Keen-eyed users will notice a few similarities with Siri and iOS Dictation here: the supported languages, the purple-glowing microphone icon, the loading indicators and the sound effects are all identical to their mobile counterparts.
I haven’t been able to test Dictation in my native language (Italian), but I did run some tests in English and Dictation performed reliably, mimicking iOS in its (occasionally mistaken) results. In my experience, while Dictation sometimes skips a word or two, it generally does a good job at capitalizing words and inserting characters like “%” and “$”. I have found voice recognition to be pretty good on my MacBook and slightly more inaccurate on my iMac — though that is likely related to the distance between me and the computer (which is obviously shorter when using the Air). Below you can see a screenshot of what Dictation created once I let it run alongside one of Steve Jobs’ presentations (the MacBook Air section from the 2010 Back to the Mac event). As you can see, the results are more than decent, and the several skips that occurred only did so when I had to pause and bring up Dictation again (because it won’t stay on screen forever), not because of a software bug.
Full-Screen and Displays
In February 2012, Macworld’s Dan Moren wrote:
What’s so bad about Lion’s multiple monitor support? In some ways it’s no better or worse than previous incarnations of OS X. You have a choice to mirror the screen or extend the desktop, and the freedom to choose which monitor has the menu bar, and how the two monitors are arranged. Simple enough.
But there’s a real problem with Lion and multiple monitors, and its name is full-screen mode. Full-screen mode’s goal is to remove distractions, let you focus on a single app at a time. And, boy does it work—probably a bit too well, in some cases.
Unfortunately, Mountain Lion doesn’t improve much over Lion’s support for multiple displays and full-screen mode. Sure you can now take apps full-screen on any display, but when you do the other display becomes unusable. I have my 21.5-inch iMac connected to a vertical 24-inch Dell monitor, and I can’t use full-screen mode because Apple seems to think it makes sense to do this:
In case you’re wondering, that’s a composite screenshot showing my Dell monitor (on the right) switching from a full-screen app to the desktop. You see the other display on the left? That’s the iMac. The linen background you see when switching to the desktop is what you get when an app goes full-screen on any display: just the linen, with no way to remove it. You can’t, say, go full-screen on one display while enjoying a normal desktop on the other; you can’t even go full-screen with one app for each display. If you go full-screen with one app, the other display gets the linen background, period.
As Dan wrote, I’m sure Apple has thought about these issues and the tricky situation of treating full-screen apps as their own spaces. For instance, a solution would be to provide an option in the Displays preferences that allows external displays to switch spaces only when the cursor is inside the display, thus treating each display as its own unit for desktop management. Obviously this would create other issues for how spaces are visualized in Mission Control, but I think it’s something that Apple could fix with its usual clever and elegant design.
After all the criticism Lion received for its poor support for multi-display setups, I thought Apple would refine this functionality as they did with most everything else in Mountain Lion. Unfortunately, they haven’t, and I can only hope they’ll consider it for a future software update.
Mac App Store
The Mac App Store has received some interesting improvements in Mountain Lion. First, you can now activate Automatic Downloads in the Software Update pane. This feature, like for iOS apps, lets OS X download new apps purchased on any of your Macs automatically. For some reason Mountain Lion didn’t let me activate it on my iMac, but it worked fine on my MacBook Air. Once downloaded, new applications will appear in Launchpad and the /Applications folder.
Second, the Software Update tool is gone. Now all OS X updates go directly through the Mac App Store. Upon hitting Show Updates, System Preferences will open the Mac App Store in the Updates tab and check for any new software. If updates are found they’ll be displayed with inline information just like any other Mac app, only they’ll be at the top in a special system section. The Mac App Store also now notifies you of OS X and app updates in Notification Center, and downloads app updates automatically so they’re ready to be installed. Mac App Store notifications have been hit or miss during the period I tested Mountain Lion, but I expect them to improve and be pushed reliably once the OS goes public.
As mentioned above, the Mac App Store now supports multi-touch navigation to swipe between pages. Every app’s menu now comes with buttons to share on Twitter and Messages, and Facebook will be enabled as an option later this year. When sharing on Twitter, the OS X tweet sheet displays the application’s icon alongside an iTunes short URL.
And yes, Mountain Lion’s Mac App Store still lacks the ability to make wish lists.
Combining iChat and iMessage into a single application, Messages has dramatically enhanced my communication skills…when it works. Unfortunately, my experiences with using it on Mountain Lion’s developer previews have been mixed. While Messages theoretically allows me to quickly get in touch with a friend or colleague without grabbing my iPhone or iPad (thus increasing my typing speed thanks to the Mac’s keyboard), I have found the app to freeze often, forcing me to restart it to get iMessages that weren’t delivered.
To be fair, Messages has improved with each preview, but even on the golden master version of Mountain Lion I’ve been experiencing some annoying bugs. After logging back into my account, for example, Messages should be able to display the most recent items thanks to Power Nap — but it doesn’t always work. Sometimes, a message arrives on my iPhone but not on the Mac, and I have to force-quit the application to “unfreeze it” from its perennial state of old conversations. Other times, I’ve had to send a new message to force the app to retrieve the latest ones. And very often, Messages simply fails to connect, displaying a red exclamation point next to everything I say. For some reason, this happened a lot with group conversations and less with individual ones.
Fundamentally, I don’t think combining AIM and iMessage in a single window is a good idea; at least, not with the way Messages displays conversations from both of them in the same sidebar. From the screenshots below, how could you tell — profile picture aside — which conversation with my friend Don is iMessage, and which one is AIM?
Fortunately, Apple had the sense to visually differentiate AIM from iMessage in the compose panel — but there are still no visual clues in the sidebar, which is the main navigational element people will rely on to switch between conversations. Compare this to Mail, where each account’s name is rightfully shown in both the message list and the compose window.
Messages could use some better filtering options to organize accounts and improve navigation across conversations (again, just like Mail). I, for one, still believe this concept by Jan-Michael Cart (whom Apple took on as an intern last year) could make for a better iMessage desktop experience than Apple’s current app. The real problem is with multiple services, and Apple has shown no interest in fixing it thus far.
Messages has been a nice addition to my iMessage workflow (if not my AIM one), but it doesn’t yet work reliably 100% of the time. I suspect Apple will be improving its servers and Apple ID management in the future, so I’ll be keeping an eye on Messages to see if and how it evolves. Just keep in mind that, if you’re looking for 24/7 uptime, iMessage on OS X still isn’t there yet.
For a more complete overview of Messages, check out our initial impressions with the beta, and tips to get the most out of the app.
Mountain Lion and the Power User
It should be clear at this point that Apple wants OS X to offer better default apps and features to first-time Mac users coming from iOS, which is why they’ve doubled down on the “familiarity” aspect in Mountain Lion — using design patterns and interactions that iOS users will be sure to recognize. But how should longtime “Mac power users” — the ones who use their Macs extensively and automate them to their own tastes — feel about this update?
While Apple’s efforts to get rid of cruft, enhance security, and streamline design across platforms should be appreciated, there are some questions lingering over the future of the third-party Mac ecosystem that simply can’t be answered today.
Specifically, there is no guarantee that Gatekeeper will stay around for the next decade, and thus no guarantee that developers who won’t (or can’t) sell their apps through the Mac App Store will be able to keep selling them at all. Change is the only constant, and Apple isn’t afraid to roll with it if they think it ultimately provides a better experience in the long term. What if Gatekeeper is found to be an unreliable, untenable solution in the next three years? What if Apple concludes that, in the end, supporting software sold outside the Mac App Store just isn’t worth it anymore? Should we see Gatekeeper as a stopgap technology that Apple is implementing while they figure out where OS X is headed, or as a definite improvement in third-party app security that’s here to stay for good?
Personally, I believe Macs won’t turn into locked down App Store-only machines, but there are some issues worth considering to have a better understanding of what is, effectively, the dual nature of OS X software nowadays.
Thanks to the new sandboxing policies, some developers are being forced out of the Mac App Store because they can no longer provide new features in their apps without breaking them (at least, not with the current state of entitlements). A notable and recent example is TextExpander 4, which Smile Software had to release on their own website. Other developers are starting to come up with their own ways of migrating customers from the Mac App Store to “traditional” licenses, which gives them the freedom to offer critical bug fixes and updates without waiting for Apple’s approval, and the ability to keep their customer base if they decide they can’t keep doing business under Apple’s rules.
Thanks to the restrictions on what kind of apps can be sold, and the fact that some desirable features can only be implemented for apps that meet those restrictions (like iCloud support and push notifications in Notification Center), many fear the Mac App Store will foster a mindset among developers where “simple” apps go to the App Store, and any app even slightly more complex is only available outside it.
And I think that’s exactly the situation Apple wants to avoid.
In the past few years I have talked to several third-party Mac developers, and I hear their uncertainty and how much the lack of timely communications from Apple frustrates them. Ted Landau published a good piece on the first month of sandboxing, enumerating various instances of developers who struggled to meet Apple’s requirements. But I can’t help but be optimistic about the future of OS X going forward, as I believe Apple knows that the Mac’s great experience is made far greater thanks to the amazing third-party ecosystem that surrounds it.
Making OS X more familiar and consistent with iOS doesn’t mean it will become identical. Yes, some hardware features are now consistent across iPads, iPhones, and Macs; yes, many default applications now come pre-installed on both iOS and OS X; and yes, Macs and iOS devices are part of the same ecosystem based on iCloud’s increasingly solid foundation. But at the same time, each hardware-related feature, each app, and even iCloud have been implemented while taking into account the differences that make these devices stand out on their own. For instance, Power Nap doesn’t just bring “instant on” to OS X, it does so with a set of options to let users tweak their power settings. Dictation works just like it does on iOS, but users can specify a keyboard shortcut and an input source.
Like a couple moving in together, iOS and OS X now share the same values, the same taste in furnishings, and they make each other’s lives better — you can tell they are planting the roots for a family. This doesn’t mean they will lose their personalities and unique traits: if anything, those differences will be even more appreciated because they come together to create something stronger as a whole.
I think the Mac power user will be just fine using Mountain Lion. In practical terms, Mountain Lion’s new features and design choices haven’t hindered my ability to install the apps I want, run macros to automate tedious tasks, or fly through applications using keyboard shortcuts. I prefer Scrivener to Apple’s Notes app, I rely on Keyboard Maestro to be more efficient, and I keep my notes in Dropbox rather than iCloud. On the other hand, I can jot down a quick todo in Reminders knowing instantly that it will “just work”, and I can pick up any conversation I was having on my iPhone thanks to Messages on my Mac. Making the entire operating system more cohesive and refined hasn’t diminished the relevance and utility of third-party software on my Mac; if anything, it’s made the key apps and functionalities I rely on better.
It’s too early to tell how the issues mentioned above (sandboxing restrictions, Gatekeeper’s existence, Mac App Store vs. third-party sources) will play out in the long term. We shouldn’t ignore them either: some developers are currently struggling to keep their apps on the Mac App Store, and others are figuring out their own solutions to implement features that Apple demands remain exclusive to it. While the power user will always know how to work around Apple’s default settings, ignoring the complaints and doubts from the developer community would still be shortsighted. Instead, we should consider these issues, reflect on the questions developers pose, and hope that Apple is listening. It is, after all, the power users that often make the best contributions to the OS X ecosystem: either by demanding new features, or by developing rich and powerful solutions. We shouldn’t take this period of transition and change as the end of an era, but rather as the latest step in the evolution towards a better computing experience for everyone.
But let’s concede, for the sake of discussion, the argument that Apple may want to eventually turn Macs into iOS devices. I believe the question no one is asking is: why would they do it?
Let’s crunch some numbers. Assuming Apple sells Macs to, well, people interested in buying Macs, we should take into account the profits and margins Apple has on that segment to understand whether or not it’s a product category worthy of further investments in the future. In February 2012, Horace Dediu wrote:
Both iPhones and Macs are sold as hardware products and the entire econometric analysis of Apple depends on hardware cost structures. This is because hardware lends itself to easy measurement. However, a casual observer would be stumped by a comparison with competitors which cannot come near the profitability Apple enjoys. How can the same bundle of components (admittedly mostly off-the-shelf) be sold at triple the margins?
It comes down to software. Apple has a monopoly on iOS and OS X and charges for it through its hardware. That’s a very valuable monopoly. It’s worth at least $1 billion per quarter.
Put into financial context, Macs generate only a fraction of the revenue (and profits) that iPhones and iPads do, but they still represent a strong category in the company’s portfolio. GigaOM’s Rags Srinivasan wrote in June that, of a gross margin of $18.5 billion in Q2 2012, MacBooks accounted for $1.65 billion. The ASP (average selling price) of MacBooks dropped by $40 since Q2 2011, and that is related to consumers’ wide adoption of cheaper MacBooks like the Air. Srinivasan also noted that the 15” Retina MacBook Pro could be an interesting new source of profits for Apple.
So with potentially larger margins on Macs carrying more lucrative components like SSDs and Retina displays, just how much is Apple’s margin on their Mac segment? Horace Dediu believes around 28 percent.
As you can see, Apple’s gross margins on their Mac segment aren’t as high as the iPhone or iPad, and I believe that’s exactly the point of Mountain Lion. People buy Macs because they want the hardware and feature set of a Mac, yet more people are buying iPhones and iPads. We could argue that the numbers are simply smaller due to the Post-PC era we’re living in, but the fact remains: millions of customers choose a Mac every quarter. How can Apple sell more of them?
Apple has always made their money not from making better computers, but by making better experiences. This means tight integration of hardware, software, and services for an ecosystem people understand and trust with their money and digital information. For the hardware, Apple has amazing gross and operating margins on the iPhone because the device sells at a far bigger order of magnitude than tablets and computers, but they also have leverage with their suppliers that lets them get better components, at a lower price, before any other company. If Apple could sell more Macs, their margins would go up. It may be only a small increase, but at this scale, every percentage point counts.
To sell more Macs, Apple knows it has to focus on building a better experience because it’s not just about the hardware — if it were, people would be buying more specced-out Windows PCs or assembling their own Linux boxes. Hence, Mountain Lion, and its replication of much of the iOS experience. By making it easier to move between iOS devices and the Mac, Apple’s message is clear: different devices serve different purposes, but the core experience will be the same, and it will free you from worrying about data loss and dealing with unintuitive metaphors.
By design and by the numbers, OS X is changing, but it won’t prevent our Macs from letting us do the things we care about.
Mountain Lion isn’t “what Lion should have been”: it’s what Lion has become thanks to the maturation of Apple’s ecosystem and the increasing adoption of iCloud by customers. Apple couldn’t have shipped Lion with this iCloud-based experience last year, as it wouldn’t have made much sense without iCloud-powered iOS devices to go along with it. But now, it’s the right time to make OS X a more refined, solid, and connected product that can properly fit into a larger ecosystem.
When Steve Jobs introduced iCloud at the WWDC 2011 Keynote, he said:
We think our solution is the next big insight, which is we’re going to demote the PC and the Mac to just be a device. Just like an iPhone, an iPad, or an iPod touch. And we’re going to move the digital hub — the center of your digital life — into the cloud.
Apple is now the kind of company that can support the evolution of two operating systems simultaneously, and it shows with Mountain Lion. Some new features of the OS — such as Notes and iCloud Tabs — will only reveal their full potential with iOS 6, which is coming in a few months. But Mountain Lion also brings a better OS X to customers who own an iPhone and iPad today. With this upgrade, they will find a more integrated and cohesive experience that starts with the initial setup process and goes on to touch almost every area of the OS. In a way, iCloud is becoming the operating system — from the user’s perspective, if not from a technical standpoint.
The fact that Apple is aiming for iOS and OS X to be equally consistent and familiar shouldn’t trick us into thinking the Mac is becoming an iOS device with a keyboard. Features that originally appeared on iOS (Power Nap, AirPlay, Dictation, and Notification Center, just to name a few) have been ported to OS X with the unique nature of the Mac in mind. Whereas most companies would think that more marks on a checklist is all they need to make better products, Mountain Lion demonstrates that Apple knows it’s the interplay of hardware and software that yields more intuitive, tasteful, and ultimately, better experiences.
Mountain Lion still has some rough edges, but considerably fewer ones than in the first version of Lion. There are some aspects with file management and sharing in iCloud and the Finder that could still use improvement, but nothing that Apple can’t add in the future. By placing iCloud front and center, and by delivering a seamless experience of apps and features, Mountain Lion represents Apple — a company of hardware, software, and services — at its best.
The Mac may now be just a device. But it’s still different.
- For further reading, I suggest checking out Siracusa’s look at the Finder through the years, and Tognazzini’s Trends: The Evolution of the Interface. ↩︎
- The latter is a new “addition” to Mountain Lion, and can be invoked via the keyboard by pressing Command-Shift-Option-S. Curiously, Save As is not present in the File menu, as it’s keyboard-only. ↩︎
- One difference is that the iPad’s Notes app displays the “+” button for creating new notes in the upper toolbar, while Mountain Lion’s Notes places that button on the left sidebar. And of course you can always create a new note by hitting Command-N. ↩︎
- Fortunately, when working with multiple accounts you can pick a default one in the Notes > Default Account menu. ↩︎
- When dragging a single note the document icon becomes a single mini-note. Drag two notes and it becomes a stack of two; three, and it becomes a stack of three. For more than three notes, Apple displays an iOS-like badge with the total number of notes being dragged. ↩︎
- A new feature on Mountain Lion, you can now use a three-finger tap to preview any file in the Finder or NSTextView. In the Finder, this means you can select any file and tap it to have a floating preview; in apps like Notes, or even TextEdit, you’ll be able to preview attachments to have a better understanding of media embedded in your text. Mountain Lion is smart enough to tell within a fraction of a second whether the three-finger tap occurred on a word (in which case, the Dictionary pop-up will open) or a file. ↩︎
- With one notable exception: you can’t add new items via Siri on the Mac. At least, not yet. ↩︎
- Notification Center can be displayed while using a full-screen app, assigned a Hot Corner, or even a keyboard shortcut in System Preferences → Keyboard → Keyboard Shortcuts → Mission Control. ↩︎
- You can also share text views. For example, you can share an image from the Mail app to AirDrop or iMessage by choosing Share from the contextual menu — just make sure you select “view in place” first in Mail. ↩︎
- The idea of “may begin” comes from iOS, where gestures start in a state of “possible” when you touch a view. On the Mac you can’t touch a view directly, but multi-touch trackpads allow for similar states to be implemented. ↩︎
- According to Apple, this feature is not enabled on the Magic Mouse because most users already tend to rest their fingers on the mouse. ↩︎
- The Dictation pop-up doesn’t stay on screen forever (in my tests, it usually goes up to 30 seconds), so eventually your fans will start spinning again. On average, I noticed Dictation brought my fans’ RPM (revolutions per minute) down to 3000. ↩︎