MacOS X apps didn't tend to set creator codes by default. Some apps ported from MacOS 9 such as Photoshop would set them, but the majority did not. However, if a creator code was set, the system would honour it and open the correct app… until Snow Leopard. In Snow Leopard, the only way to make a file open with a different app to the default is to set it manually in the Get Info window. Crucially, an application cannot set that while saving, the user has to go and do it.
I'm not going to comment on the state of play here, but rather on a point Gruber made:
Take a step back and consider that the term creator code itself shows just how different things are today. When the Mac was created, nearly all documents were proprietary binary file formats. The only app that could read MacWrite files was MacWrite, etc. Even when apps could read other apps’ file formats, they typically did so only through an import/export process.He goes on to say that now we work with many different types of open file format in many apps, so the question "Which app should open this file?" is not always answered with "The app that created it".
Thinking back to when I first switched to Mac, back in 1993 (the System 7 days), I don't think the proportion of open file types was too much lower. We saved graphics as TIFF, vector stuff as PICT, text files as plain text, databases as comma separated. Granted, I had loads of ClarisWorks or Quark files, but they're comparable to all the iWork and inDesign files I have today, which are also in proprietary formats. I don't think that's it.
You may have read John Siracusa's laments about the demise of the spatial Finder. To sum up, a spatial file browser has one window per folder, and opens each folder in a new window. That window appears in the same place as it did last time you opened that folder. To the user, the window (size/position/layout) is the folder. We've now switched to a browser style file manager, where a window is just a helpful device to pick files, and you move them around with impunity, knowing that your settings are not stored anywhere. Think about iTunes and iPhoto: browser based media managers. Even opening an image in Preview presents you with a window with a sidebar for putting multiple images in a single window. Compare to opening one in SimpleText back in the day, where the picture had its own window with nothing else in it.
In the user's terms, it used to be that the window was the document. The two were equivalent. Now, in a trend that started with the World Wide Web and has now moved into the rest of the operating system, a window is merely a container for one or more documents. That's a fundamental change in the user's concept of what a window is.
How does this relate to creator codes? Well, if the user equates a document and its window, then it is completely natural to open a document in the same app. Anything else would violate that mental model. Sure, a file could be manually opened by dragging it onto another app's icon, but that separate action was considered to be a "convert" action. Just opening a document put it exactly as you left it last time, with window position saved, the same editing tools available, and other such things.
With the trend to browser style windows, there's no longer that expectation. Double clicking a file no longer means restore the state of this document so I can work with it. And that's why it's no longer reasonable to say that the best app to open a document is the one that created it.
Have to agree. Personally, creator codes caused more headaches than they solved. Double clicking a jpg should never launch photoshop - it should launch a smaller, lighter program that can quickly view jpgs.
ReplyDeleteI can't count the number of times I selected a folder full of JPGs and clicked "Open" only to have both graphic converter AND photoshop launch. It was maddening.
A checkbox when saving a file from any program would be nice. That way we'd get to choose on a file-by-file basis but without having to open the Get Info window after the fact.
ReplyDeleteThis is a good observation, and I think it explains why I like the new Finder better than the old one. (After using OPENSTEP, I started using Greg’s Browser even on the old Mac OS.)
ReplyDeletefahrvegnugen: While I agree that that's maddening, it's relatively easily remedied. Creator codes (or whatever mechanism performs such application-file binding) should not cross system boundaries. If I have a folder of files sent to me by a bunch of colleagues, they should open according to *my* preferences, not those of my colleagues. This is easily accomplished by discarding the binding when the file is emailed/downloaded/etc. Such discarding was often but not always discarded in the bad old days by virtue of storing the creator codes in the resource fork, which non-Mac systems usually ignored. But it was unpredictable.
ReplyDeleteI actually used to detest Photoshop's creator codes. When I work on an image in Photoshop, I save it as a PSD. It only opens in photoshop. That's fine. When I'm done working on the image, I save it out as a JPEG. You don't know how many times I've force quit Photoshop because I've just wanted to quickly look at a JPEG. I actually won't miss creator codes at all.
ReplyDeleteI think many old-timey Mac users feel so strongly about the loss of creator codes because it was one of those features that separated the Mac from everything else; it's why they used a Mac.
ReplyDeleteBut, as has been pointed out by many, creator codes doesn't translate well on the modern desktop. It's an invisible feature that was used inconsistently.
For me, creator codes were useful 5% of the time, an annoying hinderance 95% of the time. For that 5% I'm more than happy to use Finder to set how I want my files to open. It is the right time for Apple to close the curtain on Creator Codes.
I wonder if as Quicklook gets better, you could go back. If I want to quickly view a JPEG, for example, just Quicklook it instead of opening it. Although, it seems, that programs should not set creator codes on non-native file formats they export, or perhaps no program should set a creator code on an open type of file like JPEG, then those would open in the app of the user's preference. But then a proprietary format can only be opened by that app anyway, so it would be associated if the user had it or else they have a compatible program that is associated. It's only when you have a type that multiple programs can read that this is a problem. It seems primarily web designers who edit their own HTML files and can't be bothered to use "open with" for their occasional non-default action. I don't understand why it's hard to set .html to open by default in BBEdit or whatever and use open with to put it in Safari once in a while. I guess they must use another text editor for only some of their .html files.
ReplyDeleteMy gut feeling is that we’ll see a shift towards role-based actions—that is, rather than just “opening” a file, you optionally have a choice between using a “viewer” or an “editor”.
ReplyDeleteWe do this conceptually ourselves when we make the choice between, say, Preview or Photoshop, and LaunchServices knows (because the respective apps’ Info.plists tell it) that Preview is just a viewer whereas Photoshop is an editor, but—and this is actually something Microsoft tried hard to introduce with OLE in Windows 3.1, though they were by no means the first—there’s no explicit UI for making the choice when you open the document besides choosing an app by hand.
I wouldn’t be at all surprised to see things extended in 10.8, or whatever, such that you can bind applications to specific roles for a given file type—either globally, or on a per-file basis—just as you bind what is effectively a non-descript default role right now.
Type and creator codes are *not* stored in a resource fork. They are "stored in the file system metadata structures of HFS/HFS+ volumes alongside things like creation and modifcation dates (Mac OS X emulates their storage on non-HFS/HFS+ file systems)"
ReplyDelete--John Siracusa, Metadata Madness, http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars
Tamuc: ooops, my bad. The point remains, however it is implemented, that the application-file binding should not traverse file systems. If a file is bound to open in TextMate on my machine (even though all others of that type open in, say, Safari), that binding should not affect anyone else to whom I send that file.
ReplyDeletefirst of all the "new" behavior is stultifying, though it may suit some people better than the old application binding scheme, it's not powerful, nor intuitive, and it diminishes the expressiveness of filenames
ReplyDeletewhat is most deficient, though, is the reliance on one principal means of "opening" a file -- double click -- which does not capture the range of actions we actually want to perform on files; while i'm a defender of the creator code system, i normally drag files to an icon (generally in LiteSwitch) or use Open With... these are more expressive, but still conceptually awkward -- "open with" perpetuates the sense of a single verb, and dragging a file makes the file the verb rather than the object
we clearly need a more expressive gestural language, one with more verbs; until Apple is willing to upset a few carts, though, we will not get there; the multi-touch trackpad, and perhaps a new mouse coming out tomorrow, may give us the foundation for a bigger vocabulary of interaction with files, but i don't expect Apple to explicitly endorse an interaction language that requires work to attain fluency
@eaganj: your suggestion ignores the "creator" aspect of the type/creator diad -- you have the notion that all files of a type should be opened in an application of your choice; the creator concept, while it is limited, allows different files of the _same_ type to be bound to different applications; this is useful beyond a single machine, for example a workgroup may pass around many files of the same type (e.g. EPS or PDF) but which must be edited with specific apps (e.g. Photoshop, Illustrator, Freehand)
ReplyDeleteso while i would advocate for flexibility in application binding, i do think the underlying metadata should survive transport
I've been meaning to write nearly this exact same thing ever since Gruber made that post. I think it's very astute to bring in Sircusa's issues with the spatial finder because I think they both come from a fairly antiquated way of thinking about how people interact with a computer. Both are examples of trying to make the computer behave similarly to something in the physical world. And there was a time when this was necessary for most users to understand how to interact with a computer. But when you think about it, it's really pretty absurd to saddle computing with the limitations of physical space.
ReplyDeleteI can't stand creator codes. They were always getting in my way. How many times did I have to Force Quit Photoshop in the middle of launching when a JPEG happened to have been saved by Photoshop?
ReplyDeleteI'm glad to see they're no longer used, though I sympathize with people who liked them. I would have been happy with the OPTION of ignoring creator codes.
-Rob
@grover: "Antiquated"? I do not see how a spatial Finder "saddles" the user. I would actually suggest the opposite, in that by providing strong cues, it reduces the time necessary to find and interact with objects when doing anything more complex than the typical simple tasks for which an increasingly larger percentage of people are likely to be using their computers.
ReplyDeleteIt's nice, I suppose, that Apple has decided to provide the option of a stripped-down, uncluttered interface for those who need or want it. I am put in mind of the way many (or most) Windows users operate with a single, maximized window. That's a fine option, but it shouldn't be forced on everybody as the One True Way.
My complaint is that in providing this simplified interface, users who want the ability to move among multiple tasks concurrently are getting the dirty end of the stick. My basic message to Apple is: Please trust that I know my work habits and when I decide that I need a particular object or task to appear a certain way, it is probably for a pretty good reason, and I would rather not have to keep resetting views or positions of things because all this complexity isn't sufficiently aesthetic or simple enough for everyone else who might be using OS X.
I suppose it is possible that I am old and inflexible, but I honestly have not found the non-spatial Finder to provide any advantages to the way I work, and I am always looking for ways to improve it. My work is in vision science so I have spent a fair bit of time considering the relative merits of different forms of visual presentation (don't get me started on all the gratuitous eye candy and horrific translucency -- for which the inability to turn off might well be be a violation in spirit of the Americans with Disabilities Act ). As popular as it currently is to bag on spatial constancy, it makes no sense to strip away something that is this fundamental to the way we think and work.
The more I consider it, I think the shift towards providing simplified access to your computer through a limited browser interface may very well be a better example of saddling the user.
Good points, but I still prefer the creator codes for the _options_ it provides.
ReplyDeleteAlso, regarding opening 'lighter' apps to see for instance a JPEG... isn't that exactly what QuickView is for?
@sporobolus I think you misunderstood what I wrote. When I refer to application-file bindings, I'm talking about just that. You seem to be reading that as "application-filetype bindings." Please re-read my second post.
ReplyDeleteAdditionally, the behavior you described does actually exist today. You can have all .html files open in Safari except for a few (via the Get Info dialog). What the creator codes provided and that you cannot in any safe way do in Snow Leopard is have an application automatically set that binding when it saves a file.
That is, you can set a bunch of files to open in TextMate while all others of the same type default to Safari, but you can't have TextMate automatically set all of its files to open in TextMate while any other html file opens in Safari. That's the whole crux of the argument!
My point is that, however that binding is made, it should not persist when the files changes filesystems (including in a zipfile/tarball). That is, if you email me your file created by TextMate and that overrides the default binding, the file should open according to *my* default preference.