Every view plug-in should take advantage of file system metadata. The canonical example is the folder full of MP3 files using list view, with columns for title, artist, length, and so on. This does not mean that the list-view plug-in has to know anything about MP3 files or ID3 tags, however. (It's up to another part of the OS to parse ID3 tags and write the information to the file system metadata structures, but that's another article.) The list view plug-in would simply allow the creation of columns for any piece of metadata.
And so on for each view plug-in: any piece of metadata should be able to participate in a view. But this is just the tip of the iceberg. The real payoff comes when the Finder Browser starts to leverage file system metadata for the purpose of searching for and organizing files and folders. The evocative phrase is this: iTunes for files.
Most people who have used iTunes have, at some point, wished that files could be found and organized as efficiently as the MP3 files managed by iTunes. Of course, part of what makes iTunes so efficient is its very narrow problem domain: music files. It makes little sense to try to come up with a fixed set of generic equivalents to the "Artist", "Album", and "Song" domains represented by the three panes of the iTunes song browser (although that hasn't stopped people from trying). But another aspect of the iTunes user experience can be adapted to the Finder Browser: the speed and ease of searching and categorization.
The first step is a toolbar plug-in for a simple search field. This search field should behave more like the iTunes search field than the one in the current Mac OS X Finder. The search results should update in real-time as you type, just like they do in iTunes. Furthermore, the default scope of the search should include more than just file and folder names. Just as iTunes will search across album and artist as well as song title, the simple search field in the Finder toolbar would consider labels, file types, and other relevant piece of metadata in addition to file and folder names. And like the toolbar search field in Apple's Mail application, the scope would be adjustable via a pop-up menu.
The next step is a file-based equivalent of the "smart playlists" found in iTunes. Put another way, this is the equivalent of live search folders for the Finder Browser: "live queries." (The idea is to make sure that every feature possible exists in both the spatial and browser parts of the Finder.) Instead of individual folders, each query would be represented by a line-item in a slide-out drawer. Dragging a live search folder into the "live queries" drawer would create an equivalent query, and vice versa. And of course, each saved browser has its own independent collection of queries.
Finally, although a fixed set of generic equivalents of the "Artist", "Album", and "Song" panes from iTunes is too confining, the user should be allowed to create an arbitrary number of panes corresponding the metadata elements of his choice.
A suitably configured Finder Browser was compared to iPhoto earlier. With the addition of the features above, plus a few more toolbar plug-ins, the Finder now has the ability to replace much of the song organization and playback abilities of iTunes. Again, I am not suggesting that the Finder should replace iTunes, I'm just trying to show the possibilities. And remember that everything the Finder seems to get "for free" from the underlying OS facilities will also benefit iTunes, iPhoto, and friends. A well designed infrastructure is a rising tide that lifts all boats.
Up to this point, as some readers have undoubtedly noticed, I've avoided providing any mock-up screenshots of the proposed new Finder. In fact, I debated including any at all. Screenshots are exciting and can do a good job of selling an idea, but screenshots also have the unfortunate side-effect of collapsing a concept into a single, particular implementation. Furthermore, since I'm not actually implementing this new Finder, any mock-ups I create will be "cold" in that no one, not even me, has ever used the interface they show. It is therefore unavoidable that the screenshots would include implementation details that readers would judge as unworkable or poorly designed. And they would likely be correct. Real implementation and testing is the only way to work out the kinks of any new piece of software.
I do have tremendous faith in the utility and usability benefits of the basic concepts that underly the proposed new Finder. I think all of the ideas in this article can be implemented successfully, given proper testing and refinement, and I think the resulting Finder would be extremely powerful, very popular, and as much beloved as its classic Mac OS predecessor.
As for the screenshots, I've decided to include only a handful. Creating a mock-up for every single proposed feature would take a very long time, and more Photoshop skills than I possess. Instead, the mock-ups I've created provide only a taste of what the new Finder could be. I encourage anyone inspired by the ideas in this article, or ideas of their own, to send me any mock-ups they've created of a possible new Finder. (Please send web page URLs rather than email attachments, if possible.) Depending on the volume and quality of the submissions, I may add the best mock-ups to the end of this article, along with my comments.
One more brief disclaimer: as you view the small collection of mock-ups, try to focus on the ideas rather than the details. To encourage this, I used bits and pieces from other applications to construct the screenshots. Nothing sticks out more than a poorly drawn widget, and there would be plenty of those if I chose to draw them all myself. Also note that the Finder Browser will be shown as a brushed metal application. This does not necessarily mean that it should be implemented as such, but brushed metal is the most "visually distinct" existing interface style available for me to steal from. I also hope it will evoke good feelings through association with iTunes (if not, perhaps, the still-sluggish iPhoto). Your mileage may vary. Let's dig in...
