Continuing my thoughts on Interface Cruft (sparked by
this paper by Matthew Thomas), this is a quick post about one of the things that "Mac OS X" gets right (or at least - more right than others ";->").
"Mac OS X" is more of a system of compromises than it is a new operating system, due to
the challenges of integrating the Unix and Mac OS environments, and due to compromises the NeXT team took to try to make NeXTStep friendly to certain environments (by building on Unix) while putting a nice Object Oriented shell on top of it.
The most interesting piece that has been used from NeXTStep 1.0 up to Mac OS X 10.2 is the use of
Packages on the file system. These are objects on the file system that appear as a single item to the higher level operating environment, while they are actually file system directories that are full of smaller objects. The most common examples of this are applications. In Mac OS X's finder, bring up a contextual menu on an Application (especially well written Cocoa applications like
OmniOutliner or
NetNewsWire Lite) and select "Show Package Contents". A new Finder window will show up, most likely with a single folder titled "Contents". Inside there will be executables (with the ability to hold executables for multiple platforms) and resources (icons,
Interface Builder documents) at the very least. But the package can also contain
Help Files, PlugIns (which can be managed via the "Show Info" command in the Finder), other frameworks, scripts, and even other applications (OmniOutliner has "OmniGroupCrashCatcher", an application for reporting crashes to the Omni Group).
Essentially, it's a way of doing what the traditional Mac OS did with its resource fork in a manner that's friendlier to traditional file system expectations. It can also be viewed as a way of
Object Encapsulation. There's one very clear advantage: since most Mac OS X applications are self contained, they can be freely moved around, shared, whatever. I can use iChat to send a friend a copy of NetNewsWire Lite by just going to the Applications folder, and dragging and dropping the application into the iChat window. Contrast this with Windows, the Linux desktop environments, and the classic Mac OS. The last time I downloaded
Mozilla for Mac OS 9, the folder that Mozilla unstuffed to was filled with folders and odd little Mozilla support items, and the Mozilla application was just another icon in the middle of the mess. On Mac OS X, all of that is contained within the executable Mozilla package. If you open up the package contents of
Chimera and drill down to the "Contents/MacOS" folder, you'll see all of the Chrome, Components, and Plugins folders. But instead of cluttering up the Finder, it's all contained cleanly within the Chimera package.
This also means that you can (optionally) put the local Applications folder onto the Dock, and have rapid access to
all applications, similar to the Applications sub-menu off of the Windows
Start Menu. Unlike the Windows start menu, which is essentially the old
Program Manager from Windows 3.x, the items in the Applications Menu are the real deal, not some pointer to an executable buried in the messy
Program Files directory. This also means that - with a few exceptions - removing an Application is simply a drag to the trash. The few exceptions are applications that are installed which also extend the system (things like iSync, or even iTunes which comes with device drivers). Writing about the Windows start menu, Matthew Thomas writes:
And naturally, rearranging items in this menu is a little bit less obvious than moving around the programs themselves. So, in Windows 98 and later, Microsoft lets you drag and drop items in the menu itself — thereby again breaking the general guideline about being able to cancel a click action by dragging away from it.This Programs menu is the ultimate in cruft. It is an entire system for categorizing programs, on top of a Windows filesystem hierarchy which theoretically exists for exactly the same purpose. Gnome and KDE, on top of a Unix filesystem hierarchy which is even more obtuse than that of Windows, naturally copy this cruft with great enthusiasm.
So, while "Mac OS X" has made a lot of compromises in order to be friendly with long-running expectations of a user interface, and to be friendly with Unix expectations of file system layout, it does do a lot of things right. There are plenty of sore spots (including interface irregularities between different Apple produced
iApps), but there is a pleasant clean feeling to it all. Generally, there are few alarms and few surprises. As "Mac OS X" continues to grow, I imagine that the situation will improve. And, for all of its cruft, the future of Windows has some interesting developments as well.
My next post on this subject will deal with some individual applications on Mac OS X that are taking the right steps away from interface cruft.