On the Principle of Least Suprise as It Pertains to Double-Clicking Files

The latest edition of Mac OS X, Snow Leopard (or 10.6 for those in the know), has changed something that hasn’t changed on Macs since their introduction in 1984: a file’s “creator” code no longer has any role to play in deciding what application will open when that file is double-clicked. This is particular anathema to those few hearty souls who stuck with Apple during the lean years of the ’90s. Back then, those hearty souls often crowed about the Macintosh’s intrinsic superiority over the PCs of the era and the creator/type code regime was often at the top of their list of reasons why Macs were so obviously better.

Creator and Type Codes

For those not steeped in the history of file system metadata, allow me to explain a little. When Apple’s engineers created the Mac’s original file system, they decided to track a certain about of metadata about each file, or in other words to track certain kinds of information about each file in addition to the file itself. Among these metadata were the creator and type codes. The type code identified the contents of the file—i.e. plain text, JPEG image, Word document, etc. The creator code identified the program that had created the file¹. If set, the creator code was used to determine which program would open the file when double-clicked. If the creator code was absent, the type code was matched, if possible, with a system-wide default program for that code.

In many ways, this was an elegant solution to the problem of deciding what should happen when a user double-clicked a file. And certainly from a 1984 perspective, it followed the principle of least surprise: users expected that the program that wrote the file would open the file and that is precisely what happened. It was an obvious choice at that time particularly as nearly every program then in existence saved files in a proprietary format. Microsoft Word, for example, saved files in a format that only Microsoft Word understood. MacWrite saved files in a format that only MacWrite understood. Indeed, in these early days the two codes were almost always redundant: the default program for a given file’s type code was almost always the same program indicated by that file’s creator code.

Modern Needs

Over time, however, standardized file types developed that could be read and written by more than one program. Today, a JPEG image, for example, can be read by Apple Preview, Adobe Photoshop, Microsoft Word, Apple Pages as well as any Internet browser you can think of. Not only are there fundamental differences among these programs as to what they are and what they do, crucially for the user experience there are also vast differences in the load times for each of these programs. Apple Preview is a relatively svelte program that typically loads in a second or two. Adobe Photoshop, by contrast, is a behemoth that can take a minute or more to load. If a user expected Photoshop but got Preview, it is a mistake that is quickly corrected because Preview loads so quickly. If a user expected Preview but got Photoshop, it is a mistake that takes much too long to correct because Photoshop is so slow to load. In addition to surprised, the user is often frustrated.

Ah, but if the creator/type code regime is even half so superior as the Mac fanboys of the ’90s loved to claim, how then is it possible for a user to expect one outcome when double-clicking yet encounter another? The answer lies in the always-present but rarely acknowledged Achilles heel of the creator and type codes: they are now and always have been hidden.² And with good reason. In the first place, since they were invented for the resource-starved original 1984 Macintosh,³ these codes were limited to 4 bytes and were consequently quite cryptic.⁴ Secondly (and more importantly, I think), there is the simple fact that there are two codes. Most users would likely not remember which code did what or what would happen if one of the codes wasn’t set. How, then, was a user to know what would happen when he or she double-clicked on a file? Again, the answer from 1984’s perspective was simple: the file’s icon. Each program that overwrote the creator code would also add an icon for that file which visually tied the document to the program. Double-clicking on that icon produced no surprises as to which program would subsequently launch.

The trouble with the icon approach, however, is that while it does succeed at identifying the associated program for each file, it does nothing to visually indicate the contents of the file. All the Word documents, for example, end up looking the same. Worse, all of the image files look the same as well. Scanning a folder’s icons in the Finder becomes useless if it has a number of files made by the same program. Thus, as icons became more detailed and especially once color became available, icons became previews of the file’s content rather than visual references to the associated program. This trend started with images but Leopard brought pervasive preview icons, even to more humble formats like word processing and plain text documents. In the process, however, the visual tie to the associated program was lost.

So now we are left with a conundrum: how do we let the user know what is going to happen when he or she double-clicks on a file and provide a preview of the file’s contents in said file’s icon? The answer is painful to those loyal fanboys of the past yet perfectly simple: the file’s extension. Long eschewed by the older Mac community as a hideous artifact of “PCness”, file extensions have nevertheless been part of the file-opening-decision-making process since the debut edition of Mac OS X, Cheetah (aka 10.0). File extensions have the advantage of being both visible⁵ and simple. When I see a file ending in “.doc”, I know it will open in Word. When I see a file ending in “.pages”, I know it will open in Pages. No guessing, no surprises. If I prefer that JPEGs open in the quickly launching Preview rather than the slowly launching Photoshop, I merely set the global default for the “.jpeg” extension to Preview. If I need to edit the image in Photoshop, I can always open it in that program manually, in a number of different ways. If there is a particular JPEG image that I want to always open in Photoshop, Snow Leopard retains a per-file override that can be used to persistently associate a given file with a given application. Thankfully, this override data is not programmatically accessible via any of Apple’s public APIs so it is more difficult for Photoshop to hijack my JPEG associations as it always did when the creator code was honored.

Just What is So Surprising

The degree of “surprise” generated by a policy decision—such as no longer honoring the creator code—is, of course, entirely subjective. Long-time Mac users will tend to be surprised by this new behavior and therefore disappointed by it. Switchers from Windows will be more likely to embrace it. Personally, I was infuriated every time I had to wait for Photoshop to launch after double-clicking an image that I realized too late had been edited in Photoshop. I always found association hijacking to be a “surprise” and I gleefully welcome its demise. Moreover, relying on file extensions makes the Mac a better citizen of our connected world as file extensions undeniably represent a de facto industry standard for application association.

Now if only Apple would accept the de facto industry standard behaviors for the Home, End, Page Up and Page Down keys…