About the Finder...

The Finder Browser should have a proper NeXT-style shelf, if for no other reason than it's simple to implement and will be invisible to users who are not interested in using it. A shelf is simply a region for storing proxy icons. Dragging an item to the shelf creates a proxy icon for that item, but the item itself does not move. If the proxy icon is dragged off the shelf, then the item will be moved to the new location. In other words, the proxy icons work the same way as proxy icons in live search folders (with the difference is that items can be dragged onto a shelf, whereas items may not be dragged into live search folders).

A shelf could take many forms, but the most obvious is simply a region of a browser window's toolbar. Another option is a drawer that slides out from one edge of a Finder Browser window. Finally, the Finder should also support a "global" free-floating shelf that can be positioned anywhere or docked to a screen edge.

Speaking of the Dock, the shelf may sound a lot like it. But remember that items dragged off the Dock disappear in a puff of smoke, whereas items dragged off the shelf actually move to the new location. (To remove an item from a shelf, use the "remove" choice in the item's context menu: click-and-hold or right-click.) Also note that multiple items may be dragged to the shelf where they will be represented as a single "proxy collection" icon, whereas multiple items in the Dock each get their own icons.

Readers who have not used a NeXT-style shelf before may be wondering why this feature is useful. The short (albeit wordy) answer is that the shelf provides a direct GUI facility for two-step delayed move and copy operations. The long answer follows.

In order to move or copy a file to a new location in the Finder (spatial or otherwise), it is usually necessary to first make both the source and the destination visible. Spring-loaded folders alleviate this need somewhat, but the coordination and mental facilities required to successfully drill down (or up!) to a distant destination from an arbitrary position in the file hierarchy make this feature somewhat inconvenient, and often confusing.

The shelf provides a "rest stop" in this process. The item to be moved or copied is first dragged to the shelf. Yes, this means that both the source and the shelf must be accessible, but this will very likely be the case if a global shelf is in use (which would float above Finder windows) or if a browser window is on the screen. The user is then free to navigate to the destination using any desired means. There is none of the "pressure" (both literal and figurative) of the continuous drag operation required by spring-loaded folders.

Furthermore, as astute readers have already figured out, the shelf eliminates any need for the perversion of interface metaphors that is the use of copy and paste for files. The "Edit -> Copy File" command now becomes "File -> Place on Shelf", and the "Edit -> Paste File" command now splits into two commands, "File -> Copy from Shelf" and "File -> Move from Shelf", making it more powerful that copy/paste (since "cut" is not an option) in addition to being more sane and consistent with the rest of the UI. These commands would also have visual feedback. There would be some form of animation as items travel to and from the shelf at the behest of these commands. And unlike copy/paste, items would remain on the shelf even if another item was moved to the shelf. It would behave like a stack in this regard. Finally, to avoid confusion, these commands would always operate on the "global" shelf, rather than a shelf attached to a Finder Browser window.

Traditionally, browser-style windows are all identical. There is nothing to distinguish one web browser window from another, for example. Oh, sure, web browsers try to remember an initial window position, and perhaps some sort of tiling preference for subsequent windows. But in general, browser windows are not easily identified and remembered based on spatial cues. This is not an optimal situation, of course. And we can change it.

The first step is to allow Finder Browser windows to be saved in the form of files. Think of these files as documents owned by the Finder, just as TextEdit owns text files. Double-clicking one of these "saved browsers" would re-open the saved Finder Browser window, restoring it to the exact state it was in when it was saved. That state includes window position and size, scroll position, view style, toolbar items and visibility, shelf contents, and so on.

What this means is that changes to a particular Finder Browser window are not automatically propagated to all other browser windows. This is unlike the existing Mac OS X Finder, in which changes to any Finder toolbar affect every other Finder toolbar, for example. Instead, each Finder Browser behaves more like a document, but with optional auto-save turned on for browsers that have already been saved to disk. There would also be an option to make the default state of new browser windows match the state of a given browser.

Finally, a browser may be designated as the "default browser" for a particular folder. From that point on, any time a browser window is opened in that folder (via a "New Browser Here" context menu or menu item, for example), the previously saved browser will be used.

All of this is meant to allow the user to create familiar environments tailored to specific tasks. When all browser windows are identical, the result is a mediocre browser that is a jack of all trades but a master of none. For example, there isn't enough room on a toolbar for every application that the user might need to drag a file to, so it ends up being populated with only the most prominent in each category.

When browser are independent and can be saved for later use, the user is encouraged to extensively customize each browser for a given task. A browser focused on photography could fill its toolbar with image editing applications, for example, and its shelf could contain the last few photos that were edited. Combined with the ability to tie saved browsers to particular folders, a user no longer has to drag a generic browsing environment along with him as he navigates the file system. Instead, his preferred environment for any subset of the file system springs into life in response to his navigation.

Think of it as "spatial browsing." In the same way that it is efficient and comforting to see the same folders in the same locations with the same state day after day, users will also benefit from browser windows that are similarly easy to recognize, remember, and customize. This ability can be taken even further with the addition of the next feature...

The view style system of the Finder should be built on a plug-in architecture. This is also an idea from Apple's past, but since I can't recall the exact source (it might be Copland, but it could also be Rhapsody), feel free to pretend that I came up with the idea on my own.

Each view style is driven by a plug-in module: icon view, list view, etc. Plug-ins may work in folders, browser windows, or both. It is up to the plug-in developer (and the user) to maintain the integrity of the Spatial Finder by not using, say, a column-view plug-in that works in regular folders (the default column-view plug-in would not). But this is not really a big concern, since anyone who likes column view will certainly want to use it in a full-fledged browser window rather than in a (comparatively anemic) plain old folder.

As promised, combining view plug-ins with spatial browsing really pays off. Imagine if a photography-oriented saved browser also used a plug-in view that displays thumbnails in the same way that iPhoto does, for example.

The Finder Browser's toolbar should also support plug-ins. (Although I hope this goes without saying, all of these plug-in APIs should be open to third party developers.) The default set of plug-ins would include toolbar items such as the back/forward/stop buttons, the address bar, and so on, as well as independent toolbar-like appendages like the shelf. At this point, I think at least a few Windows XP users see where I'm going with this, so I'll cut to the case.

Using Finder view and toolbar plug-ins, and recalling the presupposed OS-level support for powerful, high-performance, arbitrarily extensible metadata, it's only a small stretch to create a saved Finder Browser window that is, essentially, iPhoto.

Now I'm not suggesting that the Finder Browser should be a replacement for iPhoto, since a dedicated application will always be better able perform a given task (which is why the Finder has its own browser, as you'll recall). I'm trying to show just how much can be accomplished by a modular Finder if a robust metadata storage system is taken for granted. If you think about it, "metadata storage and retrieval" is about half of the functionality of both iPhoto and iTunes. Moving this ability from individual applications (each of which must currently roll its own custom solution) into the OS itself is extremely useful and empowering. It's a win-win situation: iTunes and iPhoto get slimmer, and the Finder becomes much more powerful.