Infinite Loop

Reconsidering fundamentals

The user-visible changes in Lion are legion. You'll be hard-pressed to find any part of the user interface that remains completely unchanged from Snow Leopard, from the look and feel all the way down to basic behaviors like application and document management. In Lion, Apple has taken a hard look at the assumptions underlying the last ten years of Mac OS X's development—and has decided that a lot of them need to change. Get ready.

Lion's new look

Let's ease into things with a tour of Lion's revised user interface graphics. Though Apple still uses the name "Aqua" to refer to Lion's interface, the look is a far cry from the lickable, candy-coated appearance that launched the brand. If you can imagine three dials labeled "color," "contrast," and "contour," Apple has been turning them down slowly for years. Lion accelerates that process.

The shapes have started to change, too. The traditional capsule shape of the standard button has given way to a squared-off, Chiclets-style appearance. The tubular shape of the progress bars, a fixture since even before the dawn of Mac OS X, has been replaced with a vaguely puffy stripe of material. Radio buttons, checkboxes, slider thumbs, segmented controls, "tab" controls—nearly everything that used to protrude from the screen now looks as if it was pounded down with a rubber hammer.

Even the elements that look identical, like the plain gray window title bars, are slightly different from their Snow Leopard counterparts. The new look is not a radical departure—everything hasn't gone jet black and grown fur, for example—but this is the first time that nearly every element of the standard GUI has been changed in a way that's identifiable without a color meter or a magnifying glass.

For the most part, the new look speaks in a softer voice than its predecessor. The total removal of blue highlights from several controls (e.g., pop-up menus, combo boxes, slider thumbs, and tab controls) makes most interfaces appear slightly less garish. On the other hand, the additional green in the blue highlights that still do exist makes those controls appear more saccharine.

Apple says that its goal with the Lion user interface was to highlight content by de-emphasizing the surrounding user interface elements. You can see this most clearly in sidebar and toolbar icons, which are now monochromatic in most of the important bundled applications. But this has the unfortunate side effect of making interface elements less distinguishable from each other, especially at the small sizes typical in sidebars. I'm not sure the "increased emphasis on content" is enough to balance out the loss, especially in applications like the Finder.

Appearance changes can have effects beyond emphasis, fashion, and mood. Take the "traffic light" red, yellow, and green window widgets, for example. As you can see in the images on the right, they've gotten smaller in Lion. Or rather, the colored portion has gotten smaller; the actual clickable area has lost only one pixel in height and five pixels in total width across all three widgets.

But the psychological effect of the shrunken appearance is something else entirely. Despite the tiny difference in the functional size, I find myself being ever-so-slightly more careful when targeting these widgets in Lion. It's a little annoying, especially since it's not clear to me how the new, smaller size fits into Lion's new look. Does such a small reduction in size really serve to better emphasize window content? After all, none of the other controls have gotten any smaller.

Other aspects of the new look have clearer intentions. The flatter, more matte look of most controls, and especially the squared-off shape of the standard button, all bring to mind the look of Apple's other operating system, iOS. One control in particular takes the iOS connection even further.

Finally, there's Apple's budding love affair with a particular linen texture. It made its first appearance on the backside of some Dashboard widgets. More recently, it was used as the background pattern for the notifications sheet in iOS 5. In Lion, it's featured even more prominently as the background for the newly restyled login screen, now featuring circular frames for user icons. (Also note the subset of menu bar status icons still visible in the top-right corner of the screen.)

Scroll bars

Scroll bars, which Apple likes to call "scrollers" these days, are among the least-changed interface elements in Mac OS X. While the rest of the Aqua interface was refined—edges sharpened, pinstripes removed, shines flattened—scrollbars stubbornly retained their original Aqua look for over a decade.

Scroll bars haven't been entirely static in Mac OS X, however. For many years, iTunes has had its own custom scroll bar look.

When these new scroll bars were first introduced in iTunes 7 in 2006, there was some speculation that this was a trial run for a new look that would soon spread throughout the OS. That didn't happen. But now, five years later, scroll bars are finally changing system-wide in Mac OS X. Here's a scroll bar from Lion:

The smeared gradient and fuzzy edges of the iTunes scroll thumb are nowhere to be seen. Instead, we have a narrow, monochrome, sharp-edged lozenge. Just like the window widgets, the scroll thumb appears slightly smaller than its Snow Leopard counterpart. (In this case, total scroll bar width and the clickable area are actually the same as in Snow Leopard.)

The change in appearance might distract you from what's really different: where are the scroll arrows? You know, the little buttons on either end of the scroll bar (or grouped together on one end) that you click to move the scroll thumb a bit at a time? Well, they're gone.

But wait, there's more. Here's a Finder window.

Though I can assure you that Lion comes with more than eight applications, you wouldn't know it from looking at this screenshot. Forget about the arrows, where are the scroll bars?

Placing the cursor into the window and using the scroll wheel on the mouse or two-finger scrolling on a trackpad reveals what you might have already guessed based on the shape and appearance of the new scroll thumbs. Extremely thin, monochrome scroll thumbs fade in as the scrolling begins, and disappear shortly after it ends. These transient scroll thumbs appear on top of the window's content, not in alleys reserved for them on the edges of the window.

These ghostly overlay scroll bars are straight out of iOS. When they were introduced in 2007 on the iPhone's 3.5-inch screen, they made perfect sense. Dedicating one or more finger-width strips of the screen for always-visible, touch-draggable scroll bars would have been a colossal waste of pixels (and anything less than a finger's width of pixels would have been too narrow to comfortably use). Overlay scroll bars were essential in iOS, and completely in keeping with its direct manipulation theme. In iOS, you don't manipulate an on-screen control to scroll, you simply grab the whole screen with your finger and move it.

Apple isn't (yet) asking us to start poking our fingers at our Mac's screen, but it does now ship every Mac with some kind of touch-based input device: internal trackpads on laptops, and external trackpads or touch-sensitive mice on desktops. Lion further cements the dominance of touch by making all touch-based scrolling work like it does on a touchscreen. Touching your finger to a control surface and moving it downwards will move the document downwards, revealing more content at top and hiding some of the content that was previously visible on the bottom. This sounds perfectly logical, but it also happens to be exactly the opposite how scrolling has traditionally worked with mouse scroll wheels. The effect is extremely disconcerting, as our fingers unconsciously flick at the scroll-wheel while our eyes see the document moving the "wrong" way.

Thankfully, there is a preference to restore the old mapping of finger movement to scroll direction. There's a second setting in the Trackpad preference pane, phrased in the opposite way. Unfortunately, the settings are linked; you can't have different values for each kind of input device.

Though the unification of scrolling gestures is logical, it's difficult to get used to after so many years of doing things the other way. The most common scrolling direction is downwards, and the most natural finger movement is curling inwards. These two things align when using a mouse wheel with the "old" scrolling direction setting. Old habits aside, it may be that the difference between touching a screen directly and touching a separate device on a horizontal surface in front of the screen is just too great to justify a single input vocabulary.

Either way, there's sure to be an uncomfortable transition period for everyone. For example, the two-finger swipe to the left or right used to switch between screens in Launchpad (described later) feels "backwards" when the scroll direction preference is set to the traditional, pre-Lion behavior. Perhaps just seeing a screen covered with a grid of icons unconsciously triggers the "iOS expectations" region of our brains. (And if you set the scroll direction to "feel right" for two-finger swiping in Launchpad, then the four-finger swipe between Spaces feels backwards! Sigh.)

Scroll bars do more than just let us scroll. First, their state tells us whether there's anything more to see. A window with "inactive" (usually shown as dimmed) scroll bars indicates that there is no content beyond what is currently visible in the window. Second, when a document has more content than can fit in a window, the scroll bars tell us our current position within that document. Finally, the size of the scroll thumb itself—or the amount of room the scroll thumb has to move within the scroll bar, if you want to look at it that way—gives some hint about the total size of the content.

Most computer users aren't conscious of such subtleties, but their combined effects are profound. Long-time Mac users might remember a time when scroll thumbs were perfectly square regardless of the total size of a window's content. When I think back to my time using those scroll bars, I don't recall any problems. But just try using these so-called "non-proportional" scroll bars today. The modern computer user's mind revolts at the lack of information, usually treating it instead as misleading information about the total size of a window's content. ("This window looked like it had pages and pages of content, but when I dragged the tiny square scroll thumb all the way from the top to the bottom, it only revealed two new lines of text!") Only when this cue is gone do you realize how much you've been relying on it.

And keep in mind that proportional scroll thumbs are the most subtle of the cues that scroll bars provide. The others are even more widely relied upon. The complete lack of visible scroll bars leaves a huge information void.

Let's put aside the familiar for a moment. In the absence of scroll bars, are there other visual cues that could provide the same information? Well, if truncated content appears at the edge of a window, it's usually a safe bet that there's more content in that direction. The prevalence of whitespace (between icons in the Finder, between lines of text, etc.) can make such truncation less obvious or even undetectable, but at least it's something. For total content size and position within the document, there's no alternative even that good.

But fear not, gentle scroller. Like the scroll direction, scroll bar visibility has a dedicated preference (in the General preference pane):

The default setting, "Automatically based on input type," will use overlay scroll bars as long as there's at least one touch-capable input device attached (though the trackpad on laptops doesn't count if any other external pointing devices are connected). If you don't like this kind of second-guessing, just choose one of the other options. The "When scrolling" option means always use overlay scroll bars, and the "Always" option means always show scroll bars, using the appearance shown earlier.

Lion includes new APIs for briefly "flashing" the overlay scroll bars (i.e., showing them, then fading them out). Most applications included with Lion briefly show the scroll bars for windows that have just appeared on the screen, have just been resized, or have just scrolled to a new position (e.g., when showing the next match while searching within a document). This helps soften the blow of the missing information previously provided by always-visible scroll bars, but only a little.

Applications with other UI elements whose correct placement relies on the existence of a reserved 16-pixel stripe for the scroll bar outside the content area of the window may be forced to display what Apple calls "legacy" scroll bars. (Apple's term for non-overlay scroll bars tells you all you need to know about which way the wind is blowing on this issue.) You can see an example of one such UI element in the image on the right. The document scale pop-up menu (currently showing "100%") pushes the horizontal scroll bar to the left to make room for itself. Clearly, this will not work if the scroll bar overlays the content area and is hidden most of the time. Apple suggests that such applications find new homes for these interface elements, at which point the AppKit framework in Lion will allow them to display overlay scroll bars.

Lion's scroll bars are a microcosm of Apple's new philosophy for Mac OS X. This is definitely a case of reconsidering a fundamental part of the operating system—one that hasn't changed this radically in decades, if ever. It's also nearly a straight port from iOS, which is in keeping with Apple's professed "back to the Mac" mission. But most importantly, it's a concrete example of Apple's newfound dedication to simplicity.

In particular, this change reveals the tremendous weight that Apple gives to visual simplicity. A complete lack of visible scroll bars certainly does make the average Mac OS X screen look a lot less busy. A lack of visual clutter has been a hallmark of Apple's hardware and software design for years, and iOS has only accelerated this theme. Also, practically speaking, the sum of all those 16-pixel-wide stripes reserved for scroll bars on window edges may add up to a nontrivial increase in the number of pixels available for displaying content on a Mac's screen.

But there is a price to be paid for this simplicity; one person's noise is another person's essential source of information. Visual information, like the size and position of a scroll thumb, is one of the most efficient ways to communicate with humans. (Compare with, say, numeric readouts showing document dimensions and the current position as a percentage.)

These sacrifices were an essential part of the iPhone's success. The iPad, though larger, is clearly part of the same touch-based family of products, and is wisely built on the same foundation. But the Mac is a different kettle of fish—and not just because the screen sizes involved may be vastly larger, making the space savings of hidden scroll bars much less important.

The Mac user interface, with its menus, radio buttons, checkboxes, windows, title bars, and yes, scroll bars, is built on an entirely different interactivity model than iOS. The Mac UI was built for a pixel-accurate indirect pointing device; iOS was built for direct manipulation with one or more fingers. The visual similarity of on-screen elements and the technical feasibility of porting them from one OS to the other should not blind us to these essential differences.

It's interesting that all of the scrolling changes in Lion have preferences that allow them to be reverted to their pre-Lion behaviors. The defaults clearly indicate the direction that Apple wants to go, but the settings to reverse them—public, with real GUIs, rather than undocumented plist hacks—suggest caution, or perhaps even some internal strife surrounding these features.

Such caution is well-founded. Hidden scroll bars in particular have trade-offs that change dramatically based on the size of the screen and the input device being used. Like many features in Lion, the scrolling changes are most useful and appropriate on the Macs that are closest to iOS devices in terms of size and input method (the 11-inch MacBook Air being the best example). But on a Mac Pro with dual 27" 2560x1440-pixel displays attached, Lion's scrolling defaults make far less sense.