Mac OS X 10.3 Panther

I think we've all seen a computer user lose track of a window. It's tempting to think that only "novices" have this problem, but the truth is that everyone has a limited short-term memory capacity. If you keep opening new windows long enough, eventually you will have to actually "hunt" for one, even if you were just using it moments earlier.

Most geeks have experienced the opposite of "hunting"  that effortless experience of simply thinking about the window you want and letting your mouse- or keyboard-hand do its magic trick to make the window appear. For long-time Windows users, surely the alt-tab keyboard combination factors heavily in this experience, particularly for switching back and forth between two windows. Geeks that are skilled at internalizing the structure of the window list (programmers are especially good at this) can alt-tab across even large window lists with absolute certainty and very little thought.

Nevertheless, even an alt-tabbing guru (and especially a programmer) knows that a linear list has performance characteristics that don't scale well at all. Furthermore, even given a fully-formed mental model of a simple window list, it is frustratingly inefficient to be forced to traverse all intermediate elements to reach a destination. If a user knows where a window is in this admittedly inefficient list structure that he's maintaining in his head, why can't he jump right to it rather than hitting alt-tab five times?

So there are a few problems here. First, there's the structural model used by the computer to organize windows. It helps if this model is as "brain friendly" as possible. A "stack" or other one-dimensional structure is relatively easy understand, but it can very quickly bump into the limits of short-term memory as elements are added. Moreover, even for users with a complete, detailed model of the window stack in their infallible short-term memory, it's frustrating to be forced to walk the list one element at a time.

So how do you design an interface that's both "brain friendly" and allows the user to immediately jump to the exact window he wants at any time? Personal computer input devices limit your choices somewhat. The keyboard is not really designed for this task. Chorded key sequences are the traditional form of out-of-band signaling for keyboards, but there are a limited number of convenient combinations.

Alt-tab (command-tab to Mac users) is one of the more comfortable chords, and is fittingly used for task switching. But there's no easy way to specify a particular window with just a single chord. Hardcore geeks may be thinking of something like alt-tab-5 to jump to the sixth window in the list or some such, but at that point we have long since left the realm of interfaces that are usable by "normal" people. (Don't worry, vi will always love you.)

That leaves us with that "toy computer" input device: the mouse. The mouse is great at saying "that thing right there." Why not "that window right there"? It seems like a perfect fit, but there are a few problems.

If you spend most of your time typing, there is some amount of overhead associated with simply moving your hand from the keyboard to the mouse. Dedicated alt-tabbers will no doubt cite this as a reason that it's faster to hit alt-tab
n times rather than reach for the mouse. (Choose your own value for n.)

Assuming you are willing to accept the context-switch overhead (or that your hand spends more time on the mouse than the keyboard anyway) what are your options now? Well, in true geek fashion, many OS developers have instinctively created on-screen representations of the good-old linear window list structure previously buried in the OS. The Windows taskbar started out like this. Say what you want about the Windows 95 taskbar, that little row of rectangles on the screen was worlds better than the alternative of asking users to create and maintain that structure in their own minds. Perhaps there's a lesson here...but for now, let's move on.

So now your mental model has come to life on the screen. You don't need it in your head at all anymore. The order and position of each element in the window list is effortlessly (as far as you're concerned) maintained by the operating system on your screen.

But it does become tedious to scan that on-screen list for the window you want, especially when each tiny rectangle doesn't have enough identifying information. (Can I interest anyone in seven taskbar tiles all named "Internet Explor..."?) So it is advantageous to at least remember the position on the screen of the handful of tiles that you are switching among most frequently.

Then you (possibly) pay the mouse-switch toll and click on the taskbar tile on the far-right, and then the one in the middle with the blue icon, and so on. Okay, maybe it's not entirely unconscious, but hey, it is direct access rather than forced traversal of the window list. We're making some progress.

We can also address the computer's organizational model. A one-dimensional list causes problems when there is a limited amount of screen space. A two-dimensional model where windows are nested under their parent applications drastically reduces the screen real estate needed, but it also adds one more step to the process of getting at a particular window. Is it a net win? That depends on how many windows you have open. A hybrid model that starts linear and then goes hierarchical when screen space gets tight may be a nice compromise. This sounds a lot like where the Windows taskbar is today.

The Mac had the first mass-market GUI, and yet for over a decade it lacked almost all of the features described above. "Sure, that's because the Mac couldn't multitask for most of that time!" you may sneer. But even pre-Switcher (no, not that switcher), a single application could have many open windows. So window management was always an issue on the Mac, and it was an issue on the Mac first. What was Apple's solution?

Whatever merits alt-tab may or may not have, it was out of the question in the early days of the Mac because Apple wanted to do everything it could to get users to use the funny little box with a ball in it that dangled from each Mac. Perhaps more importantly, Apple wanted to force Mac developers to create Mac-like interfaces rather than simply porting keyboard-based interfaces from the PC world. The original Mac keyboard didn't even have arrow keys on it!

So did Macs have some sort of on-screen palette with buttons or tiles representing windows? Nope, nothing of the sort until at least a decade later. But surely each application had an OS-provided menu containing all the open windows in each application. Granted, picking your window from a pull-down menu isn't very efficient, but you at least need such a menu to exist as a last resort...don't you? Nope, that feature didn't arrive until Mac OS 9.

Okay, then how the heck were Mac users managing windows for that first decade or so? (Oh, how you wished mightily that you were going to make it through this article without seeing this word, but your luck has run out, my friend.)

(cue dramatic music) Spatially.

I've written about this topic before, and I'm going to write more about it later, but you only need the survey course in order to follow along here.

So, the answer to the Mac window management riddle? Why, Mac users simply pointed to the window they wanted and then clicked on it. ("You do know how to click, don't you Steve?" Oh, never mind.)

Come now, you say, obviously that is not a workable "solution." First, windows overlap. How can you click on a window that is entirely obscured by another window? Second, without some sort of list, whether one- or two-dimensional, somewhere in the OS, how will the user even know which windows exist? "Just click on the window you want" indeed!

Maybe it will help to recall that the Mac spent most of its life with a two-dimensional window layering policy. Windows were layered within each application, and then each application's window collection was layered amongst the other applications. So right away, the choice of windows (and therefore the odds of "catastrophically-obscuring window overlap") could be reduced significantly by bringing a particular application to the front. In classic Mac OS, merely clicking on any window belonging to an application would bring all the windows in that application's layer to the front.

But even just one application can have a heck of a lot of open windows. We're still left with a seemingly intractable problem: a big mess of overlapping windows. How is a user supposed to make sense of that?

The answer is probably right in front of you right now if you're sitting at your own desk. People are innately adept at molding their environment to suit their needs. All they need are the right tools. In life, you can get pretty far with just your own (fancy, opposable-thumb-sporting) two hands. On the Mac, you can get surprisingly far with just the mouse.

The Mac user interface guidelines helped by specifying that applications
should conveniently tile newly created windows (slightly lower and to the right
with each successive window) in an attempt to leave the title bar visible for as
many windows as possible. But scanning a stack of tiled windows and reading each
title bar is no more efficient than an on-screen window list. Perhaps what the
computer cannot do for the user, the user can do for himself . . .

That's right, Mac users actually manually arranged their windows like so many pieces of paper on a desk. Insanity! The height of inefficiency! Au contraire. I won't bore you with the details yet again, but suffice it to say that there is a vast well of cognitive resources just waiting to be tapped by a bunch of boringly coherent and stable objects on a screen.

Just watch an old-school graphics designer using classic Mac OS (if you can still find one in the wild) switch among a seemingly overwhelming sea of windows faster than you, as a mere observer, can even identify what they are. The user knows what they are because he knows where they are, and where they'll be the next time he needs them--they're where he put them.

In short, identifying windows based on their size, position, and appearance (i.e. spatially) is massively efficient and imposes the absolute minimum cognitive load on the user. This is what people do best  not memorize, maintain, traverse, or chose from lists or tree-like data structures, but recognize and manipulate coherent, stable objects in space (virtual or otherwise).

That being said, there is a limited amount of screen space, after all. Eventually, there will be no place left to put your windows, or there will no longer be enough spatial distinction between windows to identify them. The screen starts to look a lot less like a bunch of objects in space and more like a slightly fancier graphical representation of a window stack data structure. This is bad news.

Luckily, we have all the techniques described earlier to fall back on. We have keyboard chords which, in Mac OS X, can be used to switch among applications (cmd-tab), and among windows within an application (cmd-`). Unlike classic Mac OS, Mac OS X does not confine windows to their parent application's layer; it allows the interleaving of windows from multiple applications. But per-application layering can be still be requested (e.g. by clicking on a Dock icon).

The Dock itself provides a two-dimensional taskbar-like structure for windows, with each application's icon sprouting a list of all its open windows in a pop-up menu. Each Mac OS X application also has an OS-provided "Windows" menu, and many applications also offer their own floating palettes listing all open windows. Finally, there are innumerable third party floating palette thingies that can aid in window management.

Still, it'd be nice if the screen space limitation could be dealt with somehow. Keyboard chording and selecting from lists are reasonable fall-backs when screen space gets too tight, but "just click the window" is really where it's at in terms of efficiency. Obviously we all just need bigger screens
. . . or do we?