Subscribe to
Posts
Comments
NSLog(); Header Image

Cocoa: Document vs. Uhhh, Not

There comes a point, very early on in every Cocoa project (especially), when you've gotta make a binary decision: is my application document-based or not? Web browser? Document-based (content = web pages). Word Processor? Document-based. iPhoto, iMovie, iDVD? Not document-based. Things get blurry, though, when you venture into other realms. Are applications like Mail, iChat, iTunes, and so on. They have one main window and then a bunch of document-like windows. In Mail's case, those spawned windows are little documents in their own right. In iChat not so much - they can just be single windows in a .nib replicating themselves as necessary.

I mention this because we hit a similar point - albeit in retrospect - in PulpFiction's development today. In our case, we did the equivalent of making Mail's main viewer a document window (you'll note that in Mail you can create multiple windows all over the place with cmd-opt-n). We chose correctly, but don't underestimate how potentially "big" the "to be (a document-based app) or not to be (a document-based app)" decision can be.

7 Responses to "Cocoa: Document vs. Uhhh, Not"

  1. If you wouldn't mind, could you elaborate on your rationale behind the decision. I like to do some OS X development in my spare time and I've been with the platform less than a year. This issue seems to be one of only a few inconsistencies I run into daily. As a user, there is simply no easy way of knowing ahead of time, whether hitting the red gum drop will close a window or quit the app. A quick fix might be to enforce a rule in the HIG that says a document-based app renames the "File" menu as "Document", or to remove the "File" menu from a non-document-based app altogether. But this is not too elegant. A better fix would involve replacing the red gum drop in non-document-based apps with a different coloured one. But we don't have this option available to us. So, the best approach I have come up with for now, is to try to anticipate what the user will do, and just go with that, which is not entirely straightforward in and of itself.

  2. Why are iMovie and iDVD not document based applications?

  3. I'm sort of curious as to why you made the decision you did as well - any elaboration?

  4. None of you have used PulpFiction yet, so I'm not sure what you mean by asking me to elaborate. I'd have to talk in such vague terms - or compare it to Mail - that you wouldn't understand my response and I may not even understand it.

    PulpFiction features an interface with a main window that can be cloned - like Mail - as well as accessory windows that can be used to view content from the main window in more detail - like Mail.

    That's about all there is to it. By doing a document-based app, we get stuff "for free" like command-N, automatic handling of document windows, and so on.

  5. Steven Canfield: Both don't allow you to have more than one document open at a time (same goes for GarageBand).

  6. It's always struck me that non-document based apps should use metal windows and document ones aqua - that's the only rationale i can see between having the two types of window. Which is sort of, but not quite, backed up by the new finder

  7. Metallic UI is sort of a grey area, even when you talk to Apple people about it. Basically, if it interacts with a physical device, it's metal. It also can be metallic if it employs a playlist metaphor. That's where the Panther Finder comes in. Safari just barely passes the playlist test (bookmarks), but Safari is one of the few apps I've seen where metal actually seems to work.

    Ultimately, I think developers should really look at it as "does this actually look good?" In many cases, the answer will be no. In a few it will be yes.

    - Scott


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.