Arc v' November 11, 2002

One response to the "When Interfaces Go Crufty" article is this one by John Gruber. Some of Johns responses are in the same area as mine, so I'll quote liberally.

First, Matthew Thomas writes:

We have the power, in today's computers, to pick a sensible name for a document, and to save it to a person's desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.

And Mr. Gruber responds (after mentioning dislike for automatic behavior in applications):

Even if you don't default to the actual desktop, there's no other default folder location that would be suitable for all new files. I don't save my Perl scripts to the same folder as my grocery list. Nor do I want applications choosing file names for me. If you don't choose the names for your own files, how do you identify them when you try to reopen them later on?

Since reading Mr. Thomas's article, I've examined my own behavior and application usage more closely. And I'm somewhere in the middle of the two viewpoints. And it's not just because I'm a developer and have Python classes that I definitely want to keep separate from my Quicken files, but because there really is room for both.

1. Applications like personal information managers (at least, Palm Desktop, Microsoft Entourage, and Apple's iCal and Address Book) and personal finance managers like Quicken are all auto-saving applications. In the case of the above mentioned PIM's, one rarely deals with the actual data files. iCal, Address Book, and Entrourage all keep their data off in their own hidden database. You can export data, but you never really open your "Entourage Calendar" - you open the application. Even Quicken (at least on the Mac configurations I've used over the past few years) is this way. I know where my Quicken file is located, but I always launch Quicken itself, and all of my data shows up. Granted, these are all essentially single-document applications (you're always working with the same data set) and curiously enough, tie in to handhelds very directly. And in almost all handhelds, from the Newton to the Palm (and I assume Pocket PC), there's no manual "Save" action for the majority of data managed in them - you turn them on and just start scribbling/typing.
2. As I've said before, OpenDoc offered an interesting solution. For most OpenDoc documents, you started from the file system by opening a piece of "stationary". It's similar to the starting templates in Office and AppleWorks, but at the file system / operating environment level. Opening a stationary document would fire up an OpenDoc shell and place you in an editor for the default document part, and at first save, you'd have to enter a name/place for the document. Windows has the "New" (or is it 'Create'?) file/contextual menu in the Explorer from which you can make not only new folders, but at least some pieces of content. So you could go to "proposals", bring up the "New -> WP Document" (shrug) menu item, and be given a new empty file for a particular application. You name it, open it, and go. I don't use Windows often, so I haven't really seen how well this menu item is suported by third party applications. But it is a nice idea.
3. But, when it comes to big documents and applications, I like the current way of doing things. One reason is that since subscribing to .Mac and using its iDisk, I share some documents (namely a rather large OmniOutliner document) between work and home and sometimes in between. Auto saving would be bad due to iDisk's speed (which is not horrible, but it's definitely not fast like local drives). Another reason, as Mr. Gruber points out, is that life is often full of temporary scratch documents. And there are so many different documents for different purposes that it just doesn't make sense for some situations or fields.

The reason for so much variety could, however, be due to interface cruft. We're running on heavy old operating systems with shiny new interfaces (and sometimes ugly new interfaces). The handhelds, particularly the Newton, had a chance to be actually new, and to approach how the operating system and applications performed in a very different way than the desktop operating systems. On the Newton, you just entered in data in the Notebook and then - optionally - filed it into Folders. You could also route the data (mail/print/fax/beam), or combine it with other Newton applications (entering "dinner with Kate" and clicking "Assist" would make the Newton go "oh! Shedule! Tonight, 8:30, Dinner" and find entries in the address book that match "Kate". Contrast this with a five step "Create New Calendar Entry" wizard.

But again - this is generally in the PIM category of data. It's a curious breed of data.

I'm not sure I want to get involved in the "there should be no 'Quit' command". There are so many applications of varying sizes and purposes out there that I doubt it will go away any time soon. The big case-in-points are the professional applications, from the Office type of applications to the Adobe and Macromedia product families, which are often very large applications, and also the Pro Tools / Final Cut Pro type applications. These applications offer a lot of functionality and people tend to stay in them longer. Adobe GoLive 6.0.x is a very large application, and when I'm using it, I keep it open even if I have no open documents at the moment, just to make it easier to switch to. I'd be very frustrated if I closed a particular window and it caused the whole application to unload itself. In the case of Quicken, there are so many windows that open up and use for control, which one would be the reigning "close this and the whole thing goes" window?

On the other hand, there are the utility applications. Apple's iCal and Address Book both go away when you close the main window. Other smaller apps do the same. This effect is probably completely unnoticed on Windows since the global X app killer button is so ubiquitous, and multi-document apps and single document ones are harder to distinguish.

Cool Site nod: Snow of Butterflies. Good design, nice sounds.

And speaking of good design and nice sounds, Eucci & Co. have wrapped up (finally) production on Nova Express for No Type's Sine Fiction series. Now, as soon as the studio is cleaned up a tiny bit, work can go into production of More Summer Dress Fire, a collection of small live performances harking back to the ELW's Modern Belongs to Us days of gallery/warehouse/alleyway/bunker recordings.

And more still coming soon.

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.