Mac OS X 10.4 Tiger

Apple's latest OS X release (10.4) is about to hit the streets. Tiger brings a …

The Finder (not really) revisited

Earlier, in the metadata section of this article (it seems so long ago, I know), I wrote about leaving the topic of metadata behind as Mac OS X's metadata features stagnated. At a certain point, everything that can be said has been said, and all that's left is hope, however dim.

With the introduction of Tiger, the Mac OS X Finder has entered this stage of its existence. The Tiger Finder does not include any significant new interface features beyond those added in service of Spotlight, and as we've seen, even those suffer from the now-expected Finder malaise.

Over the years, the Mac OS X Finder has gained a well-deserved reputation as the least pleasing bundled Mac OS X application. It has been called the most widely used piece of abandonware on the Mac platform. While some people like it, few love it, and many hate it.

In the Macintoshian Achaia forum here at Ars, the abbreviation "FTFF" is now used without explanation. It stands for "Fix the F***ing Finder," and it shows up often in Mac OS X wish-list threads. (And if you think my long-running criticism of the Finder makes any Ars forum opinions inherently biased, you don't know the Mac Ach.)

To a casual observer, this might appear a bit extreme. The Mac OS X Finder seems, if not glamorous, then at least benign. What's the big deal? The bad feelings about the Finder don't spring from a single source. There are at least three distinct threads of Finder dissatisfaction, usually appearing in combinations of two or more in any given Finder malcontent.

First, there's the whole spatial/browser issue which I covered extensively in my Panther review. I also wrote an entire article on to the topic. I'm not going to revisit the issue here. Suffice it to say that what I wrote about the Panther Finder in 2003 is just as applicable to the Tiger Finder today.

The second issue is performance. The classic Mac OS Finder was no great shakes when it came to remaining responsive under heavy load or during network activity, but standards were different back then. In the Mac OS X age, the expectations are much higher. Sadly, the Mac OS X Finder has seemed stuck in an earlier era since day one.

While applications like Motion can composite multiple video streams in real time, the Mac OS X Finder UI still chokes when dragging a large number of files from one place to another. Network access remains a notorious cause for application-wide "pauses" (the infamous spinning beachball cursor). Mac web forums are haunted by nightmarish tales of total Finder paralysis in response to accidentally clicking on a QuickTime movie on a networked volume in a column-view window, causing the "helpful" movie preview to be displayed. And iDisk, don't even get me started about iDisk, the poster child for inexplicable slowness. While third party WebDAV clients read and write files on .Mac iDisks just fine, the Finder seems to revel in long pauses and glacial data transfer rates.

Finder performance has improved steadily since Mac OS X 10.0, sometimes dramatically so. But going from "unusable" to merely "frustratingly slow" is not a point of pride. It's not so much the actual magnitude of the problems. Okay, sometimes it is. But mostly it's that the Finder suffers so much in comparison to its contemporary applications.

That leads to the final pillar of Mac OS X Finder dissatisfaction. It's the little things. Little annoyances are easy to forgive in a version 1.0 product, and this is a valid label for original Mac OS X Finder. But when these little annoyances persist over four years of development despite the relative trivialness of their solutions, people start to get pissed off.

There are too many examples to list, although that doesn't stop people from trying in the seemingly eternal forum threads on the topic. I'll just pick three from my personal experience.

The first is icon grid spacing. The Mac OS X Finder has had a very widely spaced icon grid from the start. While this does ensure that very long file and folder names cannot overlap, many users (especially those with small screens) consider it wasteful when dealing with the more common case of reasonable file name lengths.

Some sort of adjustment for icon grid spacing has been requested since Mac OS X 10.0, and yet it remains unimplemented. This issue is exacerbated by the fact that the classic Mac OS Finder had a simple grid spacing adjustment over a decade ago. (We have the technology! We can rebuild it!)

Next there's the "View Options" palette. It contains a pair of radio buttons that control the scope of the changes made in the palette. There's one radio button for "All windows" and one for "This window only." (Let's ignore for now that the concept of actually changing the view options for "all windows" in the Mac OS X Finder is a cruel joke.) When a user brings up this palette, he does so because he wants to change the view options for the window he's looking at. Maybe once in several thousand uses he also wants to try to make his changes apply to "all windows" in the Finder (whatever that means). But 99.9% of the time, he simply wants to change the view options for a single window.

Infuriatingly, the "All windows" radio button is selected by default most of the time. (Good luck divining what set of conditions determine which radio button is selected by default.) What this means in practice is that virtually every single time a user changes view options for a window, he must first (remember to) change the radio button selection. This gets very old, very quickly, let me tell you.

Finally, there's the "size to fit" behavior of Finder windows, triggered by clicking the green "+" widget in the window titlebar. In theory (and in practice in all versions of the classic Mac OS Finder with this feature), this should cause the Finder window to resize itself in order to show as many items in the window as possible, but without any extra space around them. For a Finder window with just a handful of closely-spaced icons in it, this should produce a window with no active scrollbars.

In the Mac OS X Finder, this feature has never worked consistently. When it doesn't work, there's usually one active scrollbar with about 5 pixels of travel in it. The Finder tries to size the window appropriately, but fails to correctly judge the bounds of the icons it contains. This is not rocket science...

In isolation, these all sound like nits being unnecessarily picked. "Boo hoo, your pet bug didn't get fixed." But the cumulative weight of everyone's nits can't be ignored. Complaints tend to cluster around 10-20 problems that plague a large number of people. So it's not a matter of every person having a different complaint, leaving Apple with no good way to prioritize them.

And speaking of prioritizing bugs, it's not as if these little things have been slipping through the cracks because Apple has been busy adding big new features to the Finder in every major release. Instead, the Finder remains essentially unchanged from release to release (excepting perhaps the integration of whatever new Mac OS X feature actually did get attention this time around) and the little things don't get fixed. Remember, this is over four years of development.

Even the little good will that the Mac OS X Finder did initially garner, thanks to its incorporation of the NeXT-style column view and assorted other browser-style features, has been evaporating in recent years. The honeymoon is ending for browser fans. Increasingly, they're coming to the realization that their browser-related features requests are being ignored too.

I also see a lot of complaints about the how the non-browser features of the Finder interfere with pure file browsing. ("Why can't I force all my browser windows to use list view by default?") Suddenly, all the past hubbub over the destructive browser/spatial mix in the Finder starts to make a lot more sense.

Even more painful for browser fans is the existence of an application like Path Finder. Path Finder is a browser-style file manager developed by a single person that absolutely embarrasses the Mac OS X Finder with its huge feature set. Version 1.0 of Path Finder shipped in 2001 after only 6 months of development. Today's version 3 is miles ahead of that, and the upcoming version 4 is like the Final Cut Pro of file management. It's a file browsing tour de force.

The Mac OS X Finder, Tiger's included, is none of these things, and it's a shame.

The Spotlight factor

Spotlight has been the great white hope for Mac OS X file management. At Apple's 2004 Worldwide Developers Conference, Steve Jobs himself opined that Spotlight has the potential to actually replace the Finder. "A lot of us are never going to use the Finder again," he said. "We're just going to go right here [to Spotlight] to find anything."

I don't want to minimize the value of a fast, powerful, accurate system-wide search facility. It really is a wonderful thing to have, and it handles tasks that the Finder is totally unsuited for. But it is what it is: search.

Replacing all file management tasks with search is simply self-flagellation. Search is great when you want to find a needle in a haystack, but it's unnecessarily inefficient when dealing with a small number of frequently used files. This is why folders exist: to collect sets of files related in ways that have nothing to do with their contents.

Spotlight's smart folders could help here if Apple better leveraged Tiger's new extended attribute features to allow the addition (and indexing) of arbitrary metadata. But as things stand, the task falls to plain old folders.

Given a "working set" of frequently used files, it's extremely efficient to put them all in an open folder window (maybe in list view with certain subfolders disclosed) and double-click or drag and drop the files in order to open or edit them. The search-based alternative to this straight-forward Finder interaction requires activating the Spotlight search menu, typing the first few characters of a file name, selecting the file from the search results menu (or activating the full search results window if it's not in the menu), then selecting, double-clicking, or dragging the file in order to open or edit it.

This all assumes that the file's metadata is unique enough to make it easily distinguishable in the results list, of course. Pity the poor web developer trying to use Spotlight to edit a series of identically-named and similarly structured "index.html" files, for example.

Remember that this whole process has to be run through from start to finish each time a file is opened. And unlike special-purpose "launcher" utilities like Quicksilver, Spotlight will not "learn" based on your actions. In fact, it won't retain any state at all beyond, perhaps, the last search string entered. Each search essentially starts from zero.

If this still sounds like a good way to work with your personal "working set" of files, I challenge you to try it for a month and see how it feels. Don't use the Finder at all; try to do everything through Spotlight. Who knows? Maybe your "working set" really is a random distribution of all the files on your hard drive. If that's the case, then Spotlight will be like manna from heaven.

But if you're like most users, repeatedly "searching" for files you have opened five times already today—files that are likely collected in a handful of folders—will slowly drive you mad. This is doubly true if you are a developer working in an environment where file names are frequently identical or where the hierarchy is part of the product (e.g., a web site or a Perl module distribution).

Again, I don't want to marginalize the power of search. Search is great; search is important. When you're looking for that one obscure file you just know is on your hard disk somewhere, or even just looking for a word or phrase you think you saw once, Spotlight kicks ass. But a replacement for the Finder it is not.

In Mac OS X, the increased use of search is kind of a self-fulfilling prophecy. The more the Finder sucks, the better Spotlight looks in comparison. But no matter how bad the Finder has gotten, there's one feature that has persevered: the desktop. As the most spatially consistent part of the Finder, it's the one "location" in the computer that virtually every user feels comfortable with—which is why so many people use it to store their most important or frequently used files (much to the chagrin of computer neatniks everywhere).

Applications like iTunes and Mail have already demonstrated the power of a proper mix of search and traditional, structured information management. The search field in iTunes is great, but iTunes would be a lot more frustrating to use without the hierarchy provided by the the genre, artist, and album browser panes. The same goes for Mail with its fast search field in addition to traditional mail folders.

In both cases, the hierarchy is really just a set of canned searches. That's also (effectively) the case on volume formats like HFS+ where the file path is just one possible unique identifier for a file. Plain old folders are really just "canned searches" based on file path metadata. The resulting interface is the important part, not the mechanism.

I hope that the combination of the Finder and Spotlight can some day live up to its potential. In the meantime, it's a mistake to overemphasize the utility of Spotlight as a means to cover up for the Finder's shortcomings. Spotlight is great, but it doesn't entirely eliminate the need for traditional file management. The Finder's not off the hook.

Internal changes

There are some internal changes to the Tiger Finder that are worth mentioning. The first is the modularization of the Finder's "copy engine." Applications other than the Finder often want to move or copy files. This is a surprisingly complex task, especially in Mac OS X with its Mac-specific metadata, resource forks, symbolic links, hard links, and complex rules for the emulation of all of these features on volume formats that don't support them.

The classic Mac OS solution was for applications to simply ask the Finder to move or copy files on their behalf. This worked, but it made all of these applications dependent on the Finder. During the introduction of Mac OS X, a lot was made of the fact that the Finder was now "just another application." This was partly a reference to classic Mac OS applications' historic reliance on the Finder for file management tasks. Mac OS X was to be different. Applications could no longer simply assume that the Finder was always running and available. If a Mac OS X application wanted move or copy files, it'd have to do it on its own.

In Tiger, Apple has put the Finder's file copy engine into a public library that any application can use. The Tiger Finder itself actually uses this library. This unification of "correct" file operations into a single library is an important step, especially with the potential proliferation of file metadata in the years ahead.

The other notable change to the Finder comes thanks to a combination of file system notification APIs introduced in Panther (but not leveraged by the Finder at that time) and the features added on as part of Spotlight. The Tiger Finder now correctly shows files when they are created and makes them disappear when they are deleted.

If this doesn't sound like a big deal to you, then you probably haven't used the Mac OS X Finder very much. Or maybe you simply have low expectations for your file manager. (A Windows user perhaps? F5!) But you know how crazy we "graybeards" are, always doggedly holding onto the quaint notion that the file manager should actually reflect the state of files on disk in something approaching a timely manner.

The Mac OS X Finder has historically failed miserably in this area, usually refusing to show files created outside the Finder until the user explicitly clicks in the window. In theory, applications are supposed to notify the Finder when they create files. In practice, many don't—and many can't, like Unix command-line tools that have absolutely no knowledge of the higher-level APIs in Mac OS X, let alone the Finder.

Well, those days are over. Thanks to the kernel hooks that make Spotlight so magically responsive, the Tiger Finder can no longer be surprised. It reflects file system changes instantly, regardless of their source. Behold!

I firmly believe that this change alone will save me more aggravation than all of Tiger's other improvements combined. If a Mac OS X kernel developer walked by me right now, I'd give him a big hug.

Finder summary

I know I said earlier that I was leaving the Mac OS X Finder quagmire behind due to the application's stagnation and my past exhaustion of the topic. Rest assured, what you just read was the short version. But I did want to try to explain why the issue refuses to die completely. The dissatisfaction with the Mac OS X Finder is real, and it doesn't show signs of going away any time soon.

I covered the slightly disappointing implementation of smart folders and the wacky Spotlight integration earlier, but it bears repeating: seemingly anything that comes in contact with the long-neglected Finder ends up, at best, wallowing in mediocrity.

I haven't given up on the Finder entirely. If the Mac OS X metadata saga has taught me anything, it's that vigilance at least has the possibility of paying off in some small way. I just wonder how many more years I'll have to wait before the Mac OS X Finder finally bubbles up the priority list at Apple.

Despite all of this, the Tiger Finder is better than its predecessors. Its newfound awareness of file system changes alone is worth the price of the upgrade. Just try not to think about what might have been.

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