Mac OS X 10.7 Lion: the Ars Technica review

Lion is no shrinking violet.

Window resizing

Resize widget

A lack of traditional scroll bars also means the elimination of the small patch of pixels in the lower-right corner of a window where the vertical and horizontal scroll bars meet. Since 1984, this area has been home to the one and only control used to resize a window. Setting the scroll bar appearance preference to "always visible" restores the clickable real estate, albeit sans the traditional "grip lines."

Despite the plain appearance, this resize control works as expected; what's unexpected is the cursor change that accompanies the action. The double-arrow cursor has been used in other operating systems for years, mostly to differentiate two-axis resizing (width and height) from single-axis resizing (height only or width only). When there's only one resize control per window, it's obvious that it can be used to change both the width and the height. Lion's new cursor can mean only one thing…

Window resizing from all edges (composite image)

That's right, long-suffering switchers, Lion finally allows windows to be resized from any edge and from all four corners, with a special cursor for each of the eight starting points. (When a window is at its size limit, the cursors show an arrow pointing in a single direction—a nice touch.)

As you can see from the image above, what Apple hasn't done is add borders to the windows. So where, exactly, do we "grab" when resizing from a borderless window edge? There's no way around it: some pixels must be sacrificed to the gods of Fitts's law.

A few pixels within the outer edge of the content area of the window (two to three, depending on where you count from) are commandeered for window resizing purposes. You can still click on these areas, and the click event will correctly propagate to the application that owns the window, but you'll be clicking with a resize cursor instead of a normal arrow cursor.

Two to three pixels doesn't make for a very wide target, however, which is why Apple has chosen to appropriate pixels from both sides of the window border. Four to five pixels outside the content area of the window are also clickable for window resizing purposes. Clicks in these areas don't get sent to the window (they're out of the window's bounds) and they don't get sent to whatever happens to be behind the active window—you know, the thing that you ostensibly just clicked on. Effectively, Lion windows have thin, invisible borders around them used only for resizing. (Unlike Mac OS 8 and 9 windows, which had real, visible borders, Lion windows can't be dragged by their borders.)

When overlay scroll bars are in use, the full 16x16 pixel home of the traditional resize widget in the lower-right corner is clickable, making this still the easiest target for window resizing, whether it's visible or not.

Unzoom widget

Zoom widget

Lion has a few more surprises on window edges, one of which is window size-related. Windows belonging to applications that support Lion's new full-screen mode may show an embossed double arrow icon on the far-right side of their title bars. Clicking it will cause the window to fill the entire screen. Other windows, the Dock, and even the menu bar are hidden in this mode. The window's title bar also disappears, making it unclear how to exit this mode. But just stab the cursor at the top of the screen and the menu bar slides back down into view, containing all the expected menus plus a reversed version of the double arrow symbol. Click the inward-facing arrows to take the current window out of full-screen mode.

Animation

Mac OS X has always used animation in its user interface, starting with the genie effect over a decade ago, and really ramping up with the introduction of the Core Animation framework three years ago. Lion continues this trend. In nearly all new or changed applications in Lion, if something conceivable can be animated, it is. The Finder is a good example. Even features whose functionality hasn't actually changed in Lion, such as dragging multiple items from one window to another, are given a fresh coating of animation and fades.

At its best, animation explicitly communicates information that was either absent or only implied before. For example, the genie animation tells the user where a window goes when it's minimized. In other cases, such as the water ripple effect in Dashboard, animation can add a bit of fun to an interface.

But danger lurks. A newly discovered animation might delight the user the first time it's shown, but the 350th time might not seem quite so magical. This is especially true if the animation adds a delay to the task, and if that task is done frequently as part of a time-sensitive overall task. The Dashboard water ripple is acceptable because adding a new widget to the screen is an infrequent task. But if the screen rippled every single time a new window appeared anywhere in the OS, users would revolt.

Well, guess what happens every time a new window appears on the screen in Lion? No, it's nothing as garish as a water ripple, but there is an animation. Each window starts as a tiny dot centered on the window's eventual position on the screen, then quickly animates to its full size.

This animation conveys no new information. It does not tell the user where a window came from, since the animation starts at the final position of the window. Whether or not the animation actually delays the opening of the window, it certainly feels like it does, which is even more important. This type of animation can make Lion feel slower than Snow Leopard. And when an animation like this stutters or skips a few frames due to heavy disk i/o or CPU usage, it makes your whole Mac feel slower, like you're playing a 3D game with an inadequate video card. And for what? For what someone at Apple hopes will be a lasting feeling of delight?

Perhaps it could be argued that the animation catches the eye more than a window that appears instantly (though that probably depends on the size of the window and what's behind it on the screen). For "unexpected" windows like error dialog boxes, that could be a benefit. But for "expected" windows (i.e., those that appear in response to deliberate user input), the powerful, primordial pull of these moving images is an unwelcome distraction, not a benefit.

It's conceivable that this animation could delight some users, but I have a hard time believing that the enjoyment will last much past the first week. (Interestingly, this animation does not play in reverse when a window is closed. This, perversely, makes window closing feel faster than window opening in Lion.)

Unlike the scrolling behaviors discussed earlier, there are no user-visible preferences for these new animations, which makes it all the more important for Apple to strike a good balance. In my estimation, Lion crosses the line in a few places; the new window animation is the most egregious example. I look forward to discovering a way to disable it. [Update: here it is: defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool NO]

John Siracusa / John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer.