OSNews

Neither BeOS nor Mac OS 9 require users to add extensions to their filenames. Without extensions, some other means of identifying a file's type and associated application is necessary. All versions of Mac OS assume that the application that created a document is also the best application to launch it in, resulting in situations where files of the same type launch in different applications when double-clicked. For some reason, a lot of Mac users don't seem to see this creator-based launching schema as a problem, but I do. It results in not-infrequent unexpected and undesired behavior on the part of the OS, and seems like a major usability disadvantage. Just recently an OS 8 user in our department sent me a bunch of JPEG images as an attachment. When I double-clicked them, the Classic environment started to launch. Turns out they had a Creator code for the Classic version of QuickTime. Excuse me? When did I ever tell the OS that I'd rather not view JPEGs in my viewer of choice? What does QuickTime have to do with these images, other than the fact that she created them in it on her system? I've experienced similar events half a dozen times in the few months I've been using OS X, and have heard similar stories from others. Why Mac users are so complacent about Creator-based launching is beyond me.

In an attempt to become more compatible with the Windows world, OS X requires extensions for file type identification. Meanwhile, it continues to respect the Creator code for application binding. In other words, rather than moving forward by dropping the Creator code and moving to a complete FileTypes preferences panel, OS X adopted a bad habit from Windows (extensions) and retained its own bad habits (using the Creator code for application binding). While the rest of the OS was moving forward, filetyping left one foot in the mud and stepped backwards with the other foot. This is utterly baffling to me. Filetyping under OS X is now doubly problematic, rather than better than it was.

Recently, a discussion explored this issue in the context of metadata in OS X in general. In the course of that discussion, it was pointed out to me that it is not the Creator code per se' that I don't like, but rather the application binding policy of the OS / Finder. What's needed to provide maximum flexibility to the user, IMO, is to allow for storage of any type of metadata. And one of those pieces of metadata needs to be a "preferred_app" attribute. The operating system's application-binding policy should look first to see if the user has established a preferred application for handling the current file. If not, it should look to see if there's a globally preferred application for handling this file's type. If not, it can try and use the Creator code if necessary. Respecting the Creator code should only be a last resort, since it's so often responsible for unexpected and undesirable behavior. But as seen in the screenshot below from X-Ray, the Creator code is looked at first, the file's extension second, and the file type third - the exact opposite of what logic and usability would dictate.

If Apple is ultimately to provide a central FileTypes preferences panel, and simultaneously wants to satsify users who for some reason feel strongly about the Creator code, there's another possible option here. Rather than simply elevating the importance of the file type and deprecating the importance of the creator, Apple could let the user select the order of the binding rules. For example, users who want maximum control over binding preferences could opt to have the file's preferred app checked first, the preferred app for that file's type checked second, and the creator third. Died-in-the wool traditionalists could have the Creator checked first, and other options checked second and third. In other words, Apple could not only match Be's level of flexibility, but could surpass it.

The other part of the problem is that OS X offers no central file types preferences panel. It needs one, badly. Without it, OS X will never be able to depart from the cursed practice of respecting the Creator code, and will never be able to approach Be's level of flexibility. BeOS ships with reasonable defaults for file type-to-application bindings, and these are configurable by the user on a system-wide basis, at the individual file level, and on batches of files at once via a built-in Tracker Add-On. The BeOS user does not need to put extensions on his/her files, BeOS never makes the rotten assumption that the creating app is also the best launching app, and the BeOS user has control over application binding from the micro to the macro level.

The BeOS filetyping and application binding system has more flexibility, more usability, and is more logical than OS X's. After the performance issues, OS X's backwards filetyping schema is my single largest disappointment with OS X.

After several weeks of using OS X, it was pointed out to me that OS X does offer some semblance of control here. Get Info on a file, select "Open With Application", and navigate to the new app. You can then re-set the binding for that document, or choose to make the change globally. It's great that it's possible to do so, but there's a logic problem here:

The Get Info panel relates to info on a selected file or files. But here, it is being used to make a system-wide change -- in other words, a System Preference. It is not intuitive to look in a single file's Info panel for a system preference, which is why I never found the option when looking around, and why a friend had to point out to me that it was even possible to do so.

A central FileTypes panel would be more intuitive, more powerful, and would give the user much more control over every aspect of file types and bindings.

On this note, an additional BeOS advantage is that the MIME typing system allows the OS to easily keep track of which apps can handle which file types, and thus to suggest candidate applications. For example, if I create a custom filetype with the MIME type text/x-shacker and send it to a user who hasn't registered that filetype on his system, BeOS will still be able to tell that it's a text file. Since every BeOS app registers itself to handle certain MIME types, BeOS can instantly provide a list of all text-handling apps on the user's system. This capability also comes into play when displaying the "Open With..." context menu when right-clicking a file in the Tracker.

For a detailed discussion on the entire filetyping / binding / identification / customization schema in BeOS, buy a copy of The BeOS Bible. To read an excerpt from the chapter on filetyping, click here.

1. "Out of the Frying Pan..."
2. "... And Into the Fire..."
3. "Smells Like Home Cookin"
4. "A Lot To Like, First Impressions"
5. "Networking Nirvana"
6. "CD Burning, Disk Images"
7. "Applications"
8. "iMovie, iDVD"
9. "Browsers and E-Mail"
10. "Power Editors"
11. "Community"
12. "The Bad and The Ugly"
13. "File System Shoot-Out"
14. "Application-Binding Policies"
15. "Alien Filesystems"
16. "Miscellaneous Moans and Groans"
17. "All Told, Life Is Good"