We Recommend

My Discussions

Mac OS X 10.1

User interface

Much of the quality of Mac OS X's user interface is tied to overall system performance, which we've already covered. This section will therefore concentrate on the handful of other areas that play the biggest role in the OS X user interface: System Preferences, the Dock, and the Finder.

Performance is billed as one of the biggest changes in 10.1, in part because the user interface has not really changed that much. There are very few substantial new features, especially in the "big two" applications: the Dock and the Finder. Given that, much of the criticism leveled at the Mac OS X user interface in earlier articles still applies to 10.1. (And I'm sure some of that criticism will be reiterated here.) Once more into the breach, dear friends...

System Preferences

By "System Preferences", I mean more than just the application of the same name, which was covered earlier. I'm talking about any new features or settings that affect the system-wide user interface. The most important are listed below.

System Menus

One of the most welcome additions to 10.1 is the new "system menu" or "menu extra" (to use Apple's terminology) feature (also mentioned earlier). Although the simple menu extras provided with the OS may not seem that exciting (e.g. an audio volume slider or a battery monitor), it is the framework for system-wide menu bar modification that stands to have a tremendous impact on the future of the Mac OS X user interface. First, a little background.

In 10.0.x, there was no officially sanctioned method for global menu bar modification. With the OS X Apple menu off limits to user and developer modification (a designation that remains in 10.1), the entire 10.0.x menu bar was effectively fixed (with the exception of Apple's tacit inclusion of an optional menu bar clock). This was an especially disappointing, given the removal of Mac OS 9's application switcher menu from the far-right side of the menu bar, leaving that end entirely barren (again, save for the clock) in 10.0.x.

Apple's rationale for this decision has been described to me as being motivated by the proliferation of menu bar clutter in classic Mac OS. Many classic Mac OS applications wanted to include their own system-wide menus, some of which had limited value to the user. Of course, these menus were almost universally optional (although often enabled by default), and I never considered this a big problem in classic Mac OS.

Apparently, neither did other Mac users and developers, because many system-wide "menus" for Mac OS X 10.0.x quickly appeared. I put "menus" in quotes because many of these were not menus at all, but rather applications with borderless windows that drew themselves directly over the existing menu bar. This was an even bigger affront to UI "cleanliness" than the supposed proliferation of (proper) system-wide menus in classic Mac OS—and a further lesson that, if users want something, they'll get it.

Mac OS X 10.1 seems to acknowledge this by providing a proper framework/API for system menus. The user experience it provides is quite nice. System menus may be activated through preference panes, or may be explicitly dragged to the menu bar by the user. Once there, they may be rearranged by holding down the command key and dragging the menu icons (or titles) around, causing a "shuffling" animation similar to the Dock. Dragging a system menu off the menu bar causes it to disappear in a Dock-like puff of smoke.

All of the system menus described earlier are implemented using this interface, including the menu bar clock. You can almost hear the proliferation of new system menus, and the conversion of existing "hacked" menus to the new API. Apple itself has joined in with a new, and very useful system menu for running scripts: AppleScripts, Perl scripts, or shell scripts. Script Menu is a free download at Apple's web site.

Unfortunately, third parties will have to continue to stumble in the dark as they try to leverage the new system menu framework (and rest assured, they will try), because the system menu API is not public. Instead, Apple wants third party developers to add such functionality through what Apple calls "dock menus", meaning menus spawned from docked application icons (e.g. the new playback commands in the iTunes pop-up menu).

Many of you have been asking for a mechanism to provide global access to certain features provided by your application. Dock menus are the way to do this. Please note that the menu extras area of the main menu bar is not being made available to 3rd party developers at this time and is reserved by Apple for hardware and networking related items. The Dock is intended to be the point of entry for 3rd party developers providing this type of global access functionality.

Furthermore, the 10.1 installer removes all of the old Apple-supplied "docklings" introduced in 10.0.x. John Geleynse again:

Dock Extras, aka Docklings, are no longer being developed by Apple
and the private APIs providing this capability are not guaranteed to
continue working after 10.1.

Existing third party docklings continue to work in 10.1, but produce a warning dialog.

Despite Apple's attempt to maintain an iron grip on the new global menu bar modification API, industrious third party developers will find (and, in fact, already have found) a way to use it. Like I said earlier, it is simply impossible to stop the development of applications that users want—and Mac users apparently want global menu bar modifications.

Apple is foolish to try to stop this phenomenon. Dock menus, while useful, do not fulfill the same need. They are lost in the over-burdened Dock's sea of functionality. While I fully expect new OS X applications to take advantage of the new Dock menus, the wave of global menu bar modification utilities will also continue, whether Apple likes it or not. This includes the current crop of "hacked" Apple menu replacements that draw directly over the existing Apple menu (which will have to continue on in their current form since the new API only appears to affect the right side of the menu bar).

Apple is hurting itself and its users by withholding the documentation for such highly requested APIs. The proliferation of "blind" attempts by third parties to leverage these (possibly changing) APIs without any public documentation will adversely affect the user experience. A user won't know that "it's not Apple's policy to allow third party global menu bar modification." They'll only know that their application switcher menu replacement has suddenly started crashing in Mac OS 10.1.3.

Bad show, Apple. Give the people what they want. Make the global menu bar modification APIs public.

Fonts

As shown earlier, there is a new system-wide preference for font smoothing. Unfortunately, not all applications honor the setting. Worse, some applications that choose to present "un-smoothed" text at certain sizes produce less than ideal results. Compare the following text, both in the same size and font, in 10.1's Mail application and in SimpleText in the classic environment:

9pt Geneva in Mail (OS X)

9pt Geneva in SimpleText (OS 9)

Notice how the OS X text appears slightly compressed? It looks like the character spacing needs to be adjusted, or perhaps a bitmapped version should be used at smaller sizes. Whatever the problem, my preferred email message list font (9pt Geneva) is much less readable in OS X's Mail application than in Entourage in OS 9. I can only hope that the coming version of Entourage for OS X handles this situation better.

Other than the partially functional option to turn off font smoothing below a certain size, there are no other significant font choices in 10.1. You cannot adjust the font used in menus, dialogs, the Dock, toolbars, open/save dialog boxes, or the Finder. The default fonts are generally nice to look at, but many of them are much larger than I would like. The large fonts used in open/save dialogs and in the Finder are particularly bothersome because they reduce the amount of information that can be conveyed in a given width. Mac OS X desperately needs more font size adjustability in the interface, and 10.1 does not deliver it.

Keyboard Access

Full keyboard access was cover earlier, but it bears mentioning again. If not for the buggy implementation, this feature would be a home run for 10.1. I hope the bugs will be worked out in future 10.1.x releases.

Other forms of keyboard access continue to languish. Some open/save dialog boxes now respond to keyboard input in a sane manner, allowing navigation of the miniature column view with the arrow keys: up and down to move through a list, and right or left to descend or ascend the hierarchy. Typing the first few letters of a file or folder name also scrolls the selected list to the proper location. Unfortunately, the return key does not open the selected item or folder, making a trip to the arrow keys an essential, and annoying, part of any keyboard navigation experience in an open/save dialog.

I said that "some" open/save dialogs now respond to keyboard input in a sane manner because some continue to just plain go nuts. The movie below shows the open dialog box from the Acrobat Reader application bundled with 10.1. From the starting position shown in the movie, I simply typed the letters "a-r-s" in an attempt to select the "Ars Technica" folder from the list. Watch what happens.

As you can see, I'm booted all the way back to the root of the file system, and one of the "arrows" from the file list has drawn itself on top of the left border of the dialog (easier to see in the the larger version). This bug has existed since 10.0, and it's a shame to see it still around in 10.1.

Also note that the file list allows partially obscured items in the list (look at the "Sites" folder in the right pane at the start of the movie) rather than forcing itself into a size equal to an integer number of items—another annoying bug.

Window Management

There is still no method for in-place window minimization in 10.1. The sole window minimization function, displaced minimization to the Dock, continues to be less than ideal for many purposes (e.g. "peeking" behind a window, or minimizing and restoring several windows quickly without trips to and from the edge-mounted Dock). It also forces anyone who wants to minimize a window to use the Dock for this purpose, regardless of whether or not they want the additional clutter, or whether they want to use the Dock at all. At work, I'm forced to keep the Dock visible at all times because I don't like the delay and uncertain targeting that a hidden Dock provides, but I do need to minimize windows.

A high quality in-place minimization hack would surely find many users (and possibly customers) in the Mac community. I hope someone out there is working on one right now, because Apple (in now-typical fashion) appears to have washed its hands of this feature entirely, despite strong demand from the user community.

The Dock

The small number of functional changes to the Dock in 10.1 were covered earlier. The ability to reposition the Dock has the most significant effect on the user experience—for users that want the Dock someplace other than the bottom, that is. But the essential nature of the Dock remains unchanged. While its intended purpose as a interface simplification device remains admirable, it is still over-burdened with functionality that would better serve users in separate, more specialized interface widgets.

There are many third party applications that extend the OS X user interface, but none of them can completely replace the Dock because none of them can control window minimization the way the Dock does. And applications that implement portions of the Dock's functionality in a more specialized manner (say, a dedicated application switcher palette) do not remove those functions from the Dock. The resulting interface is even more confusing (e.g. there are now two lists of running application on the screen all the times).

At the same time that more applications are taking better advantage of the Dock's functionality (e.g. iTunes with its new pop-up functions and the Print Center application with its improved status display), the intractability of the monolithic, do-everything Dock continues to keep the Mac OS X user environment from suiting the needs of many users. A more customizable Dock, or possibly even an arbitrary number of more specialized Docks, would go long way towards making the OS X user interface more flexible and powerful.

One final complaint: Dock icons are still reduced to undecipherable vaseline-smeared blobs when the Dock is made very small—despite the possible existence of pre-drawn icon resources at or near that size (e.g. 16x16 "icns" icon resources). This makes the Dock both less attractive and less useful at small sizes:

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.