The Persistence of Click-Through
Most people probably haven’t heard of click-through, which is the ability to click on the buttons of background windows. Maybe a few have noticed it, and many people have unconsciously been annoyed by it, but discussion of click-through is left to the geeks. Geeks like John Gruber, back in 2003. He wrote a series on click-through, which was becoming increasingly prevalent in Mac OS X. It began while discussing the differences between iTunes (which does not have click-through) and Safari (which does), continuing with a lengthy discussion on why click-through is wrong and finishing with what Apple should do about it.
Not only are all of these still relevant, upsettingly, they are now more relevant. Click-through is rampant. It is enabled in most applications, particularly almost all of Apple’s own applications, and Apple’s own implementation of click-through is wildly inconsistent. In iCal, the bottom bar, the to-do list, the mini calendar, and, of all things, the calendar itself all support click-through. Whereas the title bar and the list of calendars do not. Even Aperture, one of Apple’s newest software, not only supports click-through, but retains mouse-over animations: when Aperture is in the background, mouse over one of the sliders on the ‘Adjustments’ tab.
Gruber’s articles are still worth reading. His argument boils down to:
- Click-through is rarely useful, at most saving the user a single click.
- Click-through is more often disruptive, causing an action that the user never intended.
- Apple is making a mistake by neither encouraging nor discouraging click-through in the HIG.
- Apple needs to make click-through disabled by default via its Cocoa API, and then Apple needs to disable click-through on all of its own apps.
In Real Life
One of the primary arguments for click-through was “I can see a button, I should be able to click it”, as though GUIs behave like real world objects. This really argues that the distinction between background and foreground windows is unnecessary. But, as Gruber argued, the distinction between active and inactive applications is integrated into the Mac UI, and has served it well for decades.
This pro-click-through argument was much easier to make in 2003 for one main reason: brushed metal. And 2003 was pretty much the year of brushed metal: iTunes and QuickTime had already long since had brushed metal, but in January 2003, Safari also released with brushed metal. Later that year (after Gruber had written these pieces), OS X Panther was released, bringing brushed metal to other applications, namely the Finder.
One of brushed metal’s many problems was its windows looked almost identical when active or inactive. The only thing that changed was the close-minimize-zoom buttons, the title bar text color and, maybe, the buttons. At a glance it was pretty much impossible to tell the difference. The ‘normal’ Aqua windows of the time weren’t much better. An active Aqua windows had a light-grey, almost white, title bar, with pinstripes everywhere else. An inactive Aqua windows had a non-gradient pinstripe title bar (with inactive close-minimize-zoom and title text), leaving the pinstripes as they were. The difference was between a ton of pinstripes and a ton of pinstripes.
The point is in 2003, the visual distinction between the active window and inactive windows was not immediately obvious. It was entirely conceivable that what someone thought was the foreground window was, in fact, a background window. Why shouldn’t it support click-through?
Leopard
As of Mac OS X Leopard, though, this no longer holds water. Leopard refreshes the UI, taking OS X closer toward iTunes. In particular, Leopard brings two changes to windows — brushed metal is gone and the Aqua theme’s active and inactive versions are now much more distinct. See for yourself:
Active windows have a dark gradient and a deep shadow, whereas inactive windows have a light gradient and a shallow shadow. The text color doesn’t change, but that’s only to signify that it supports click-through (Go ahead. Just try clicking calculator to the front without clicking on a button.). It is now pretty damn easy to, at a glance, tell which window is the active, foreground window. More importantly, it is just barely less than obvious which windows are inactive.
Which makes support for click-through all the more absurd. Whereas before the train of thought was “I see a button, I should be able to click it”, with Leopard the train of thought is closer to (I hope) “I see a button, but its window is in the background so I’ll need to click it to bring it forward first”. Whereas click-through was slightly obnoxious back when there was little difference between active and inactive windows, now it’s becoming disruptive and confusing. “Huh? Wait, I thought that window was in the background.”
Apple seems to have two separate, conflicting plans for window UI. On the one hand, they are making strides to further distinguish active and inactive windows. On the other hand, they are actively making inactive windows behave like they were active, leaving click-through enabled by default and building the ability to scroll a background window. As Apple makes more and more progress toward each of these objectives, the contradictions are going to become more and more evident.
Apple needs drop one of these goals, and it should be click-through. There is little indication of them actually doing that, though. They’re discouraging the Carbon API (which, by default, does not have click-through) by not bringing 64-bit support to it. And Cocoa (which enables click-through by default) is becoming the de facto API for Apple products, both on the Mac and now the iPhone.
However, Snow Leopard is well into development. And its primary purpose is to clean up OS X on the developer’s side, while not focusing on end-user features. I just hope that UI consistency is on their list. Apple needs to either have the entire UI have click-through or, much preferable, none (with room for exceptions) of the UI have click-through. Snow Leopard is their big chance to declare which of these conflicting objectives they will, in fact, follow from here out.
UPDATE on 10 July 2008: Tightened up a few of the paragraphs, especially in the introduction and conclusion.
