Introduction

It's that time of year again. For three consecutive years, Apple has released major updates to what is now definitively The One True Apple Operating System: Mac OS X. The 10.1 release was a compiled-binary apology for 10.0, distributed for free to the brave Mac OS X pioneers. Version 10.2 came dressed for success, wearing its code-name on its sleeve in a fur-themed box. Sporting significant architectural improvements such as rendezvous and Quartz Extreme, pride was a big part of Jaguar's message.

Mac OS X 10.3 Panther, released on October 23, 2003, solidifies Apple's yearly operating system update strategy: another year, another +0.1, another US$129. As with 10.2, qualifying customers who have purchased new Mac hardware recently can upgrade to 10.3 for "free" (which means "US$19.95 for shipping and handling" in Apple's world.)

It's strange to have gone from years of uncertainty and vaporware to a steady annual supply of major new operating system releases from Apple. But some important questions quickly follow. Do I really want to pay US$129 every year for the next version of Mac OS X? Worse, do I really want to deal with the inevitable upgrade hassles and 10.x.0 release bugs every single year? Just as the 10.2.x code base was finally settling down (the botched 10.2.8 release notwithstanding), the Mac community is asked to start all over again with 10.3.0.

Is it worth it, or is a major OS upgrade every year simply too much, too often? Would things be different without the $129 price tag? Or is Panther well worth its price tag and potential time investment? Well, it is 0.1 more, isn't it?

Background

Ars Technica has been following Mac OS X since the second developer release in 1999. Earlier articles are listed below in reverse-chronological order, with the major public releases in bold.

• Mac OS X 10.2 Jaguar 09/05/2002
• Mac OS X 10.1 10/15/2001
• Metadata, The Mac, and You 8/20/2001
• Mac OS X 10.0 4/02/2001
• MWSF: Mac OS X Post-Beta 1/17/2001
• Mac OS X Public Beta 10/03/2000
• Mac OS X Q & A 6/20/2000
• Mac OS X DP4 5/24/2000
• Mac OS X DP3: Trial by Water 2/28/2000
• Mac OS X Update: Quartz & Aqua 1/17/2000
• Mac OS X DP2: A Preview 12/14/1999

The earlier articles contain information that will not be repeated here, as well as concepts that will be referenced but not reexplained. In general, it is safe to assume that any praise or criticism found in the 10.2 article that is not either reinforced or contradicted in this article continues to be true of 10.3.

The test systems used for this review are shown below:

• Stock Dual G5 2GHz: A dual 2GHz Power Mac G5 with 1.5GB RAM, an ATI Radeon 9600 Pro video card with 64MB of VRAM in an 8x AGP slot, a 160GB 7,200 RPM Serial ATA hard drive, a DVD-R/CD-RW drive, and a Sony E540 21-inch flat screen CRT.
• BTO Dual G5 2GHz: A dual 2GHz Power Mac G5 with 1.5GB RAM, an ATI Radeon 9800 Pro video card with 128MB of VRAM in an 8x AGP slot, a 160GB 7,200 RPM Serial ATA hard drive, a DVD-R/CD-RW drive, and a Apple Cinema HD Display 23-inch LCD.
• 15" AlBook: The 1GHz 15-inch Aluminum PowerBook G4 which was reviewed earlier here at Ars Technica.
• G3/400: A revision 1 blue and white Power Mac G3 400MHz with 384MB RAM; an ATI Rage 128 video card with 16MB of VRAM; an ATA/66 PCI card with a Western Digital 60GB 7,200 RPM HD attached; and a 17-inch Apple Studio Display CRT.

As faithful readers will notice, most of these systems are a significant step up from the dual G4/450 and G4/800 that have served as the "high-end" systems in earlier Mac OS X reviews. The venerable G3/400 hangs on for one last appearance, having served as a test system in every one of my past OS X reviews.

What's (not) in a name?

As with Jaguar, Mac OS X 10.3's code name is also a prominent part of its product name. (At this point, can "Panther" even be considered a code name?) See my previous discussion for more on Apple's historical use of code names in actual product releases. The story with Panther is slightly different, however.

Given the branding of Jaguar, many Apple watchers expected Panther to follow suit, with a black panther-fur-covered "X" logo and packaging design (humorous alternatives aside). Instead, Apple went with a brushed metal "X" on a black background.

I mention this for a few reasons. First, just as Jaguar's flashy, speckled orange fur signaled the ascendancy of Mac OS X after the tough road of 10.0 and 10.1, Panther's branding has its own message. Panther is tough. Panther means business. Just look at the box art evolution.

Mac OS X boxes: who's your daddy?

The caption says it all. Although I'm not a big fan of the typeface used for the metal "X", the intimidation factor of the Panther branding can't be denied.

The second reason Panther's branding is interesting to me is that it shows just how ruthlessly dedicated to the creative process Apple has become. I am hard-pressed to think of another company that, after investing millions in establishing a big-cat-themed product naming scheme and accompanying animal fur branding, would switch to an entirely different aesthetic with the very next release.

It would have been all too easy to have Pixar render a sleek, black-fur "X" logo, slap it on a box with a black spine, and call it a day. Indeed, many people still consider that design to be the more attractive choice. But it's also the "lazy" choice. Just as the "lazy" iMac redesign (which now lives on as the eMac) was rejected in favor of the significantly more challenging (in many senses of the word) "sunflower" LCD iMac, a black-fur Panther logo falls short of the creative standards Apple (apparently) sets for itself.

Regardless of the merits of the end result, I respect this type of discipline. If you're not willing to challenge both yourself and your customers, you'll never end up with anything Insanely Great. Kudos to those responsible.

One last branding note: I'd be remiss if I didn't mention the continuation of the Jobs-accent-heckling Mac OS X nickname trend. Just as all the cool kids talked about Jagwire last year, so too is Panther (increasingly inexplicably) called "Panthwire" by the few, the proud, the painfully 1337. Rock on, brothers.

Installation

Panther comes on four CDs: three discs for installing the OS and one disc containing the developer tools. The installation options are the same as those for Jaguar. I chose to do a normal "upgrade" install on top of 10.2.

I customized my installations in several ways. I omitted almost all the foreign language support on the PowerBook in order to save disk space. I installed some of the optional developer tools, including the gcc 2 compiler suite, guessing (correctly) that it may be handy when trying to compile Unix software that is not quite ready for Panther's default gcc 3.3 compiler.

There's a new intro movie and some new background graphics in Panther's setup assistant application, but overall, the installation process is the same as Jaguar's. I'd still like to see a few more options, particularly an "archive and install" option that can be reversed, allowing the user to revert a system to a previous OS version.

But given the Unix roots of Mac OS X, having multiple bootable OSes on a single volume is a bit tricky, to say the least. While Apple has been good about confining its files to the /System directory, the BSD layer is not so kind, and gets very grumpy when things like /usr aren't where they should be. These are surmountable problems, but the cost/benefit ratio is apparently still too high.

Unix in Panther

Some big changes are afoot on the Unix side of the fence (some of which I'll talk about later). Panther has synced with FreeBSD 5, and has incorporated gcc 3.3 as its default compiler. The new version of gcc is better at optimizing code for the PowerPC. More importantly, it includes performance profiles for the G5 (a.k.a. PowerPC 970), having the ability to leverage that chip's unique features, including native 64-bit integer arithmetic (obviously) as well as more obscure features like the G5's hardware square-root function.

I compile and install a lot of Unix software on my OS X systems, and I don't use a package management system like Fink or Darwin Ports. (The latter was reportedly going to be included in Panther, but was then pulled before release.) In OS X 10.0 through 10.2, I've had more than my share of epic battles with uncooperative wads of source code and, in particular, Mac OS X's dare-to-be-different linker.

Through a combination of Panther's improved compiler toolchain and the collective experience open source software developers now have with Mac OS X's eccentricities, I'm happy to report that building Unix software on Panther is now a much more pleasant experience. To give just one example, the latest stable version of perl compiles cleanly without any hand-holding and passes all tests. Will wonders never cease?

More so than its predecessors, Panther ships with the latest versions of most Unix software—allowing for some lead-time, of course. Although I mentioned compiling perl, Panther ships with perl 5.8.1RC3 which was released on July 30th. The official 5.8.1 release came on September 26th, about a month before Panther's release. A four month-old version of perl may not sound so great, but consider that Jaguar shipped with Perl 5.6.0 which was released in March of 2000. Apple has clearly gotten its act together as far as keeping Mac OS X in sync with open source software projects.

Panther's authentication system finally supports passwords longer than eight characters. (Previous versions would allow longer passwords, but then ignore everything but the first eight characters.) It also uses shadow passwords by default, which means that even the encrypted versions of account passwords are not publicly accessible. These changes are long overdue. Be warned, however, that if you are upgrading from Jaguar, your passwords will still use the old system. To fix this, simply change your account password using the relevant preference pane or the passwd command-line tool.

Apple ships its OpenGL-accelerated port of XFree86 with Panther. Formerly a free download, it is now an optional install from the Panther CDs. I had more than my fill of X11 during my undergraduate education, so I merely expect Apple's X11 to let me run X applications in a pinch, and it does that admirably. For recovering X11 users, Apple has also seen fit to hide a focus-follows-mouse feature in its Terminal application. (Sorry, no auto-raise yet.)

Speaking of our friend the Terminal, I am sad to report that my pet Apple Type Services bug remains unfixed in Panther. For those of you who want to use 9pt Monaco in your Terminal windows without any character-spacing errors, the work-around I have been using is to manually edit the Terminal property list file, setting the font spacing to a value that is impossible to get via the GUI:

<key>FontWidthSpacing</key>
<string>1.003</string>

Then never, ever touch the font panel in the Terminal, and patiently wait for next year. Sigh.

Panther's new look

The "ruthless dedication to the creative process" that I praised earlier also extends to the look and feel of the OS itself. Put simply, things look subtly different in Panther. Let's start with the menus.

Jaguar menus

Panther menus

 

Ignore the extra menu item, keyboard shortcuts, and spacing differences, and focus on the stripes. The pinstripes in the menu background are nearly invisible in Panther. This is true everywhere the generic pinstripe background is used in the OS. The Panther stripes are so subtle that Jaguar looks positively jarring in comparison. If you disagree, just try looking at Jaguar after using Panther for a few days.

Also note that menu-item separators have been restored to their classic Mac OS look in Panther. While Jaguar used an empty space, Panther now has actual lines. Overall, I much prefer the Panther look for menus.

Panther's menu manager is greatly improved, particularly when displaying pop-up menus near the bottom or top of the screen. Previous versions of Mac OS X had a tendency to show oddly truncated menus in some situations, requiring some unnecessary scrolling. Sub-menus are also no longer limited to 5 levels deep.

While pinstripes have been heavily subdued in the signature Aqua background pattern, they have been eliminated entirely from window title bars.

Jaguar title bar

Panther title bar

I'm not a fan of this change, mostly for sentimental reasons. Mac title bars have always had pinstripes of some kind, and Aqua's ubiquitous use of pinstripes always struck me as a nice homage. But if pinstripes are to be removed or subdued, I'd expect their last bastion to be the window title bar. First the happy Mac is removed, and now this? It's almost too much for a Mac traditionalist to bear. But I did say "ruthless" before, didn't I?

Window title readability is improved with the removal of the pinstripes, but the pinstripes never appeared behind the window title in classic Mac OS anyway. If improved readability was the goal, there was no need to remove the stripes entirely. Lest we forget!

Also note that the Panther window widgets are no longer "floating" above the window, but appear more "sunken" instead. I prefer the floating widgets to the sunken ones. If Apple insists on using sunken widgets, I like the widget graphics in the Smooth Stripe third-party appearance theme better than Apple's interpretation. (What, you don't immediately see the difference? Pshaw!)

Icon selection in the Finder has changed in Panther. You can see a comparison with Jaguar below.

The Icon

Selected in Jaguar

Selected in Panther

While Jaguar darkens the icon itself and doesn't highlight the name at all, Panther doesn't alter the icon but adds a highlighted background to both the icon and the name. The Panther highlight is more reliable, since there is no guarantee that merely "darkening" an icon will result in a recognizable change--or any change at all (imagine a black icon). It's also not easy to tell if an icon has been darkened (or lightened or inverted or any other color change) unless you have a good idea of what the original looked like.

Panther goes to great pains to avoid such "invisible highlights", providing both a translucent tint for the icon background as well as a solid color outline, at least one of which will always be visible on top of any possible background color. Similarly, the name highlight has a subtle shadow to define its edge.

The Panther highlight is a lot more visible than its Jaguar counterpart, which is the whole point of highlighting. Some people think Panther's highlighting looks ugly and amateurish, but the last thing Apple needs is negative feedback when it puts usability ahead of aesthetics for a change in Mac OS X.

Many icons are subtly different in Panther as well. Here are just two examples. (If your web browser doesn't support PNG images: Hello from the year 2003! Come join us!)

Jaguar	Panther
Jaguar	Panther

Are those icons really so different that they needed to be redesigned? The small increase in size may have been driven by usability concerns, but it's not like the old icons looked bad or were more difficult to identify than the new versions. In fact, the contrast has actually decreased on the new System Preferences icon. I detect a little bit of "change for the sake of change" creeping into Panther's look and feel. While that is acceptable and even admirable in the world of marketing and branding, it is a fine line to walk in the user interface of the product itself.

Has Apple crossed that line in Panther? Take a look at this modified screenshot of the Sound preference pane from Jaguar that shows off the Aqua tab-view widget.

Jaguar tab-view widget

Granted, the Aqua pinstripes do seem a bit jarring after seeing the more subtle Panther variety, but those Aqua tabs look just fine to me. Now look at the tab-view widget in Panther.

Panther tab-view widget

Yes, that is the same tab-view, not an entirely new widget. In addition to no longer looking remotely "tab-like", the view pane itself has changed from a rectangular "floating plane" to a darker "sunken well" with rounded corners.

(Also note that the slider widget has also changed, getting thinner in Panther.)

I have yet to hear a convincing explanation for the tab-view's new appearance. The relevant WWDC session was not illuminating. The change was presented as if the new design is so obviously better than the old one that a mere description of the differences is equivalent to an explanation of the reasoning behind them.

As a consequence of this change, there is a lot more of the the tab-view's darker shade of gray throughout the OS. Panther tab views even get darker as they nest. (No it's not just an optical illusion.)

Nested Panther tab-views get darker

This gives Panther a slightly darker look, which may be easier on the eyes. I think it looks a tiny bit "Windows 95-ish", but Windows 95 itself looked decidedly "NeXT-ish", so it's all in the family, I suppose.

Panther adds a new control size: "mini." Take a look:

Mini-widgets: actual size!

No, that image is not scaled down. Now there are three sizes for most widgets in Mac OS X: regular, small, and mini. Mini-widgets were requested by application vendors that need to fit a lot of controls into a small space (e.g. 3D modelling applications with many floating palettes). You can see some examples of the dramatic space savings provided by mini-controls in Apple's human interface guidelines. (Also note the new "circular slider" control.

It's nice to see Apple being so responsive to developers. For years during the reign of classic Mac OS, developers were forced to create custom controls for widgets in such common use that they should have been added to the OS long ago. Mac OS X has totally turned that around, benefiting developers, users, and Apple itself. Developers have less work to do, users don't have to worry about custom controls behaving incorrectly or looking odd, and Apple can more confidently admonish developers for rolling their own controls when there is (surely) a standard control that will do the job. Plus, mini-widgets are so darned cute.

The toolbar widget now highlights the active item when used as a pane-switcher as in System Preferences. (The far-left icon is selected in the screenshot below.)

System Preferences

Yes, System Preferences has been rearranged again. At some point, I think someone needs to make a final decision here. Three years should be enough time to pin this down. Yeesh. Anyway, you can arrange things alphabetically if you don't like the categorization-du-jour in Panther. Also note the alternating darker-gray background that makes the categories more visible.

Straying a bit from look and feel, you can see that several preference panes have been renamed (Internet becomes .Mac, General becomes Appearance, etc.) or consolidated (Keyboard and Mouse, Desktop & Screen Saver) to make room for some new preference panes. Panther also allows third-party preference panes to be installed by dragging them into the System Preferences window (a dialog pops up asking whether to install system-wide for just for the current user), and removed by control- or right-clicking on the preference pane icon.

Apple's ever-changing guidelines for when and where to use the brushed metal look have changed yet again in Panther. The new guidelines can be found at Apple's web site. Here's what they have to say this year:

You can use a brushed metal window if your application:

• Provides an interface for a digital peripheral, such as a camera, or an interface for managing data shared with digital peripherals--iPhoto or iSync, for example.
• Strives to recreate a familiar physical device—Calculator or DVD Player, for example.
• Provides a source list to navigate information—for example, iTunes or the Finder.

A "source list" is defined as follows:

A source list is an area of window set off by a movable pane splitter to provide users a way to navigate data. Use a source list when the data presented in it is a primary means of navigating within the application, as in iTunes or the Finder. Users select objects in the source list that they act on in the main part of the window.

As others have pointed out, by this logic, many Apple applications still don't fit within these guidelines. It's pretty clear by now that the guidelines are an attempt to explain Apple's choices, which unfortunately seem to change with each OS release. There are also still several variants of the brushed metal look, as shown in this forum post. What a mess.

Typing command-tab now brings up a very prominent application switcher overlay.

Panther's new application switcher

This is a vast improvement over previous versions of Mac OS X which tried to use the Dock for this purpose (as if it doesn't already have enough to do). Trying to track a subtle highlight as it hops among the various other icons in the Dock (i.e. inactive applications) is extremely difficult. It's not even obvious that you should be looking at the Dock in the first place. But there's no missing the Panther implementation.

Finally, Panther includes the obligatory handful of whizzy new animations. Here are two of them. First, the slide-out sheet animation has been tweaked slightly.

Step through the movie a frame at a time if it moves too quickly at full speed. Sheets (blessedly) slide out faster in Panther. This new "curling out of a slot" animation is only used in some situations, apparently depending on the size of the sheet relative to the window and the type of window (metal vs. Aqua). It's cute.

Application launching is now accompanied by a zoom-and-fade animation.

Stuff like this is pure eye-candy, but there's virtually no performance hit. Even the G3/400 had little trouble showing these animations. An option to disable these features still might make the OS "feel faster", but it would also be slightly less fun. The lack of a setting for these features means that Apple has made this judgment call for you, for better or for worse.

As an aside, note that Finder windows (like the one shown above) have no scroll bars at all when the content fits entirely within the window. The classic Mac OS human interface guidelines considered this a bad idea, and I agree. Scroll bars should be visible, but inactive when there is nothing to be scrolled. Controls popping in and out of existence, eating into what appears to be the window's content area, is not my idea of a user-friendly interface.

New look summary

There are many more changes than those listed above, but I hope you get the idea. Overall, Panther's new look is an improvement over Jaguar in terms of usability, while back-sliding a bit (in my opinion, of course) in aesthetics. I'm not a fan of the pinstripe-less title bars or the swaths of darker gray, but the more-subtle pinstripes elsewhere more than make up for these changes.

The "churn" in the OS X look and feel does concern me, however. On one extreme you have classic Mac OS which didn't change its widget appearance for years on end, and on the other extreme you have Mac OS X which seems determined to change every year. A happy medium would be nice, or, at the very least, an adequate explanation for all of the changes.

The new tab-view really takes the cake. It's not that it's a bad control or that it looks ugly, but it certainly isn't very "tab-like." And what was so wrong with the old widget? Is this the most efficient use of interface design resources at Apple? I find it all kind of puzzling.

One person's puzzle is another person's source of excitement, I suppose. But I'm a lot more interested in increased usability than lateral look-and-feel changes. One also wonders why Apple gets to have all the fun. Officially sanctioned third-party theme support would be nice, but I'm not holding my breath.

Performance

Panther is faster than Jaguar. There are a few ways to look at this. First, there's the boring, old world of numerical performance. You know, benchmarks and all that jazz. Panther wins these mostly on a technicality: gcc 3.3 produces more optimized code, and can better leverage the G5. Panther itself is built with gcc 3.3, so there you go.

But "perceived performance" is where Mac OS X has always suffered. As far as the user experience is concerned, if it "feels slow," it is slow. Panther has improved here as well. I am hard-pressed to find any part of the user interface that does not feel noticeably faster in Panther than it does in Jaguar. It's as if the cobwebs have been removed from the OS. There are far fewer "uncomfortable pauses" in the UI. Animations have fewer frames, and therefore complete faster. Yes, even windows resize slightly faster.

This is mostly the result of optimization in a handful of very common operations. In particular, almost everything having to do with text (measuring text, text layout, text rendering, etc.) has gotten a significant performance boost in Panther. This sounds like a pretty boring optimization, but it really pays off.

Here's another way to look at Panther's performance. For over three years now, Mac OS X has gotten faster with every release—and not just "faster in the experience of most end users", but faster on the same hardware. This trend is unheard of among contemporary desktop operating systems. It certainly didn't apply to classic Mac OS, where every significant new OS version was perceptibly slower than its predecessor on the same hardware. (Yes, System 7 and Mac OS 8, I'm looking at you.) The world of Windows follows a similar trend. It is usually taken for granted that a shiny new OS will not really sing until you upgrade your hardware.

Not so with Mac OS X, as my blue and white G3/400 can attest. It has hosted every version of Mac OS X ever released, and the darned thing just keeps getting faster.

Of course, the more pessimistic angle is that Mac OS X's performance had nowhere to go but up! And like System 7 and Mac OS 8 before it, Mac OS X is indeed perceptibly slower on the same hardware than its distant predecessor, Mac OS 9. But I'd argue that the 10.1-to-10.2 and 10.2-to-10.3 transitions were at least as significant, as measured by lines of code changed and new features added, as the transition from System 6 to System 7, or System 7 to Mac OS 8. I think it is fair to give Mac OS X some credit where credit is due.

Part of the reason for classic Mac OS's slow evolution and generational performance dips is the nature of the code. Classic Mac OS is a tangled wad of phone cord next to Mac OS X's neatly-ordered spice rack. Mac OS X changes so significantly and improves so rapidly because it can. Whole subsystems are refactored, recoded, or resynchronized with work done elsewhere (e.g. FreeBSD, XFree86, OpenSSL, etc.) to a degree that would (and probably does) make a classic Mac OS programmer's head spin.

For those who haven't been paying attention, this is the big pay-off for going with the Unix-based NeXT platform as the basis for Apple's new OS all those years ago. It gave Apple a modular Unix-flavored foundation that is well-understood by legions of smart developers, many of whom Apple quickly (and smartly) scooped up and put to work on Mac OS X.

At every WWDC, I am more and more impressed at the sheer volume of "stuff" that has changed under the hood in each new Mac OS X release. Seemingly everything is up for grabs. The potential down-side is that Mac OS X developers must be nimble in order to keep up with Apple's OS developers. While Apple is good about maintaining existing APIs, the new APIs are often so compelling that any developer who does not adopt them is at a competitive disadvantage. It seems that only the strong will survive.

Window management

Now for a sobering dose of perspective. While Panther is indeed faster than Jaguar on the same hardware, it is still not nearly fast enough in many areas. Those darned cobwebs have not been fully excised from Panther. Window manipulation in particular still sometimes pauses, stutters, and generally lags behind my mental state.

Yes, this does indeed include our old nemesis, window resizing. While the window resizing speed on a beefy G5 is acceptable, I am left to wonder exactly what is (still) gumming up the works even a little. Is the system CPU-bound as it renders the window contents "in software" rather than on the video card? Is memory bandwidth still an issue on a Mac with a 1GHz memory bus? Is the real culprit IPC overhead related to the window server? I am fresh out of ideas. It seems clear that this "problem" will eventually solve itself as Macs (finally) start to get faster, but we're not quite there yet.

Clutter, an application that creates a small window for each album in your iTunes music collection, provides a good stress-test for window handing.

Clutter: about 130 windows (some overlap)

Simply showing and hiding the Clutter application (and all of its windows) takes about 1.5 seconds on a dual 2GHz G5 with 1.5GB RAM and 128MB of VRAM. You can actually watch as the clutter appears or disappears, one album cover at a time. Less than two seconds doesn't sound very long, but you'd be surprised how little it takes to make you feel like you're "waiting for the computer", especially when simply moving from one application to the next, hiding or showing windows as you go. Toggling window visibility should be instant, and I'm interested to know exactly what is causing the lag.

Disk performance

It's a sad fact of life that most slow operations during everyday use of a dual G5 are I/O bound. Disk performance is what's keeping applications from launching instantly or files and folders from being copied without any tiresome progress bars. And when the virtual memory system starts thrashing, almost every operation suddenly becomes gated by the speed of your disk.

Mac OS X has addressed this problem in a few ways, historically. The easiest solution is to simply do less disk I/O. Application launching performance was greatly improved in earlier OS X releases by reducing the number of frameworks that are read from the disk during the launch process. The second solution is caching. Mac OS X has always been aggressive about using any available RAM as a file cache. Panther goes a few step further with two new features: automatic file defragmentation and hotfile clustering.

A file is fragmented when the data it contains is spread over the disk instead of being contained in a single, contiguous set of disk blocks. Since moving the disk head from one location to another is one of the slowest operations possible in a hard drive, fragmented files take a disproportionately long time to read. It is difficult to avoid fragmentation entirely, especially for files that grow slowly or without bound. Defragmentation collects the data from a fragmented file and moves it to a contiguous region of free space on the disk (assuming there is one large enough).

Under certain circumstances, Panther will defragment files automatically. You can read the thread in Macintoshian Achaia for all the gory details, but the short answer is that fragmented files less than 20MB large on journaled HFS+ disks are defragmented automatically in Panther when they are opened, whether for reading or for writing.

This initially strikes me as a slightly wrong-headed optimization. First, it seems odd that up to 20MB of data could be written to the disk as a result of merely opening a file (note: not actually reading or writing any data either, just opening). Second, if fragmentation is such an issue on HFS+ disks, a better solution is to improve the allocation policy or, better yet, replace HFS+ with a better file system (which Apple is doing anyway as part of its filesystem metadata enhancement project...right? Right?)

Nevertheless, I am more than willing to give Apple's HFS+ developers the benefit of the doubt and assume that this optimization was created as a result of performance profiling, and was tested and shown to provide a net performance improvement in typical usage.

Hotfile clustering, which is also detailed in the forum thread, is another optimization that I instinctively view as premature. Panther tracks frequently accessed files and slowly migrates them to a "fast" portion of the disk. This only happens on the boot disk, and there are constraints on the number and size of the files that are eligible. As a side-effect, transferring files to the hotfile area also defragments them.

It seems to me that this optimization tries to out-smart the normal file caching mechanism. But as with the automatic defragmentation, I'm willing to trust that this change has proved itself in testing. I can imagine that it does actually play well with normal disk caching, since presumably all of the very frequently accessed files will be in a conveniently cacheable contiguous cluster (say that three times fast) in the hotfile area.

The proof is in the pudding: Panther thrashes less than Jaguar on the same hardware in my experience. Admittedly, this could be attributed to many things, not the least of which is the fact that this is a freshly installed OS. But remember that I did a normal "upgrade" install rather than an "erase and install", so I'd like to think that these two new features really are at least partially responsible for the decreased disk activity.

Here's one final anecdote about Panther's file caching performance. I had to extract a few icons for this article from my Jaguar installation CDs because I'd neglected to save them before upgrading. They were stored inside a large (over 100MB) compressed archive on the CD. I used the command-line pax program to decompress the archive on the fly and extract the files. After I had extracted the first icon, I noticed that the CD had stopped spinning in the drive (this change is very audible on a G5). I then proceeded to extract the rest of the files from that same archive, and the CD never spun up again. Now that's some tasty disk caching.

Performance summary

It's hard not to like an OS upgrade that makes your computer faster. On both the lowly G3/400 and the mighty dual G5 (which started its life running Jaguar), upgrading to Panther provided an immediate and noticeable performance improvement. What more is there to say? Panther's performance lives up to its intimidating branding.

Fast user switching

Of all the new features in Panther, Fast User Switching has made the biggest difference in my computing life at home. Fast User Switching is Apple's name for the feature that allows more than one graphical login on a single Mac simultaneously. That sounds boring, but in my household, it's serious business.

Let's say I'm writing an article for a certain web site. I have the HTML source open in BBEdit, a bunch of images open in Photoshop, and many multi-tabbed Safari windows open to Mac-related web sites and other things I plan to link in the article. I also have an e-mail application and an IM client running, iTunes playing, and so on. Then my wife wants to "use the computer for a second."

The whole point of having multiple user accounts in Mac OS X is so that my wife can have her own little world: her own bookmarks, e-mail and IM accounts, music collection, and so on. But in the situation described above, I am loathe to close every window and every application that I just spent hours building up into a comfortable working environment just to let my wife check her e-mail. So we end up partitioning the applications into "his" and "hers" in a classic-Mac-OS-style compromise: I use Fire and she uses iChat, I use Entourage and she uses Apple Mail, and so on, all within "my" Mac OS X account. So much for "separate worlds."

Panther solves this problem by allowing both of us to be logged into our own separate accounts simultaneously. My wife can switch to her account and check her email in a few seconds by pulling down a menu. There's even a slick animation for the switch. When she's done, I can return to my account and everything will be exactly the way I left it. Ah, that's nice.

There are a few wrinkles. A password must be entered in order to switch to a different account. Only accounts with no password at all can be switched to without entering a password (as shown in the demo movie). Since it is all but insane to create accounts without passwords on a network-connected computer, this means that every switch will be accompanied by password entry.

The solution (and the way I expected it to work) is to have a setting in each account that (optionally) allows it to be switched to without a password once it has been successfully logged in. A more complex alternative is to include more finely-grained access control that would allow each account to specify which other accounts can switch to it without entering a password (again, only after it has already been logged in).

Other, more-thorny issues also arise once you start fast-user-switching between accounts. Some applications don't expect to be used by more than one user simultaneously, and may behave erratically. Other applications are aware of fast user switching but are not able (or don't know how) to handle multiple simultaneous users, and simply punt by only allowing one user at a time. iTunes is just one example of an application that doesn't (yet, presumably) play well with fast user switching.

But the issue is not quite as clear-cut as allowing more than one user to play music with iTunes simultaneously. What about device access? Say I start burning a CD, then allow my wife to fast-user-switch to a different account. Should she be able to eject the CD while it's burning? What about when it's done? The policy decisions are just as troublesome as the implementation.

I expect these issues to be hashed out over the years. For now, I'm ecstatic that the feature exists at all. I'll even tolerate repeatedly entering my password for at least one major release.

There's one more implicit caveat with fast user switching. Having two users logged in simultaneously uses more resources, particularly memory. Not twice as much, of course, thanks to a modern virtual memory system and dynamic linker, but you will use up RAM very quickly if you try to keep an entire family of five logged in simultaneously. Some paging is acceptable when switching to a user that hasn't been active for a long time, but eventually you just plain need more memory. (Isn't that just always the fact?)

CPU cycles are not as precious, since, presumably, inactive users are not doing anything too processor-intensive (or, more typically, anything at all). But if one user is ripping a CD and another is encoding MPEG2 files, don't expect great performance during the "active" user's 3D rendering job. You can't get blood from a stone, after all.

If any of your Macs are used by more than one person, fast user switching will change your life. As Steve Jobs mentioned when Panther was first demonstrated, this is one feature that Windows had first. But as the saying goes (a saying that has applied to many of Apple's accomplishments over the past few years), better late than never.

Window management—a digression

I think we've all seen a computer user lose track of a window. It's tempting to think that only "novices" have this problem, but the truth is that everyone has a limited short-term memory capacity. If you keep opening new windows long enough, eventually you will have to actually "hunt" for one, even if you were just using it moments earlier.

Most geeks have experienced the opposite of "hunting"—that effortless experience of simply thinking about the window you want and letting your mouse- or keyboard-hand do its magic trick to make the window appear. For long-time Windows users, surely the alt-tab keyboard combination factors heavily in this experience, particularly for switching back and forth between two windows. Geeks that are skilled at internalizing the structure of the window list (programmers are especially good at this) can alt-tab across even large window lists with absolute certainty and very little thought.

Nevertheless, even an alt-tabbing guru (and especially a programmer) knows that a linear list has performance characteristics that don't scale well at all. Furthermore, even given a fully-formed mental model of a simple window list, it is frustratingly inefficient to be forced to traverse all intermediate elements to reach a destination. If a user knows where a window is in this admittedly inefficient list structure that he's maintaining in his head, why can't he jump right to it rather than hitting alt-tab five times?

So there are a few problems here. First, there's the structural model used by the computer to organize windows. It helps if this model is as "brain friendly" as possible. A "stack" or other one-dimensional structure is relatively easy understand, but it can very quickly bump into the limits of short-term memory as elements are added. Moreover, even for users with a complete, detailed model of the window stack in their infallible short-term memory, it's frustrating to be forced to walk the list one element at a time.

So how do you design an interface that's both "brain friendly" and allows the user to immediately jump to the exact window he wants at any time? Personal computer input devices limit your choices somewhat. The keyboard is not really designed for this task. Chorded key sequences are the traditional form of out-of-band signaling for keyboards, but there are a limited number of convenient combinations.

Alt-tab (command-tab to Mac users) is one of the more comfortable chords, and is fittingly used for task switching. But there's no easy way to specify a particular window with just a single chord. Hardcore geeks may be thinking of something like alt-tab-5 to jump to the sixth window in the list or some such, but at that point we have long since left the realm of interfaces that are usable by "normal" people. (Don't worry, vi will always love you.)

That leaves us with that "toy computer" input device: the mouse. The mouse is great at saying "that thing right there." Why not "that window right there"? It seems like a perfect fit, but there are a few problems.

If you spend most of your time typing, there is some amount of overhead associated with simply moving your hand from the keyboard to the mouse. Dedicated alt-tabbers will no doubt cite this as a reason that it's faster to hit alt-tab n times rather than reach for the mouse. (Choose your own value for n.)

Assuming you are willing to accept the context-switch overhead (or that your hand spends more time on the mouse than the keyboard anyway) what are your options now? Well, in true geek fashion, many OS developers have instinctively created on-screen representations of the good-old linear window list structure previously buried in the OS. The Windows taskbar started out like this. Say what you want about the Windows 95 taskbar, that little row of rectangles on the screen was worlds better than the alternative of asking users to create and maintain that structure in their own minds. Perhaps there's a lesson here...but for now, let's move on.

So now your mental model has come to life on the screen. You don't need it in your head at all anymore. The order and position of each element in the window list is effortlessly (as far as you're concerned) maintained by the operating system on your screen.

But it does become tedious to scan that on-screen list for the window you want, especially when each tiny rectangle doesn't have enough identifying information. (Can I interest anyone in seven taskbar tiles all named "Internet Explor..."?) So it is advantageous to at least remember the position on the screen of the handful of tiles that you are switching among most frequently.

Then you (possibly) pay the mouse-switch toll and click on the taskbar tile on the far-right, and then the one in the middle with the blue icon, and so on. Okay, maybe it's not entirely unconscious, but hey, it is direct access rather than forced traversal of the window list. We're making some progress.

We can also address the computer's organizational model. A one-dimensional list causes problems when there is a limited amount of screen space. A two-dimensional model where windows are nested under their parent applications drastically reduces the screen real estate needed, but it also adds one more step to the process of getting at a particular window. Is it a net win? That depends on how many windows you have open. A hybrid model that starts linear and then goes hierarchical when screen space gets tight may be a nice compromise. This sounds a lot like where the Windows taskbar is today.

The Mac way

The Mac had the first mass-market GUI, and yet for over a decade it lacked almost all of the features described above. "Sure, that's because the Mac couldn't multitask for most of that time!" you may sneer. But even pre-Switcher (no, not that switcher), a single application could have many open windows. So window management was always an issue on the Mac, and it was an issue on the Mac first. What was Apple's solution?

Whatever merits alt-tab may or may not have, it was out of the question in the early days of the Mac because Apple wanted to do everything it could to get users to use the funny little box with a ball in it that dangled from each Mac. Perhaps more importantly, Apple wanted to force Mac developers to create Mac-like interfaces rather than simply porting keyboard-based interfaces from the PC world. The original Mac keyboard didn't even have arrow keys on it!

So did Macs have some sort of on-screen palette with buttons or tiles representing windows? Nope, nothing of the sort until at least a decade later. But surely each application had an OS-provided menu containing all the open windows in each application. Granted, picking your window from a pull-down menu isn't very efficient, but you at least need such a menu to exist as a last resort...don't you? Nope, that feature didn't arrive until Mac OS 9.

Okay, then how the heck were Mac users managing windows for that first decade or so? (Oh, how you wished mightily that you were going to make it through this article without seeing this word, but your luck has run out, my friend.)

(cue dramatic music) Spatially.

I've written about this topic before, and I'm going to write more about it later, but you only need the survey course in order to follow along here.

So, the answer to the Mac window management riddle? Why, Mac users simply pointed to the window they wanted and then clicked on it. ("You do know how to click, don't you Steve?" Oh, never mind.)

Come now, you say, obviously that is not a workable "solution." First, windows overlap. How can you click on a window that is entirely obscured by another window? Second, without some sort of list, whether one- or two-dimensional, somewhere in the OS, how will the user even know which windows exist? "Just click on the window you want" indeed!

Maybe it will help to recall that the Mac spent most of its life with a two-dimensional window layering policy. Windows were layered within each application, and then each application's window collection was layered amongst the other applications. So right away, the choice of windows (and therefore the odds of "catastrophically-obscuring window overlap") could be reduced significantly by bringing a particular application to the front. In classic Mac OS, merely clicking on any window belonging to an application would bring all the windows in that application's layer to the front.

But even just one application can have a heck of a lot of open windows. We're still left with a seemingly intractable problem: a big mess of overlapping windows. How is a user supposed to make sense of that?

The answer is probably right in front of you right now if you're sitting at your own desk. People are innately adept at molding their environment to suit their needs. All they need are the right tools. In life, you can get pretty far with just your own (fancy, opposable-thumb-sporting) two hands. On the Mac, you can get surprisingly far with just the mouse.

The Mac user interface guidelines helped by specifying that applications should conveniently tile newly created windows (slightly lower and to the right with each successive window) in an attempt to leave the title bar visible for as many windows as possible. But scanning a stack of tiled windows and reading each title bar is no more efficient than an on-screen window list. Perhaps what the computer cannot do for the user, the user can do for himself...

That's right, Mac users actually manually arranged their windows like so many pieces of paper on a desk. Insanity! The height of inefficiency! Au contraire. I won't bore you with the details yet again, but suffice it to say that there is a vast well of cognitive resources just waiting to be tapped by a bunch of boringly coherent and stable objects on a screen.

Just watch an old-school graphics designer using classic Mac OS (if you can still find one in the wild) switch among a seemingly overwhelming sea of windows faster than you, as a mere observer, can even identify what they are. The user knows what they are because he knows where they are, and where they'll be the next time he needs them--they're where he put them.

In short, identifying windows based on their size, position, and appearance (i.e. spatially) is massively efficient and imposes the absolute minimum cognitive load on the user. This is what people do best—not memorize, maintain, traverse, or chose from lists or tree-like data structures, but recognize and manipulate coherent, stable objects in space (virtual or otherwise).

That being said, there is a limited amount of screen space, after all. Eventually, there will be no place left to put your windows, or there will no longer be enough spatial distinction between windows to identify them. The screen starts to look a lot less like a bunch of objects in space and more like a slightly fancier graphical representation of a window stack data structure. This is bad news.

Luckily, we have all the techniques described earlier to fall back on. We have keyboard chords which, in Mac OS X, can be used to switch among applications (cmd-tab), and among windows within an application (cmd-`). Unlike classic Mac OS, Mac OS X does not confine windows to their parent application's layer; it allows the interleaving of windows from multiple applications. But per-application layering can be still be requested (e.g. by clicking on a Dock icon).

The Dock itself provides a two-dimensional taskbar-like structure for windows, with each application's icon sprouting a list of all its open windows in a pop-up menu. Each Mac OS X application also has an OS-provided "Windows" menu, and many applications also offer their own floating palettes listing all open windows. Finally, there are innumerable third party floating palette thingies that can aid in window management.

Still, it'd be nice if the screen space limitation could be dealt with somehow. Keyboard chording and selecting from lists are reasonable fall-backs when screen space gets too tight, but "just click the window" is really where it's at in terms of efficiency. Obviously we all just need bigger screens...or do we?

Exposé

Panther includes a new window management feature that effectively increases the size of your screen by shrinking all of your windows temporarily. Following Apple's recent Gallic naming trend, it's called Exposé. Exposé has three modes, all of which share a common mechanism.

When activated, Exposé shrinks and rearranges (if necessary) windows on the screen in such a way that the windows do not overlap at all. (In case this doesn't go without saying, all windows continue to update as usual during and after the transformation process.) The three different modes of Exposé determine which windows will participate in the rearrangement process at any given time. The choices are "All Windows", "Application Windows", and "Desktop."

"All Windows" means all visible windows. The exclusion of hidden windows may be a bug or a feature, depending on your point of view. A preference would be nice. "Application Windows" means all windows in the front-most application. "Desktop" shows only the desktop, sliding all other windows off the screen.

Exposé can be activated in a variety of ways, all of which are configured in its preference pane.

Exposé preference pane

Any mode can be assigned to a corner of the screen. When the mouse cursor hits that corner, the feature activates. (Screen saver activation and deactivation can also be set in the Exposé preference pane.) Exposé modes can also be assigned to function keys F1 through F13, optionally combined with one or more modifier keys, and the modifier keys themselves (shift, control, option, and command) can also activate Exposé features on their own. You must specify either the right or left modifier key when one is used in isolation. Finally, any mouse button can also activate Exposé, again optionally combined with one or more modifier keys.

The sheer number of possible configurations is daunting, but almost anyone will be able to find a comfortable setup eventually. The only possible gap in functionality is the lack of support for the function keys F14 through F16 (yes, Apple's new keyboards have an F16 key), which are used by Mac OS X for other functions by default (e.g. screen brightness for F14 and F15)

Exposé activation works in two ways. If activated by a key or mouse button (or combination thereof) and that key or button is held down, Exposé will deactivate when the key or button is released. If a key or button is tapped, or if a screen corner is used, Exposé will be toggled on, requiring another activating action to toggle it off again.

Hitting tab while Exposé is activated switches to "Application Windows" mode (if not already there) and cycles through the windows belonging to each application. Large application window-sets zoom in from "behind you." (Try it.) The ` key does the same, but in the opposite direction. The cmd-tab and cmd-` key sequences can be used to jump more than one application at a time before allowing Exposé to redisplay.

Exposé allows direct switching from one mode to another. You can go directly from viewing all windows to viewing one application's windows or just the desktop.

Mousing over a window when Exposé is activated highlights the window and shows the window title in large text. Clicking on the window brings it to the front and deactivates Exposé. In addition, a drag sequence that is started before Exposé is activated can be completed by hovering over a window (which will then come forward, deactivating Exposé) and then dropping the item.

The Exposé experience

Phew, that's a lot of functionality. And truthfully, it takes some time to feel the system out and decide how best to take advantage of it.

When in use, it looks even cooler than Apple's demo. (You can find some even more impressive Exposé videos on the web.) Thanks to Quartz Extreme, all of the scaling and window movement can be handled by the video card. The animation is very smooth on QE-capable Macs...right up until it falls off a performance cliff when the number of windows exceeds some value. My guess is that this knee in the performance graph is determined by the amount of VRAM, but it could also be due to the CPU overhead of the algorithm that determines the size and position of each window. (I'd love to hear from Apple on this topic.)

I plumbed these depths with the help of our old friend Clutter. Asking Exposé to show "All Windows" when Clutter is running with its 120+ windows added to my usual set of 20-60 windows resulted in about two frames of animation on a dual 2GHz G5 with 128MB of VRAM on a 1920x1200 monitor. About 40 windows is where the animation starts to drop frames on this system, but that is a just a rough estimate.

Thankfully, aside from bragging rights, it matters little how many frames of animation are shown as long as the process completes in a timely manner. Exposé seems to drop frames in an attempt to ensure that the window scaling and rearrangement process happens as fast as possible—a wise choice.

Exposé has many strengths and a few weaknesses. First, the weaknesses. While Exposé is an admirable attempt to provide a predominantly spatial window management interface, its implementation necessitates the marginalization or elimination of several spatial traits.

Window appearance is diminished as an identifying characteristic by an amount proportional to the number and nature of windows being arranged. Windows that contain images can withstand tremendous shrinkage while maintaining their identity. Graphic designers will therefore have a much higher window count threshold.

Windows containing text do not stand up to scaling very well at all. Identically sized Terminal windows are among the worst in this regard. Even at full size, appearance is not a strong identifier for text-filled windows. Unix geeks and programmers will not find Exposé as useful when switching among shell and code windows.

Position is very nearly eliminated as a recognizable trait. Exposé does try to keep windows as near to their original location as much as possible, but there's only so much it can do. Exposé's arrangement algorithm is deterministic, but it depends on not only the exact set of windows being displayed, but also which one of those windows was the front-most when Exposé was activated.

Exposé has strengths that are both obvious and subtle. The most obvious "big win" for Exposé is among novice or undemanding users who open few windows or have a very low tolerance for maintaining the state of the window stack in their heads. The answer to your mother's question, "Where did that window go?" can now be, "Here are all your windows. Click on the one you want." While this experience is subject to the weaknesses listed above, they are minimized during low-volume "typical" usage. Exposé makes mincemeat of a few web browsers, an e-mail client, and one or two Word documents.

For the more experienced user, Exposé offers a few unique advantages. The most important is perhaps the least obvious: speed. I mentioned earlier that showing and hiding large numbers of windows is still sluggish in Panther under some circumstances. Exposé, for whatever reason, seems to sidestep these performance pitfalls. My guess is that Quartz Extreme (and, by extension, OpenGL running on the video card) is to thank.

Here's just one example: showing the desktop. I have tried many different systems for getting to my desktop quickly. Initially, I used the "Hide Others" command from the Finder's menu, but that required switching to the Finder first. Then I installed a variety of dedicated utilities to do the job: docklings (remember those?), applications with floating windows, AppleScripts, and even Konfabulator widgets. All of them suffered from the same problem: Mac OS X cannot hide or show windows instantly (or any reasonable approximation thereof) once the window count gets too high. Exposé, on the other hand, can slide every window off the screen in a fraction of the time required by the other methods.

A second or two may not seem like a lot of time, but to hardcore users, any time spent waiting for the computer to catch up to their intentions is frustrating. A whole second seems like an eternity when you're "in the zone." Exposé may be a first: a Mac OS X feature that is full of eye candy but is also a speed champ.

Exposé has another important, but often overlooked quality: stability. No, I don't mean "stability" as in a lack of crashes or other software bugs (although there are no issues with those either). What I mean is that Exposé absolutely respects your right to control the objects on your screen—down to the pixel if you so desire. Despite its window rearrangement gymnastics, Exposé always puts your windows back exactly where it found them. It's important to understand that even the slightest deviation from this policy would be disastrous. Exposé would quickly gain a reputation as a "window scrambler" rather than a window management aid.

Finally, once you get used to the fact that you can quickly and fearlessly rearrange your screen like some kind of Olympian God of Window Buffers, the door opens to a whole new world of manipulation sequences with a formerly prohibitive degree of difficulty.

Need to add an attachment to an outgoing email message, but the file is on your desktop, buried under three week's worth of window clutter? Don't bother with that open/save dialog box, just slam the mouse into the corner, pick up the file, hit the corner again, and drop it in your message window.

Forget if you've already opened the background image for your Photoshop project? Forget about scanning the window list for a familiar title, just hit F10 and look for it. If it's not there, whack the mouse into the corner to show the desktop, click the Finder icon in the dock, put the mouse in the other corner to show all Finder windows, dig out the file you want, and drag it onto the Photoshop icon.

You get the idea. The only thing missing (from an experienced user's perspective, anyway) is some sort of slide-away shelf that's visible in the "Exposé world" where proxy icons can be stored. And, of course, spring-loaded folders in the Dock, which Panther still lacks. (Boo!) Finally, For those looking for a click-target for Exposé activation, there's a funny blue blob with your name on it.

Exposé summary

In its effort to add new window management functionality to Mac OS X, Apple could have very easily piled on the floating palettes, pop-up menus, and window lists that have traditionally defined the world of window management aids. Instead, Apple's designers appear to have taken a step back and reconsidered the problem domain. By expanding the ability to manage windows based on appearance rather just a text title, Exposé plays to the strengths of the dominant variable in the window management equation: the user. Shored up by existing "traditional" window management features from earlier OSes, Mac OS X now stands head and shoulders above its contemporaries when it comes time to, as Apple puts it, "Find the window you need. Now."

The Finder

The Finder has not fundamentally changed in Panther. "But wait!" you say, "What about the brushed metal, and that sidebar? It's a whole new Finder!" Sadly, that is not the case. Although the appearance has changed in somewhat dramatic fashion (depending on how you feel about the brushed metal look), the user interface of the Mac OS X Finder is essentially unchanged. As you may already know, I consider this a bad thing. But before we get into all that, let's look at what has changed.

The Sidebar

While previous versions of the Mac OS X Finder featured a customizable toolbar, Panther adds a sidebar to the mix and then turns the entire window metal.

The Finder with a toolbar and sidebar

The toolbar contains items that perform actions: new folder, delete item, switch view, etc. There's also a new toolbar item that pops up a menu containing the same commands as the control- or right-click context menu. It's the button with the "gear" icon in the screenshot above. Panther includes this "action" menu-button in many places as a way to ensure that there is a user-visible access point for commands that would otherwise be "hidden" in context menus. I'm not sure how well an icon of a gear conveys the intended message, but the sentiment is sound.

Other items that could previously be dragged to the toolbar (e.g. files and folders) can now be dragged to the new sidebar as well. There is a default set of items that can be changed in a Finder preference panel. Beyond that, it is up to the user to drag items in or out.

The icons in the sidebar scale with the available space, shrinking from a maximum size of 32x32 pixels to a minimum size of 16x16 pixels as space becomes tighter. A scroll bar appears in the sidebar when the list of items no longer fits in the available space. A scrolling list is a big improvement over the previous mechanism for handling overflow.

The primary conceit of the sidebar is revealed when an item is selected. Look again at the screenshot above, and notice that there is no horizontal scroll bar in the window. Despite the fact that the item selected in the sidebar (my home directory) is actually located at the path /Users/john, it is not possible to back up a level in the directory structure by scrolling left in the column view.

Apple considers this a feature. One of the complaints about earlier versions of Mac OS X was that the directory structure was not "user-centric" enough. Used to "owning" the whole machine, Mac users were uncomfortable with OS X's directory structure that dictated that their sphere of influence start a level or two down in the hierarchy. Panther's solution is not to alter the directory structure, but to create the illusion that a user's "familiar places" (as indicated by the choice of sidebar items) all appear to be the top-level of the hierarchy when selected in the sidebar. While this policy may help some users feel more comfortable, it may also be seen as unnecessarily limiting by more demanding users.

Live searching

The search field in the Finder toolbar is now "live", meaning it updates the result set as you type, a la iTunes. The search feature uses the same window-hijacking technique used in the Jaguar Finder. Once you start a search, your current window "becomes" a search results window. Luckily, clearing the search field or hitting the back button restores the window to its pre-search state.

Live searching in the Finder

The scope of the search is also (unintuitively, in my opinion) independent of the contents of the window where you begin the search. I expected the scope to at least default to "everything below the currently displayed folder," but that's not even an option. The closest is the scope of "selection," which searches below the currently selected folder or volume. [Update: if you choose "selection" and then don't select anything, the Finder will apparently search from the current directory downwards. That's hardly obvious, but it's there.]

The Finder's live search feature leverages the new SearchKit framework in Panther. Powered by Apple's venerable "V-Twin" search engine, SearchKit is used extensively, and to great effect throughout Panther. The rounded "search field" widget has been added to the standard set of Mac OS X controls, continuing Apple's commendable progress in this area.

Labels

The Panther Finder returns colored labels to nearly the full height of their System 7-era glory. (For those not following along, that was sarcasm.) There are seven label colors to choose from. While the label names can be customized, the colors cannot (without some resource hacking, that is). Rather than tinting the icon of the labeled item, labels in Panther color the background of both the name and the icon. It looks like this.

The new look of Finder labels

This new look follows the same reasoning as the new icon selection technique described earlier. But thanks to the new selection appearance in list view Finder windows, it's easy to confuse labeled items and selected items, especially when the colors are similar.

Labeled or selected?

In the screenshot above, the file named "Steve Jobs 1984" is selected, and the two below it are merely labeled. It's not easy to distinguish the rounded edges and gradients of the labeled items at a glance. When a labeled item is selected, things get even funkier.

Labeled and selected

That small red dot is all that is left to indicate that the selected file is also labeled.

Labeled icons only have a highlight behind their names. This helps differentiate labeled icons from selected icons, but it also makes the label less obvious. Compare the selected icon on the left with the labeled icon on the right in the screenshot below.

Labeled and selected icons

This is a tough problem, and the Panther look is a reasonable solution. A possible improvement for the list-view situation is to shorten the label highlight so that it only extends as far as the file name. That would put two rounded end-caps in view, in addition to the obvious visual distinction of the different lengths of the colored bars.

Labels are set via a strange new menu item that "shows off" the capabilities of Apple's new menu manager.

Setting Finder labels: what the heck is that thing?

I put "shows off" in quotes because I think this interface is an abomination. First, the "Color Label" menu item (if you can even call it that) does not highlight at all when the mouse is over it. Second, it takes up nearly three times the vertical space of a normal menu item. Third, it asks the user to click a series of tiny colored dots in order to make a choice.

This is unlike any previous "normal" menu item, and it is worse in almost all respects. The targeting demands are increased considerably, asking the user to aim horizontally as well as vertically, and substantially reducing the target size. Presumably in an effort to save space, text labels only appear when the mouse is over one of the tiny dots. As mentioned earlier, the cumulative space is more than that of a single, normal menu item anyway.

What, I must ask, is so horrible about a "Color Label" sub-menu? Granted, sub-menus are harder to navigate than simple inline menu items, but I have to believe that they have better performance characteristics than the system shown above. The ability to implement arbitrary custom views within menus is a potentially useful capability, but the Finder's label menu shows exactly how developers can hang themselves (and their users) with all this new rope.

Before we leave the topic of labels, let's look at the history of this feature. The Mac OS X Finder lacked labels from its inception, despite their presence in the Mac operating system since System 6 (circa 1988). Labels had become a central part of many Mac users' workflows, and they were sorely missed. Industrious third party developers went so far as to add labeling back to the Mac OS X Finder through various nefarious means.

The common wisdom regarding the missing labels was that the decade-old mechanism for storing label information in classic Mac OS (a few bits in an HFS/HFS+ filesystem data structure) was due for an overhaul. The hope was that Apple was working on something much better than a paltry fixed set of seven label colors stored in obscure fields in Apple's proprietary volume format.

Apple may indeed be working on something better, but the Finder labels in Panther use the same old obscure fields in HFS+ as their System 7 forbearers (and therefore have the same limitations). In other words, Mac users waited three years to get back what they already had, with no improvements. This could just be a question of resource limitations and priorities at Apple, but a more pessimistic theory surmises that labels were omitted from Mac OS X 10.0-10.2 simply because the ex-NeXT developers who lead those development efforts simply didn't like them.

I actually don't subscribe to the latter conspiracy theory, but I am disappointed that a three-year wait did not result in the hoped-for spiffy new labeling system. My fingers are crossed for Mac OS X 10.4.

Finder performance

Previous versions of the Mac OS X Finder suffered from a bad case of "spinning rainbow disc" disease. That multicolored spinning cursor appears when an application has stopped processing events for a few seconds. In Jaguar and earlier, the Finder would become totally unresponsive in a variety of common situations, most involving access to network resources. Panther substantially reduces, but does not quite eliminate this problem.

Network volumes can be mounted via the "Connect To..." menu item, as in Jaguar, but Panther also allows network browsing through the previously underused "Network" icon at the top level of the Finder hierarchy. Windows networking is now based on the more capable Samba version 3. Sadly, the Finder's half-hearted implementation of FTP still does not allow FTP uploads and still performs like a dog when compared to third party FTP applications. On the WebDAV front, Panther includes an option to create a local copy of your iDisk that is automatically synchronized in the background, presumably as a sop for continuing poor network performance in this area.

Most complaints about the Mac OS X Finder's performance have revolved around the topics listed above, particularly networking. But there's another, simpler aspect of a file manager's performance that seems to have been eclipsed by these more serious problems. Back in the days when Mac OS X was just a series of colored boxes on a slide and a few thousand rumors on the web, the Finder in the next-generation Mac operating system was imagined to be a file shuffling machine, able to tear through folders and volumes with thousands upon thousands of files without breaking a sweat.

The reality of the original Mac OS X Finder was that simply trying to open a window containing a few thousand files resulted in a total application lock-up and some more quality time with your old rainbow friend. Eventually, the action would resume, but God help you if that folder was on a network volume. You might as well go get a cup of coffee.

Similarly, selecting and then acting on large numbers of files and folders was fraught with lock-ups and long waits. Right-click on a selection of a few thousand files and you're in for a nice little vacation. Try to drag those same files and you will be holding that mouse button down for a long time as you wait for the Finder to start responding again. This is not the advanced, ultramodern Finder we all envisioned.

Matters have improved steadily, and Panther is faster than its predecessor when dealing with large numbers of files. But steady improvement is not going to cut it, not at its current rate anyway. Manipulating, or even just viewing large numbers of files is still orders of magnitude too slow in the Panther Finder, particularly when dealing with network volumes.

For example, I recently tried to scroll through a list-view folder on an SMB share containing about 2,000 files using the Panther Finder on a dual 2GHz G5. The server was on the local 100Mbps LAN. It took me several minutes of patient hand-holding as I dragged the scroll thumb through small portions of the file list, waiting each time for the Finder to slowly display the icons for the newly revealed files before it would let me continue.

The Finder would literally not let me scroll to any of the "unknown" portions of the file list until it had finished doing whatever it was doing to display the icons of the newly revealed files. These files were all of the same type, and were plain, flat files with no resource forks and no Mac-specific metadata. Only after fighting with the window for several minutes was I finally able to drag the scroll thumb from the top to the bottom in one continuous motion.

Listing that same directory from the command line is nearly instantaneous. Some overhead for the GUI is expected, but this is ridiculous.

Unfortunately, making a lightning-fast GUI file browser is actually a very hard problem full of special-cases and in need of clever optimization. The Mac OS X Finder appears to use a lot of standard Mac OS X controls and views. Performance improvements in the Finder have partially been a result of the optimization of these OS-provided widgets.

But while optimizing common controls is an important task that can significantly improve the performance of all applications simultaneously, certain applications simply have needs that are far beyond what generic controls can provide. The Finder is one such application. Whether through completely new custom controls or through clever subclassing, the Finder needs to implement its views with an eye towards efficiently handling thousands of files and folders with ease and speed.

Even in situations where the underlying data is the gating performance factor (e.g. slow network disks), the Finder must do everything it can to remain responsive, showing as little or as much information as it has at the moment, but never blocking the user from interacting with the GUI. Controls and views that expect to be backed by in-memory objects and data structures are poorly suited to this task.

Independent of any other interface issues, I hope to someday view, scroll through, and manipulate vast numbers of files and folders in the Mac OS X Finder with the thoughtless confidence befitting a modern operating system running on a multi-gigahertz machine with gigabytes of RAM. Sorry, Panther Finder, but you are not yet that file manager.

Taking a poll

There's one final aspect of the Finder's performance that deserves some mention here, even though it's actually a usability issue at its core...or rather, it should be. As any software developer will tell you, "Polling is bad, m'kay?" Polling is the act of repeatedly rechecking some condition. An example that's relevant to the Finder would be repeatedly asking, "Are there any new files in this folder? Are there any new files in this folder? Are there any new files in this folder? Are there any new files in this folder?" and on and on at some regular interval.

This, needless to say, is not the best use of CPU cycles, since the answer will be the same nearly all of the time: "there are no new files in this folder, now leave me alone!" Okay, so I added that last part, but the sentiment is apt. Polling is indeed bad.

But if you think about the situation described above, the apparent responsiveness of the Finder seems to depend on the frequency of that accursed polling. Let's say you download a file to your desktop using a web browser. If the Finder only polls the desktop folder every ten seconds, that file won't show up for an average of 5 seconds. That's hardly "responsive."

Another alternative is to simply update Finder views when the user (or another program) tells the Finder to do so. This eliminates costly polling entirely. Even better, if applications faithfully notify the Finder of any changes they make to the file system, there will be no lag at all between the creation of a file and its appearance in the Finder. This is the system that Apple has chosen for the Mac OS X Finder, and it sounds like a good one.

In practice, however, not all applications appropriately notify the Finder after making changes to the file system. A command-line utility from the FreeBSD world is the worst-case scenario. It certainly can't be expected to have Mac-specific code for sending notifications to the Finder. Files created by one of these "uncooperative" (from the Finder's perspective) applications simply wouldn't show up in the Finder at all. Yikes.

The Mac OS X Finder has worked around this problem by polling just once when the user starts to do something with a particular folder. For example, a file copied to the desktop with the command-line utility "cp" will not appear until the user activates the Finder by clicking on the desktop, a Finder window, the Finder's Dock icon, etc.

Now it seems like we've covered all the bases. There's no polling at all, and the Finder is reasonably aware of any kind of changes to the file system. But issues remain. Most frustratingly, sorted list-view windows in the Finder have an annoying habit of updating just as you try to grab a file from them. If you're not paying enough attention, the window will re-sort its contents (due to a newly added, deleted, or modified file) and replace the file you meant to grab with another file. It is all too easy to really hose yourself this way, especially when deleting files.

This whole situation—polling vs. responsiveness—is somewhat indicative of what I have always viewed as a problem with the direction of Mac OS X's development. Granted, polling is bad, but its existence in classic Mac OS was indicative of a value system that put the user experience first. "What is the best possible user experience?" is the primary question, only then followed by "How can we make that happen?" In Mac OS X, it seems to me that the first priority has been to do what is most efficient, and then try to provided the best user interface that can feasibly be implemented on top of that foundation. The shoe is on the wrong foot in such a system.

It may seem contradictory to swear up and down about poor performance on the one hand and then ask that the user experience take precedence over all other concerns on the other, but performance is part of a good user experience. Focus on the user and performance will mostly take care of itself...yes, possibly meaning that you will have to implement new OS features in service of the user experience that you hope to provide. But the end result will be a better overall system. Quartz is one example of this principle in action, but the Mac OS X Finder seems to be a result of the opposite value system.

So let's look again at the responsiveness of the Finder when dealing with file system changes. Let's start with the premise that the Finder should always provide the user with an absolutely consistent view of the file system. This is essential to maintaining the illusion of direct manipulation. Obviously polling still sucks, especially if we need to poll several times every second in order to meet our responsiveness goals. What can we do that's better?

What if the responsibility for tracking file system changes and notifying any interested parties was moved from the applications to the operating system kernel itself? Since all local file I/O goes through the kernel anyway, surely it knows when, where, and how every change is made. This is all without polling, of course. There's no need to poll when you're the one making all the changes.

Well, it's Apple's lucky day. Faced with a similar problem—how to track state changes without costly, inefficient polling—those industrious FreeBSD developers have created a generic OS-level facility for asynchronous event notifications. It's called kqueue, and you can read all about it in this PDF file. Since Panther has synched with FreeBSD 5, it includes kqueue support. Now all the Finder has to do is register for notifications on all open Finder windows (and the desktop) and just sit back and wait for the operating system to inform it of any interesting events. Problem solved, and in a way that puts the user first!

Unfortunately, the Panther Finder does not do this. This feature is not absent due to the difficulty of its implementation. After a few days of effort, a handful of Ars Technica readers were able to whip something up that does the job. You can find the source code and some instructions for compiling it in the forum thread. The code is only about two pages long, and the most difficult part is finding a way to ask the Finder which windows are open. The code has to (sadly) poll the Finder periodically to gather this information. Apple's Finder developers would not have this problem.

So, why is there (apparently) no kqueue support in the Panther Finder? My guess is that Apple plans to add a new (or reimplement an existing) higher-level notification facility on top of kqueue, with APIs in CoreFoundation, and then Carbon and Cocoa on top of that. That's much more in keeping with Mac OS X's API structure than asking the Finder team to use the (decidedly Unix-y) kqueue APIs directly. But I could be wrong, and it could just be a lack of time that kept kqueue out of the Finder. Either way, in Mac OS X 10.4 the Finder team should proclaim "kqueue or bust."

Same as it ever was

I wrote (and have been mercilessly linking to throughout this review) an entire article (see?) about what's wrong with the Mac OS X Finder's user interface, and how it can be fixed. I did not write about all of the things covered in the previous sections of this review: networking, appearance details, interface responsiveness, performance when dealing with large numbers of files, etc. Instead, I focused solely on the fundamentals of the file management user interface. If you have not already read that article, you many not understand everything in this section because I do not plan to repeat myself in (much) detail.

I wrote earlier that the Panther Finder has not fundamentally changed, and with respect with the issues discussed in the earlier article, this is indeed the case. The fact that many users, and even reviewers seem to think that this is not the case illustrates the widespread misunderstanding surrounding this topic.

And so I am fated and cursed to disagree with both my detractors as well as those who claim to be in total agreement with me on the topic of the Finder. Here's is a quote from the aptly-titled Panther editorial, Missing The Boat On Panther:

Apple has created a fused Finder, one that has a built in File Browser that obeys the interface conventions expected of such a Browser, and a built in "spatial" (Classic Mac OS) Finder that obeys the conventions expected of such a Finder.

[...] This is a truly revolutionary step. It gives us the best of both words.

I don't mean to pick on any single reviewer, but no, no, and a thousand times no! The Panther Finder does not provide "the best of both worlds." It provides exactly the same self-destructive combination of spatial and browser-style features as all of its Mac OS X predecessors. Perhaps people are so blinded by the metal appearance that they can't see that it is simply a new look for the Jaguar Finder's toolbar. The actual behavior is exactly the same as far as browser-style vs. spatial interaction is concerned.

Any window can still be "transformed" from a "file browser" to a "regular folder" and back again at any time. The metal appearance is still haphazardly tied to individual folders just as the toolbar was in Jaguar. And just as the Jaguar toolbar was essentially impossible to entirely banish, so too will metal Finder windows haunt you in the Panther Finder regardless of your wishes.

This mix of browser-style and spatial interfaces necessarily, by definition, undermines the spatial interface. A window's spatial qualities (i.e. appearance, size, and position) simply cannot be a reliable way to identify a folder when any window can become a file browser at any time, and then transform back to a "normal" window, all without changing any of its spatial attributes!

What's worse, the Panther Finder, like the Jaguar Finder before it, will arbitrarily deposit state changes across folders as they are viewed and manipulated from within a browser-style window. The upshot is that, once a single browser-style window is brought into the mix, it is effectively impossible to predict the future state of Finder windows based solely on your actions.

There is an extensive article at macosxhints.com that attempts to explain the incredibly complex mechanisms that govern what any given Finder window will look like in the Jaguar Finder. The vast "truth table" of user inputs and resulting window states in the Panther Finder is subtly different than in Jaguar, but possibly even more complex. It's like some sort of sick game.

I doubt even the Mac OS X Finder development team would be willing to bet a month's salary that they can accurately predict what any given Finder window will look like the next time it is opened after an arbitrarily complex series of manipulations. The Mac OS X Finder is absolutely inscrutable.

I'm sure many readers will e-mail me and tell me that I'm wrong, and that they can always predict what a Finder window will look like in Mac OS X, Panther or otherwise. For a very limited set up actions, this is very nearly possible. But across the full range of functionally in the Finder, the house always wins. You will think you have it figured out, and then you will be surprised again.

This is because users are instinctively looking for a simple set of rules. But please look again at the policy and mechanism in the Jaguar Finder. Is that what you had in your head while using Jaguar? Can you even comfortably fit that set of rules in your head and call on it in a moment's notice to predict the state of Finder windows? (Never mind that there are many scenarios not covered at all by that article.)

Compare this to the classic Mac OS Finder, where there is no complex set of rules to be memorized, no strange mechanisms to understand, absolutely no "game" to be played at all. There is no 14,000 word treatise on the user actions that determine the subsequent state of windows in the classic Mac OS Finder. I doubt anyone even thought about the issue at all. Everything is always how you left it. What's to know?

I don't want to get bogged down in the details of any particular example (that's what the forums are for) but the central issue here is best summarized by the phrase, "What the heck did I just do?" (Feel free to substitute your own expletives.) If you don't know what your actions are actually doing, or, more importantly, where they are being applied, then a predictable system is impossible.

The classic Mac OS Finder didn't have a browser-style interface at all, a fact which further reveals the culprit in the Mac OS X Finder. What is a window in the Mac OS X Finder? Is it "a folder", in the simple, direct, classic Mac OS sense? Or is it "a device through which the contents of any folder can be viewed"? (i.e. a browser.) Well, it's both, and therein lies the problem.

Say you're using a metal browser-style window in the Panther Finder which is currently showing folder A. If you navigate to folder B and then change the view style (say, from list to icon view) what have you actually done? Have you changed the view style for folder A or folder B? Does it matter what view you used while you navigated to folder B, or which view you switched to or from? What about resizing a browser-style window? Which folder is that affecting, if any? What if you toggle the toolbar on and off as you navigate?

Where did this browser window come from anyway? How do you get a new browser window? The "New Finder Window..." menu item may or may not produce a metal window. If it doesn't, but just opens your home directory in a normal window instead, can you safely make it a metal window? Will that make your home directory a metal window every time you open it in the future? Does it even matter which folder you opened to get the initial browser window?

If you move a metal window, are you moving the window belonging to the folder that initially spawned the browser, the current folder, or none of the above? Or perhaps all of the above? Does it matter what folder you're viewing when you close the browser window? And what will all of the folders that you passed in your travels look like the next time you open them? Does it matter how you open them, whether by keyboard command, Dock click, title bar pop-up menu, keyboard shortcut, or double-click from within another window (and does it matter what type of window)? Where will these windows be on the screen? What view will they use? What size will they be?

And on and on...and this is without even considering situations where the same folder is open in multiple windows! Bottom line: if any window can be either a file browser or a folder, and if changes made in file browser windows have any effect on folder windows, then there is no Spatial Finder.

Now the inevitable reply is, "Fine, then just don't use the browser part of the Finder. Problem solved." That's not a solution for several reasons. As mentioned earlier, it's impossible to entirely banish browser-style windows from the Finder. Making a decision to avoid the browser is one thing, but being forced to do so manually as metal Finder windows inevitably and repeatedly appear before you is something else. But most importantly, why should the user be forced to forego all browser-style file management features? Browsers are useful! It is a fundamentally broken interface that asks the user to avoid half of its functionality in order to make the other half work in something approaching the correct manner.

The worst part of this whole mess is that the solution is so dead-simple! A window in the Finder must be one of two things:

1. The one and only direct incarnation of a specific folder.or ? important word!
2. A file browser that has no ties to any particular folder and has no effect on any folder's state.

That's it, just pick one! No magical transformations from one type of window to another. No confusion about what it is you're looking at or what you're actually doing. Put two menu items in the Finder, "New Folder..." and "New Browser...", and you're off to the races. (Selecting keyboard equivalents for those two commands is left as an exercise for the reader.)

Everything after that is details—making sure both kinds of windows are the best that they can be. But the Panther Finder doesn't do too well in that area either. I've already talked about the performance issues that span both kinds of windows. The browser-style functionality is no great shakes either. There's the new sidebar and a slightly different toolbar, but that's about it as far as significant browser-style features.

I don't know how many people are on the Finder development team, and I understand that they have to do a lot more than just create the user interface (i.e., threading, networking code, volume handling, disk image mounting, etc.), but I do find it puzzling that a single third-party developer can create a browser-style file manager with a feature list that puts the Panther Finder to shame. Say what you will about the wisdom of including so many features in a single application, Cocoatech's PathFinder unquestionably tops Apple's offering when it comes to sheer functionality. (I know some Mac users who would kill to have the sortable column-view feature alone, nevermind the huge pile of other features in PathFinder.)

Something is (still) very wrong with the Finder's development process.

Finder summary

The Mac OS X Finder is lost at sea. To borrow a line from Mr. Cube, the Finder's user interface designers either don't know, don't show, or don't care what's going on in the 'hood...or, at the very least, in my head. I would be more comfortable with this if the Finder team was aggressively pursing its own vision. But switching to a brushed metal appearance and adding a sidebar does not a vision make. The OS X Finder's user interface has made amazingly little progress in over three years of development, and the changes that have been made appear largely directionless. The Panther Finder is not a kick-ass file browser, and it certainly isn't any kind of Spatial Finder.

Despite the decade-old underlying implementation, it's nice to see labels finally make their return. The integration of network browsing was also long overdue. But the new browser-style features are prisoners of the flawed interface. I find myself wanting to use the live search capability, for example, but then not knowing where or how to "safely" get a browser-style window that I can manipulate without fear of hosing the state of my folders. Bleah.

Incremental performance improvements and feature additions make the Panther Finder better than its predecessor, but that is faint praise indeed.

Safari

Yes, Apple's Safari web browser has been around for a while now, but I have not had an opportunity to write about it. I'd like to do so now. I think Safari is one of Apple's greatest software success stories.

Let's look at what Apple has done with Safari. In less than a year, Apple has created what is arguably the best all-around web browser on any platform, and has done so in a way that allows it to interoperate with millions of web sites that are designed for severely broken Microsoft and Netscape browsers from the previous decade. But let's rewind.

I was a web standards snob in the '90s (okay, I still am), so I welcomed Internet Explorer 5 for the Mac, one of the first browsers to have extensive CSS1 support, with open arms. While Netscape languished, Mac IE5 just got better and better. I remained faithful to Mac IE5 over the years, following it across OSes from Mac OS 9 to Mac OS X. I'm a bit of a usability snob as well, so I stuck with IE5 even as newer, faster browsers were introduced, simply because I could not stomach their user interfaces. When Safari was introduced, I looked upon it with suspicion and not a little disdain.

First, Safari didn't even use Gecko, the speedy and capable layout engine behind the Mozilla web browser. As Mac IE5 aged, speed and standards support had become a sore point. How could Safari have either of those without Gecko? Safari used the KHTML layout engine from the Konqueror web browser which was created as part of the K Desktop Environment in Linux. I'd used Konqueror before and was not impressed.

Second, history had taught me that web browsers are not easy to create. It took Microsoft, a huge corporation with vast software development resources, years to catch up to the Netscape web browser, which itself had taken years to develop. The seemingly interminable Mozilla project had been trying for years to create a next-generation replacement for the aging Netscape browser with little to show for it but a strange cross-platform user interface framework and a very fast, standards-compliant rendering engine wedded to a user interface that only a mother (or developer) could love.

If the mighty Microsoft and legions of open source software developers (and a heck of a lot of Netscape employees, until that whole mess started to collapse) can't create a decent web browser without years of effort, how the heck does Apple expect to end up with anything acceptable with vastly fewer resources and even less time?

Well, here's how they did it (the short version).

A recipe for success

The first step is to hire the smartest people possible. Scoop up all those web browser wizards that Netscape/AOL/TimeWarner/Whatever is shedding. Apple has always been good at attracting the best people because Apple is cool. With the introduction of the Unix-based Mac OS X, Apple became cool to Unix geeks as well. A lot of experienced web browser developers are Unix geeks. Things are already looking up.

Next, stand on the shoulders of giants. That means don't try to write a new web browser from scratch if you don't have to. But also don't fall into the trap of getting buried under a vast foreign code base. That eliminates Gecko right away, despite its excellent performance and robust feature set. When your layout engine has its own generic array and string classes, it's a hint that you might be biting off more than you can chew.

Finally, do what you do best, whatever that may be. You have to add value. An also-ran web browser is as good as failure when the 800-pound gorilla of Internet Explorer is staring you down.

So Apple started out with a great development team and a small, manageable layout engine that was just ripe for improvements. And improve they did, molding KHTML into a near-equal of the mighty Gecko in both features and performance. The value-add came from the spit and polish of Mac OS X's native environment. Safari uses native controls everywhere (CSS purists be damned), and benefits from Mac OS X's excellent image- and text-rendering capabilities. Stir in just the right amount of Jobs-II-era interface simplicity, and you end up with the Best Mac Web Browser Evar.

But wait, there's more. Safari development has continued at a break-neck pace. Again, Netscape and Internet Explorer had conditioned me to expect significant web browser upgrades on a biannual basis, at best. At the other extreme, the incredibly active Mozilla project seemed to have new releases every week or so, very few of which could reasonably be called "stable." But the Safari team has been fixing bugs, adding features, and turning out solid, reliable releases on a comfortably regular basis.

Not only that, but the development process has been extremely open, thanks largely to Apple employee Dave Hyatt who has faithfully updated his weblog and engaged the community in an on-going discussion of all things Safari. When someone in the community finds and isolates an HTML or CSS rendering bug, Dave often has it fixed the next day (or, more likely, fixed it last week and it will be included in the next Safari release). If only all of Apple's developers were this available and responsive.

Before I cease my fawning, let me just list a few things that I love about Safari...and a few that I dislike, because I just gotta be me.

Safari's user interface is pleasingly minimal. The distance from the top of the window to the web page content area is much smaller than in most other browsers, even when all the extras are turned on. I have never used a "favorites bar" (Safari calls it the "bookmarks bar") in any other web browser because I just always thought it took up too much space. Safari's interface is slim enough that I don't notice the extra space, and now use the bookmarks bar as a near-replacement for my bookmarks menu.

Safari: svelte!

Also notice the combination stop/reload button, because why have two separate buttons for functions that are mutually exclusive? Clever. The tabs are also slim, and there's even room for an adjustable Google-powered search field (not pictured) next to the address bar.

Putting the back and forward buttons so close together that a one-pixel targeting error produces the opposite of the desired result is not such a hot idea, on the other hand. And no menu separators in the bookmarks menu? Come now, I'm pretty sure Netscape 1.0 had that feature. The unchangeable (without some effort) 60-second timeout is not very web-developer-friendly either. Dragable tabs and a properly customizable toolbar would also be nice.

But these are small details in the grand scheme of things. Safari gets the essentials right, and I found myself finally leaving IE (may it rest in peace, it served me well) for Safari despite my predictions to the contrary.

Although the Ars Technica Mac browser roundup article put Safari in first place with a rating of 8 out of 10, it went on to say this:

Do Mac OS X users have a "best of breed" web browser? Not yet. They all have their advantages and disadvantages.

As far as I'm concerned, the latter statement (which I agree with) does not necessarily imply the former. Safari is "best of breed" in my estimation. What it may lack in its ability to fully penetrate the bass-ackwards world of Windows-IE-specific web sites, it more than makes up for with its excellent, and rapidly evolving support for actual web standards and its elegant (if still a bit feature-thin) user interface.

It also proves that Apple is capable of neatly replacing formerly "essential" (usually Microsoft) software when it puts its mind to it. A web browser is not on the same scale as an office suite, but I'm starting to believe...

Xcode

Apple's developer tools have received a complete overhaul in Panther. They even have a new name: Xcode. It would take an entire article at least this size to cover every feature of Xcode, but suffice it to say that Xcode improves upon its predecessor in every conceivable way. Even the icon is better, now conforming to Apple's icon design guidelines and providing a larger click target than its predecessor.

If you want to hear about the most important new features in Xcode, head over to Apple's web site. While things like predictive compiling and code completion are new to Xcode, they are not new features in the world of integrated development environments.

The most important aspect of Xcode as far as I'm concerned is that it signals Apple's intention to do for itself what others either haven't done, or have not done in a way that meets Apple's standards. Put another way, Xcode is Apple's way of saying to Metrowerks, "Someday, we won't need you anymore." That may sound harsh, but developer tools are an essential part of any platform. It is clearly in Apple's best interest to ensure that it has the best tools possible. Making the tools themselves is the best way to do this.

In some ways, it is analogous to the situation with Safari and Internet Explorer. Microsoft has discontinued IE for the Mac (and for Windows, as a matter of fact, as a separate product). A web browser is an important part of the modern computing experience, so it was in Apple's best interest to ensure that it had a good web browser. Thus, Safari was born.

Or was it the other way around? Did Apple simply not think Mac IE was good enough and set off to create its own browser? Did Microsoft get wind of Apple's web browser development efforts and then decided to discontinue IE for the Mac? Only a few people know the truth about this series of events, and I am not one of them.

But as far as I'm concerned, it doesn't really matter which was the cause and which was the effect. The hard truth is that Apple is better off having its own web browser. It would be even better off with a Mac version of IE as well, but given the choice, Safari alone is better than IE alone. It's not wise to depend too heavily on outside sources for important parts of your core strategy...and even less wise to depend on your primary competitor.

So while it's better to have both Xcode and Metrowerks CodeWarrior on the Mac, Xcode is an essential hedge against the (possible) day when Metrowerks drops Mac support entirely. While Metrowerks claims that they are "fully committed" to the Mac, I'm sure Microsoft said the same thing when Mac IE5 was first introduced.

Despite all the improvements, Xcode is clearly a 1.0 release. Bugs and gaps in functionality exist, and the feature set is not quite a match for the mighty Visual Studio from Microsoft. But the overall feeling is that of an IDE that's off to a good start. I expect great things from Xcode in the future.

Open/Save Dialogs

The open/save dialog box in earlier versions of Mac OS X is inefficient, confusing, and generally not worth dwelling on because it is mercifully gone in Panther. Here is the new open/save dialog box.

The new open/save dialog box

The first thing you'll notice is the sidebar. Yes, this is the very same sidebar that appears in the Finder. I'm not among those who think open/save dialogs should be eliminated entirely in favor of some sort of direct manipulation using the existing file manager, but it is nice to see some small amount of convergence with the Finder.

There are back and forward buttons which are especially useful for returning from whence you came after jumping to folders with keyboard shortcuts. There is no persistent history for the back and forward buttons, however, which is a shame. The pop-up menu now blessedly shows the file hierarchy from the current location upwards instead of the seemingly arbitrary list of locations found in previous versions of Mac OS X. Recently visited locations are also in the pop-up menu, below the path hierarchy. A separate menu-button containing recent places would be a lot more convenient.

List view is now an option, as shown in the screenshot above. I always found column view to be much too confusing in open/save dialogs. They are usually not big enough to show more than two columns, and therefore only a single higher level in the hierarchy. Scrolling through columns is perhaps the least efficient way to get handle on the current location anyway (the pop-up menu is the right tool for that job). I also don't like the uncertainty about exactly where the focus is and where the file will be saved when more than one column is visible. Usually, it's the right-most column, but sometimes that column is empty. It's an opportunity for confusion with no real benefit. I now use list view in all my open/save dialog boxes, and Panther as been pretty good about remembering my preferences. The state of disclosure triangles in list view is not retained, unfortunately, nor is the selection.

Keyboard support is cruelly incomplete. I am accustomed to navigating open/save dialog boxes using only the keyboard—particularly open dialog boxes. For nearly two decades, I have typed the first few letters of a file folder name, hit return, and repeated until I got to the file or folder I was looking for. With my fingers on keyboard and my eyes on the screen (to confirm that my typed prefix got me where I wanted to go, using the arrow keys to adjust if it didn't), this was a very efficient technique. Perhaps not surprisingly, this does not work in Panther. Typing a prefix will jump the selection around in the list view in an open/save dialog box, but hitting return will not open the selected folder. Argh!

Odds and Ends

My battle for sane icon placement in the Finder continues. The grid spacing is still unadjustable by any means other than changing the font size, and is hugely wasteful at any setting. My kingdom for a slider!

The scope of the view options palette still sometimes defaults to "All Windows", which is not what you want 99.999% of the time. You must carefully study and then possibly adjust this setting every single time you adjust the view settings for a window, or risk repeatedly and unintentionally modifying the default view settings for Finder windows. That scope setting shouldn't even be in that palette. It is very rare to want to adjust the default view settings. Most users will want to do it only once. The view settings palette is called up because the user wants to change the view settings for a particular window, not "all" windows.

The Finder now asks for authentication when performing a file manipulation task that requires administrator privileges. This will save me many trips to the command-line.

The Finder now mounts disk images without launching a separate application. The features of Disk Copy, the former owner of this task, have been rolled into the new, comprehensive Disk Utility application.

The Finder can also create and expand zip archives. Resource forks and Mac-specific metadata are handled through the same "dot-underscore" files used to support these features on UFS disks. Inside a zip archive created by the Finder, the resource fork (if any) and Mac-specific metadata for a file named "MyFile" are both stored in a separate file named "._MyFile", which is then stored in a directory named "__MACOSX". When the Finder unzips such an archive, the process is reversed and the parts of the file are rejoined.

The Mac OS X metadata situation has not improved. If Apple is working on a grand new vision for filesystem metadata, it is not present in Panther. The result of the three-year wait for Finder labels does not set a good precedent in this area, but I am still cautiously optimistic, if only because the issue is quickly become much too large to ignore. Microsoft is finally making its move in this area, and must be quite smug about Apple's decision to regress its metadata capabilities with Mac OS X. Apple's development of the Mac OS X metadata system has gotten it to a place that Microsoft has been working for years to get away from. Wake up, Apple.

Many utility applications have been updated. In particular, the new Activity Monitor and Console applications are greatly expanded. Activity Monitor now measures nearly every remotely interesting aspect of the system: CPU usage, running processes, disk activity, memory usage, network traffic, etc. Both current and historical values are shown in a collection of small graphs and floating windows. You can inspect individual processes and list their open files, memory statistics, and even esoteric information like the number of context switches, mach messaging calls, and page faults. it is impressive. The Console application now provides access to nearly every log file in the system. It even reads the gzipped archives of old logs, and provides live searching. It's nice to see these less flashy applications also receiving substantial upgrades.

Panther includes an application for managing fonts: Font Book. It provides more than enough features for the average user to manage his fonts, but professional designers may still want more. Fonts can now be installed by simply double-clicking them in the Finder.

Have you noticed how Mac OS X reviews rarely talk about stability anymore? That is as it should be. The stability of the OS is almost a nonissue at this point. Application stability is still somewhat suspect, especially (you guessed it) in the Finder, which crashes for me at least a few times a week. I had about five kernel panics in Jaguar across three Macs in over a year of use. I have not yet had a kernel panic in Panther. (I also have not logged out, or even quit any applications, since I started writing this article weeks ago. Let's hear it for Fast User Switching!)

Panther includes the ability to encrypt your entire home directory. I am much too scared to try this feature, and from what I have read on the web, my caution is well-founded. It sounds like a useful feature for certain types of users, but I am more than happy to let others work out the bugs before I try it.

The Keyboard preference pane now includes the ability to assign keyboard shortcuts to any menu item in any application. The first thing I tried to do is assign command-n to the Finder's "New Folder" menu item, as God intended. But I was thwarted again by Mac OS X's apparent knowledge of my secret desires and bottomless urge to thwart them. My system refuses to let me set single-letter keyboard shortcuts like command-n using this preference pane, although others have reported success.

Conclusion

After rereading the conclusion of my Jaguar review, I'm tempted to simply copy and paste it here, substitute "Panther" for "Jaguar", and bump the version numbers by a tenth. That's not to say that Apple hasn't made progress with Panther, only that the overall improvement is somewhat comparable to that made in Jaguar.

This is nothing to be ashamed of, but the other side of the coin is that many of the year-old complaints also still apply: unpolished corners of the user interface, the Finder, the metadata situation, and even user interface responsiveness (to some degree) are all still issues in Panther. But I do think the overall rate of improvement is accelerating; it's just not distributed quite the way I would like. As with Jaguar, many problems can be overcome or avoided with the help of third party software.

For me, Fast User Switching, Exposé, the Unix changes, and the comprehensive performance improvements make Panther a more significant OS update than Jaguar. Like Jaguar before it, it is nearly impossible to recommend against upgrading to Panther. Mac OS X's development process is a train that's leaving the station with or without you. The message to users is clear: "Get onboard."

In the introduction I pondered the consequences of this juggernaut, with its annual $129 price tag and all the potential problems associated with the OS upgrade process. But if there's going to be any consumer backlash, it's not going to start with me. I think Panther is worth the cost, but I consider its price to be an investment in the future of Mac OS X--something I obviously have strong opinions about. I'm probably not a typical user, however. If Apple wants to help ease the burden of the larger Mac community, decent upgrade pricing would be a good start. With a yearly release schedule, that is nearly the same thing as a simple price reduction, but if so, so be it.

If you use Mac OS X every day, you owe it to yourself to upgrade to Panther. And as always, if you care about the future of the Mac platform, you owe it to your fellow Mac users to let Apple know what you think of its latest offering. If you're more technically inclined, please don't forget to file bugs. Apple can't fix what they don't know is broken.