iTunes: Yet another inconsistent ‘click-through’ behaviour

Posted by Pierre Igot in: iTunes, Macintosh
May 29th, 2006 • 1:37 pm

In Mac OS X, there are a number of things that you can do with interface objects without bringing them to the foreground. The most obvious one is the ability to close a background window (by clicking on its red “Close” button) without having to bring it to the foreground first.

But there are many more subtle things that you can do, several of which involve some variation of the same “click-through” behaviour, where clicking on or dragging to a background object actually works without bringing that object to the foreground first.

The problem is that this ability to “click through” also brought about a whole slew of new possibilities for Mac users, and Mac OS X itself has to be able to accommodate an exponentially greater number of possible user actions.

Sadly, even after four major revisions, Mac OS X still falls short, and many other Apple applications also suffer from pretty glaring flaws when it comes to the way that they handle click-through actions.

Here is an example in iTunes 6. iTunes has one main window where it displays everything. The contents of the window vary depending on what is selected in the source list on the left.

But you can also open certain things in a separate window, by double-clicking on their icon in the source list. For example, you can keep your library visible in the main iTunes window and open the iTunes Music Store in a separate window by double-clicking on the Music Store icon in the source list (which is handy when you want to make sure that you don’t already own a track that you are about to purchase).

You can also open individual playlists in a separate window, again by double-clicking on the playlist’s icon in the source list. I often do this when I am in the process of creating a playlist that is a compilation of various tracks by various artists, because I want to be able to browse my library and still see the contents of the playlist at the same time, especially in order to be able to determine the exact order of the tracks in the playlist.

When you have your library in the main window and a playlist in a separate window, if you drag a track from your music library (in the foreground) onto the playlist window (in the background), under your mouse pointer iTunes displays the horizontal separator that indicates exactly where in the playlist iTunes will insert the track that you are about to drop:

Drag and drop with horizontal separator

In this screen shot, I am about to drop a track called “Quicksand” exactly between track #1 and track #2 in my playlist.

The problem occurs when I try to rearrange tracks that I have already dropped in the playlist. As indicated above, Mac OS X supports all kinds of click-through behaviours. In this case, even though the playlist is in a background window, I can actually click on an item in my playlist and hold the mouse button down and drag, and Mac OS X will appear to let me drag the item around without my having had to bring the playlist window to the foreground first:

Drag and drop in background window

The problem, as you can see in this screen shot, is that, even though this appears to be a legitimate user action, iTunes fails to display the horizontal separator under my mouse pointer to indicate where the track that I am currently dragging will be dropped.

And in fact, if I do attempt to drop the track that I am dragging (here with my mouse pointer at the very top of the list, thereby indicating that I want to move that track to the top of the list), iTunes will move the track… to the very end of the list, regardless of the position that I am trying to specify with my mouse pointer!

This strikes me as a very poor implementation of click-through. Either you support click-through or you don’t. But you can’t appear to support it, and then fail to support it properly and trigger some kind of unwanted, unpredictable behaviour instead.

Of course, if I click once on the playlist window first to bring it to the foreground, and then drag-and-drop the track, everything works just fine.

But the problem is with what happens when the playlist is a background window. Clearly Apple decided support some user actions—namely, here, the ability to click on a background item and drag it—but not all of them. I can click on the background item and drag it, but I am only supposed to do this if I want to drop it on a destination other than the playlist window itself!

Yet there is of course nothing in the iTunes interface that actually prevents me from dragging an item in the background window and dropping it elsewhere in the same background window. But the result is completely useless! It always moves the track to the bottom of the list, regardless of the position of the mouse pointer in the background window.

Let’s compare this to what happens in the Finder. The Finder itself supports all kinds of click-through actions. If you have one Finder window in the foreground and another Finder window in the background, you can click on an item in the background window and drag it to another destination somewhere in that same background Finder window (for example, a folder).

When you do that, the Finder accepts the action and correctly moves the item to the destination you indicated with your mouse pointer—and it also brings the Finder window in question to the foreground, because clearly that’s where you want to be now.

This is the exact same situation as in iTunes, and clearly the iTunes behaviour is wrong whereas the Finder behaviour is right (for once!). Sadly, however, this means yet more inconsistency for the user to contend with in the Mac OS X interface.

I realize that Apple’s engineers probably have “bigger fish to fry,” i.e. more significant bugs to deal with. But there used to be a time when this level of attention to detail didn’t seem to be beyond the scope of what Apple’s engineers were able to deal with. These days, on the other hand, this kind of inconsistency occurs all over the place in Mac OS X, and there is no indication that any of it will be fixed in the foreseeable future.


Comments are closed.

Leave a Reply

Comments are closed.