Thoughts on Interface Cruft, pt. 3: Documents vs. Applications

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.