- # Aw, you really shouldn’t have
John Gruber’s latest thoughts are on the issue of “click-through” in Mac OS X — what it is, and how it’s often misused. Only one problem: John quotes me. Nothing wrong with that in itself, of course. But in doing so this time, he appears to have confused two unrelated topics, making his otherwise compelling argument rather less convincing. So, let’s review.
All window managers suck. (At least, all the window managers I’ve ever used, and no, please don’t e-mail me just to tell me what your favorite disaster manager is.) Actions that would take only a second or two, with real pieces of paper on a real desktop, often take many times as long to do with windows on a computer screen.
One such action is layering windows — bringing one window in front of another. This is something you often need to do if you’re performing actions which involve two or more windows, such as dragging stuff from one to another.
The Mac OS, historically, has made layering windows pretty easy to do (as long as you can see at least part of each one). It lets you click any part of a window to bring it to the front, without worrying about whether there’s a button or anything else important at the place where you’re clicking. Where programmers make an exception to this rule, allowing a click in a background window to activate a control as well as bringing the window to the front, it’s called “click-through”.
To indicate the usual lack of click-through, undraggable items in background windows — those which don’t do click-through — are supposed to appear inactive. (This has the additional benefit of reducing screen clutter.) This is where I think John gets a bit confused. He says:
As stated earlier, applications that do not support click-through invariably [sic] disable the controls in background windows, such that they don’t look clickable. Yes, this still requires new users to learn about the concepts of the frontmost window and active application …
Whoa, stop right there. Making controls inactive in background windows does require new users to learn about the frontmost window, yes, but it does not require them to learn about the active application. You see, background windows belonging to the active application appear inactive in exactly the same way as background windows in any other application do. This behavior is everything to do with windows, and nothing to do with applications. (The existence of applications does have some odd effects on window layering in classic Mac OS, but that’s regardless of the presence or absence of click-through.)
Now of course, you could take a step back and say that the problem is that there shouldn’t be any distinction between different applications …
And away he goes, constructing a straw man of invisible applications, then knocking it down as part of explaining why click-through is usually bad. Unfortunately, application-centricity and click-through have nothing to do with each other.
So where were we? Ah yes, Mac OS makes layering windows easy to do. Microsoft Windows, on the other hand, makes it hard to do. (Alt+Tab is very nice, and more efficient than the Mac equivalent, but few people know it exists.) If you click in a background window in Windows, not only does it come to the front, but any control that happened to be under the pointer where you clicked also gets activated. The only universally safe area to click, to bring a window to the front, is its taskbar button. (On the plus side, the taskbar does solve the problem of switching to a window which is completely obscured by other windows in front of it.)
This default click-through behavior, in turn, encourages people to maximize windows, so they won’t have dangerous bits of other windows lurking in the background.
This, in turn, makes it much harder to do things involving multiple windows, since you only have one window visible at a time.
This, in turn, encourages designers to invent redundant and non-spatial methods of doing things which would normally involve multiple windows. Examples include copying/pasting files in the file manager, most of the buttons in the Windows Explorer toolbar, and most of the items in a Windows XP Explorer task pane.
This extra complexity, finally, means that no matter how often you personally layer your windows, the Windows interface is more complicated overall than the Mac interface. The extra complexity isn’t solely the fault of click-through, mind you, but it’s a substantial contributing factor.
It is possible, of course, for developers on either platform to override the platform’s usual behavior. For example, in Mac OS versions 7 thru 9, the Launcher applet allows click-through — you can click any of its buttons without bringing it to the front first. And in Windows, Microsoft Word 2000 and Excel 2000 do not allow click-through — in contrast to most other applications (including the others in Microsoft Office), clicking in a background Word or Excel window will bring the window to the front and do nothing else. (What, you never noticed? Of course you didn’t notice! You had all your windows maximized the whole time!)
However, defaults are important, and this is just as much the case for developers as it is for users. APIs can be designed to encourage, discourage, or even prohibit good user interface design by developers. And in Mac OS X, it appears, the defaults for click-through behavior are a shambles.