|Monday, September 21, 2009
11:39 - You've broken the Creator Code, and now you must die
It looks to me as though the jury remains out on the subject of Type and Creator codes in Mac OS X.
Apparently Snow Leopard has made the conscious decision to eradicate Creator Code recognition. Naturally there are those who are scandalized by this and similar decisions, as indeed I've been known to be. But there are also plenty of people who seemingly have taken a step or two back and evaluated this decision from the perspective of the majority of users and what behavior will seem the least weird to the most people.
I think this is one of those situations where Apple was never going to make everybody happy. I’ve been using Macs nearly as long as they’ve existed, and Apple products longer, and in many ways, sure, going from creator codes to file extensions was a step backwards.
However, the scenario put forth by the Apple Engineer that you dismiss as “comically wrong”, is exactly how I feel. Just because I used Photoshop to edit a file at some point, or even to create it, doesn’t necessarily mean I want that behemoth of an application to launch every time I double-click that particular file. As long as I have a way to specify that an individual file should open with a different program, I personally prefer to have documents open with the default application for its extension if I haven’t specifically said otherwise.
Yes, it’s a change from the days of classic Mac OS, but it’s not as abrupt of a change as you make out. An awful lot of programs simply don’t use creator codes any more – in Cocoa, they’ve always felt like a bit of legacy metadata that shouldn’t be there anymore. Sure Photoshop and Nissus Writer (which are both old Toolbox apps using Carbon) do, but many apps created more recently (say, in the last decade) do not.
It’s about time we got rid of that cruft and had a system-wide standard behavior. Yes, some people are going to dislike the new behavior, but you’ll adjust. Progress is not betrayal, but sometimes progress comes with some pain.
The comments on the post crystallize a good set of well-reasoned rebuttals to the original poster's indignance. I think what it comes down to is that if you're a hard-core Mac nerd with a really well-established workflow that depends on the flexibility of Creator codes that override a system-wide extension-app binding, then this Snow Leopard decision will seem like a betrayal and a dumbing-down of Mac OS X to conform to a Windows-level lowest common denominator, just as I considered the adoption of extensions for file type identification to be a dumbing-down and an irreparable loss of elegance. But if you're a casual user, or one who skips from machine to machine (or even OS to OS) a lot, or really just one who isn't wired into the system at the cortical-implant level such that any infringement on a just so workflow is cause for alarm and rage, then the new behavior just looks like common sense.
I was justifiably horrified when Apple started using the extension for file typing, rather than the four-byte Type code I'd enjoyed for many years and around which I'd built my workflow. My indignity came from the perceived elegance of the old "File Exchange" Control Panel in Mac OS 9, which was set up to apply certain (user-definable) Type and Creator codes to newly created files downloaded from the Internet depending on the app and context you used to download them. ("Helper Apps", to dredge up a term from Ye Olde Internette.) If you saved a GIF from a website using Netscape, it would apply the proper GIFt Type code and a Netscape Creator code, and all would be well in Classic Mac Land—you could remove the ugly and pointless ".gif" extension with impunity. But when Mac OS X came along, there was no more File Exchange; if you got a GIF from the Web somewhere, it was assigned no Type or Creator codes by anything, and if you removed the ".gif" extension (like any good-hearted soul with an ounce of aesthetic sense simply would do, so went my theory), it would lose its app binding and icon, and double-clicking on the file would earn you nothing but a blank look from the OS. Hardly desirable.
Further, when in OS X 10.1 they introduced the option to "always show file extensions" (implying, as it did, that extensions could be hidden rather than eliminated altogether, but were still depended upon by the OS for file typing), it seemed like the end of all that was once good in the world. It seemed like an unthinking engineering band-aid designed to get a product to market quickly, spearheaded by newcomers to a venerable product who neither understood nor appreciated that product's design or inherent elegance, and only valued getting the project finished on time so they could get bonuses.
But this was all tunnel vision. If I were to just step back a few paces, I'd realize that not only was this move the result of a well-informed decision by people who really did understand the underlying technology and what made it cool, it was made by people who understood it well enough to understand when it was valuable to let go of it.
Extension-based file typing is ugly, true. But it's the way things are done, for better or for worse; and the designers of 10.1 realized this. They also realized the importance of cross-platform compatibility to Mac OS X's success. What's more, they figured out a compromise that allowed them to retain the Mac's per-file smartness while guaranteeing cross-platform compatibility. By requiring extensions on filenames (and allowing them to be hidden on a per-file basis, even engineering a trick contextual "hide" function in the shared save dialogs that let you "hide" extensions by deleting them from the "observed" filename—a little bit of wetware-hacking, that, and a darned effective one), they ensured that not only would Mac people get to enjoy their clean extension-less filenames, but their Windows-using counterparts would never be confronted with a filename sent from a Mac that was frustratingly missing an extension, and just as useless at a casual double-click as on OS X 10.0.
There's real value in ensuring that a potential source of friction in a computing experience never arises. An ounce of prevention, as they say.
At first I missed File Exchange and the Internet Control Panel and the control they offered me over type-mapping; but eventually I understood that the real value in the new 10.1 behavior was that by sacrificing the utility of the Type code field, Mac OS X did away with the necessity for File Exchange altogether. Eventually it became clear that the only reason File Exchange existed in the first place was as a patch to cover a gap in functionality left by the incompatibility of Type codes with the prevailing technologies on the Internet, and if there were a better way to cover that gap I shouldn't mourn the loss of the old one. It's like if I were to complain about how fuel injection made it impossible to clean my carburetors.
The same thing is now happening, almost a decade later, with Creator codes. I think it's telling how many of the commenters on Ross' site are pointing out how confusing and off-putting it is for a casual computer user to have to deal with an OS that respects Creator codes and opens files in the apps that created them—with the perceived effect, to a user who wasn't responsible for creating the files in the first place, that it's opening the files in randomly selected apps. Even the person who created the files might well be annoyed by the traditional open-in-creator behavior, as in the quoted comment above. The only people who really benefit from the traditional behavior are those who are so wedded to it that they've built their muscle memory and workflow style around it.
What it comes down to, as is so often the case, is that different users develop different habits depending on their environments. People get used to the damnedest things. Millions use Windows every day and don't feel it's lacking anything in the usability department, and indeed are put off by the Mac simply because it doesn't have a Start menu or a right mouse button. Apple has to take into consideration the marginal utility of making the transition experience more seamless for the greater number of potential switchers (and, indeed, brand-new users with no Windows preconceptions) as opposed to the marginal utility of keeping the long-time users of Creator codes happy. Unfortunately for the latter group, the former is a much more numerous and lucrative market.
But this need not mean Apple is appealing to a lowest common denominator, nor is "dumbing down" the OS experience. The fact that the OS still has the capacity to bind individual files to specific openers ought to go to show that the OS X team is still committed to retaining the flexibility that the Mac has always had. For that matter, the new behavior—once you think about it dispassionately—is better thought out from the user perspective anyway. Really, why does it follow that the "opener"—which is what the user really cares about—should be derived from the "creator"? Why should you have to lie to the OS about what app created the file just because you want a different app to open it? The old system overloaded the existing metadata field with a not-quite-congruent behavior interpretation, encouraging the loss of historical information (e.g. the actual "creator" app) in pursuit of a poorly supported feature, and by the end of Mac OS 9's lifespan the widespread practice of changing the "creator" code to alter the "opener" behavior had taken on the lore and legend of a hack so venerable as to be scripture—but still a hack.
It really makes a lot more sense the way it's designed now: system-wide rules mapping file types to apps, and per-file exceptions that override the general per-type rules. The "opener" behavior is now explicitly what that bit of metadata is used for, and it's fully exposed to the user and mutable, whereas—as is often overlooked—the old Type and Creator codes were never really supposed to be user-modifiable at all. The app creating the file stamped the Creator code, and you were always supposed to use that same app to open that file in the future, since after all this was designed in the age before industry-standard app-agnostic file types like JPEG and HTML, and every app had its own proprietary file type anyway. Resetting the Creator code to override that behavior was a useful trick popularized by third-party plugins but never really embraced by Apple. But now, any app that sets the Creator code is doing so for legitimate historical reasons—stamping the file with a brand that can't easily be changed, but that doesn't affect the behavior of the file when you double-click it either, so there's no desire to change it anyway. That's the way it should have been all along. No matter how conceptually beautiful a couple of 32-bit alphanumeric words were in defining the appearance and behavior of a file in 1987.
I haven't investigated this myself, but since setting the "opener" rule on an individual file is a well-supported feature of the Finder, it should be an easily accessible method for applications to use, and thus any app should be able to set that behavior on a file it creates, right? As one commenter noted:
Sure: If you save a Keynote document, you have the option to set a checkbox either to contain the used images or not.
At this point ( save dialog ) or in the applications preferences could be on option for that.
File > New > SaveButton ( “always open with this app” option checked NO )
Application creates new file on disk.
File > New > SaveButton ( “always open with this app” option checked YES )
Application creates new file on disk.
Application changes “always open this file with” flags to eg. TextMate
Seems like a perfectly natural way to leverage the new system's preferred way of doing things, and in a clear and user-accessible way to boot. Just as with the extension supplanting the Type code, the new way maintains flexibility and yet avoids confusing new users. It just requires app developers to do a little more legwork, and long-time nerd users to adjust their expectations a little.
It's well established that Apple likes to keep its software development neat and tidy, jettisoning old technologies as frequently as introducing new ones. They don't get emotionally attached to technologies for their own sake, as so many users (myself included) have been known to do. John Gruber noted this recently, among many other similar observations about Snow Leopard:
The single most remarkable thing about Snow Leopard is that it is smaller than the previous version of the system. It is an operating system that is — and, going back to its roots at NeXT, has always been — evolving, not just growing. Apple doesn’t just add to it. They prune. They churn. And the track record shows that when it comes to ushering old technology out the back door, they err on the side of too soon rather than risk letting it linger too long. Apple worries about the way things should be far more than it worries about continuity with the way things used to be.
With this in mind, it's surprising that it's taken them this long to address the dangling twig that is the Creator code and snip it off.
That's what makes Apple fundamentally different from Microsoft and others: they're not afraid to alienate those adherents to the old ways, because they know that of all their user base, those users are the ones best equipped to adjust to a new paradigm. They don't put that onus on newbies and force them to juggle lots of weird new concepts; they'd much rather make it work the way a reasonable and untrained person would expect, and then support additional discoverable flexibility in the underlying technology for those users who are ready to delve a bit deeper in the quest for efficiency. But power-user flexibility, however useful, should never get in the way of that all-important first impression.
UPDATE: Note that I'm not waving a general Snow Leopard banner here; I'm still not using it myself, because my main machine is a Dual 2.0 G5 from 2003 that can't run it. Aside from the fact that it now can't be upgraded to 10.6, I have no technical reason to get a new machine; but 10.6 and its implications are forcing me to figure that into my budget even though I'd had no intention to do so otherwise. Not fun.