Thursday, May 01, 2008

The Dock should be destroyed, or at least changed a lot

I found an article about features Windows should have but doesn't, which I originally got to from OSNews' commentary on the feature list. To quote the original article:


The centerpiece of every Mac desktop is a little utility called the Dock. It's like a launchpad for your most commonly used applications, and you can customize it to hold as many--or as few--programs as you like. Unlike Windows' Start Menu and Taskbar, the Dock is a sleek, uncluttered space where you can quickly access your applications with a single click.

Which OSNews picked up on:


PCWorld thinks Windows should have a dock, just like Mac OS X. While they have a point in saying that Windows' start menu and task bar are cumbersome, I wouldn't call the dock a much better idea, as it has its own set of problems. These two paradigms are both not ideal, and I would love someone to come up with a better, more elegant solution.

The problem I have with the Dock (and had with the LaunchPad in OS/2, the switcher in classic Mac OS, and actually less so with the task bar, though that and the Start Menu do suffer this problem) is that their job basically involves allowing the internal structure of the computer to leak into the user's experience. Do I really want to switch between NeoOffice Writer, KeyNote and OmniOutliner, or do I want to switch between the document I'm writing, the presentation I'm giving about the paper and the outline of that paper? Actually the answer is the latter, the fact that these are all in different applications is just an implementation detail.


So why does the task bar get that right? Well, up until XP when MS realised how cluttered that interface (which does seem to have been lifted from the NeXT dock) was getting, each window had its own entry in the task bar. Apart from the (IMO, hideously broken) MDI paradigm, this is very close to the "switch between documents" that I actually want to perform. The Dock and the XP task bar have similar behaviour, where you can quickly switch between apps, or with a little work can choose a particular document window in each app. But as I said, I don't work in applications, I work in documents. This post is a blog post, not a little bit of MarsEdit (in fact it will never be saved in MarsEdit because I intend to finish and publish it in one go), the web pages I referenced were web pages, not OmniWeb documents, and I found them from an RSS feed, not a little bit of NetNewsWire. These are all applications I've chosen to view or manipulate the documents, but they are a means, not an end.


The annoying thing is that the Dock so flagrantly breaks something which other parts of Mac OS X get correct. The Finder uses Launch Services to open documents in whatever app I chose, so that I can (for instance) double-click an Objective-C source file and have it open in Xcode instead of TextEdit. Even though both apps can open text files, Finder doesn't try to launch either of them specifically, it respects the fact that what I intend to do is edit the document, and how I get there is my business. Similarly the Services menu lets me take text from anywhere and do something with it, such as creating an email, opening it as a URL and so on. Granted some app authors break this contract by putting their app name in the Service name, but by and large this is a do something with stuff paradigm, not a use this program to do something one.


Quick Look and Spotlight are perhaps better examples. If I search for something with Spotlight, I get to see that I have a document about frobulating doowhackities, not that I have a Word file called "frobulating_doowhackities.doc". In fact, I don't even necessarily have to discover where that document is stored; merely that it exists. Then I hit space and get to read about frobulating doowhackities; I don't have to know or care that the document is "owned" by Pages, just that it exists and I can read it. Which really is all I do care about.

2 comments:

Anonymous said...

I hadn't realised the disjoin between apps and documents in the dock (in terms of switching apps / switching documents, especially). In fact I only realised the cmd-tilde the other day for going window -> window within an app (doh!). Now all I need is for Terminal to offer up a key for going tab -> tab (like Safari does) and I'm done.

I must say though while I agree that it's largely irrelevant what app you're using (in terms of switching apps / documents at least), I can see some problems with Apple jumping on your idea:

[1] My dock icons are already diddy enough. By the time Mail.app has added the ~40,000 unread cocoa-dev messages in there as mini-windows, it's possible I'll spend a lot of time switching documents just to get to "zebra.png".

[2] Sometimes you want to do 2 things with 1 document. Eg. if you're writing static HTML, you might want to see it in TextMate / BBEdit, and also in Safari / Firefox.

By the way can you send me my frobulating doowhackities document, I've been looking all over for that chap. Thought I'd left it on the fridge, didn't realise you had it.

Thanks bud,
Ken

Anonymous said...

Dunno how long you've been around MacOS - I had the misfortune to have to support Macs back in the days of System 6/7 onwards. I was really digging some stuff BeOS did, but I digress.

The one really cool thing that Apple tried before OS X was called OpenDoc. Basically, instead of having an application that you edited documents in, you had a document, in which you could embed bits that were supplied by a variety of applications (applets?).

It never took off - I recall someone quite recently suggesting it was because 3rd party suppliers weren't happy with the idea of you not seeing the application - in particular the splash screen. Not editing an "Excel" document, but a document with a spreadsheet component theoretically makes you less aware of excel, and less likely to buy it, I guess.

Anyway, the long and the short of it is that it didn't take off. Now, proper multi-tasking exists outside of Amiga/BeOS/Unix, so it isn't such an issue.