Window management is too important to be left to such a low-bandwidth device as a mouse.
— Jim Mackraz

The behaviors of window managers

I started using computers with windowing systems as they are commonly understood in 1986, both at home and at work. Starting at that early date, I was exposed to a number of window managers, and know that they can be changed in ways that most people wouldn't consider, because they've never been exposed to a window manager that allowed them to change those things.

Two behaviors in particular radically change the way a window manager feels to the user, but can't be changed on popular desktop systems. They both center around the active window, which is the window that gets input from the keyboard. They are:

1. Whether a window becomes the active window when the mouse cursor enters it, or only becomes active after the user clicks on the window. These behaviors are called follow mouse and click to type, respectively.
2. Whether or not becoming the active window causes the window in question to become the top window on the screen. Automatically raising the active window is generally called auto raise, and we will call the alternative static.

Since there are two possible variations on each behavior, there are four possible window manager behaviors: auto raise with click to type, which is what most people are familiar with; auto raise with follow mouse, which is very annoying to watch and seldom used; static with click to type; and static with follow mouse.

Each of the four possible styles provides a radically different feel. Once a user is comfortable with one of those styles, they will not be comfortable using a window manager with any of the other styles. This is why modern windowing environments designed to accommodate the user will allow both of these behaviors to be set either way.

Another option not commonly seen is for a window manager to be paned. Non-paned window managers have windows wrapped in rectangular frames that can have nearly any geometry, overlapping in arbitrary ways. With a paned window manager the screen is divided up into rectangles such that they cover the entire screen. Each such rectangle is a pane, and windows must fit into those panes. Windows open to the maximum size that fits in the pane they are in. Windows can't overlap, because panes don't overlap. There have been a few paned window managers, but they aren't very popular, and I know of only two still in active use. I would appreciate hearing about others.

Because of the way windows are managed — or rather, not managed — by the user, a paned window manager has to have the auto raise behavior. While windows in other panes are irrelevant, as they can't overlap the currently active window, it is possible for another window in the same pane to be on top of the active window. Since all the windows in a pane have very nearly the same shape and position, failing to raise the active window to the top is liable to leave it completely obscured.

Oddly enough, paned window managers introduce a third alternative to follow mouse or click to type, which is to have the focus driven only from the keyboard. Much as a framed manager may allow the user to move between windows based on a keyboard sequence, a paned manager may allow the user to move between panes or directly to a pane with a keyboard sequence, and to cycle through the windows in a pane with a different sequence. Since the mouse isn't used to select, size or position windows, a paned window manager is free to ignore it completely.

With this behavior, it becomes possible to use the mouse to manipulate objects in a window that other than the active window. This is not possible with any form of framed window manager. Further, if the active window only partially fills a pane for some reason, then it may be possible to manipulate objects in another window in that pane with the mouse without changing the active window.

The behaviors of people

In the late 80s, I noticed that most people using windowing systems used them in one of two styles. Many people kept their windows nicely organized, almost as if the manager were paned, with specific windows in specific locations so they could find things easily. Other people seemed to lay windows out in a haphazard, or maybe not so haphazard, manner, with windows overlapping and seemingly everywhere.

It would seem that paned window managers would appeal to the former group of people. However, they can get a similar behavior from a framed window manager with just a little work, so there hasn't been much work on paned window managers. The two paned window managers I know of include ratpoison, which was modeled after a program designed to simulate multiple character consoles on a single such device; and the panes mixin for plwm. Plwm can be described as a window manager construction kit, and the panes mixin provides the ability to build paned window managers with it.

As the next section shows, having fixed panes allows for more efficient window management than having windows of varying size and position, as it makes sense to label the panes. This means that rather than cycling through active windows or having to use some form of graphics input device to activate a window, the user can go to the top window of a pane with a single character.

The behaviors of numbers

To compare the efficiency of window managers, I'm going to use the GOMS model developed by Card, Moran and Newell, as described by Raskin. It is used to make comparisons between two different methods of performing a task by creating a sequence of actions the user goes through with each method, assigning a fixed value for each type of action, and then summing them to get the time take to complete the task. The end result is a number of seconds for some action. It is incorrect to assume that it will take any user that number of seconds, or even an average user. It is correct to expect that the values will reflect the ratio of times it takes a typical user to perform those actions.

I'm not going to describe the methodolgy used to generate the sequences, as Raskin covers that in detail. The actions in a sequence and their assigned times are:

K

0.2 seconds; the time it takes to strike a key on the keyboard or a button on a pointing device.

P

1.1 seconds; the time it takes to move a pointing device to a point at a target.

H

0.4 seconds; the time it takes to move the hands from a pointing device to the keyboard, or vice versa.

M

1.35 seconds; the time it takes the user to prepare for the next set of actions in a task.

The sequences below assume the subject is working on some task involving typing: writing a report, filling in a spreadsheet, or any number of everyday tasks people do with computers. For some reason, action in another visible window is needed. The actions are activating it, typing in it, or some kind of mouse action in it. Given that, plus a GOMS model, we can numerically rate the efficiency of each styles of window manager. Since auto raise is irrelevant to the sample tasks, we only need to consider three types of window managers.

GOMS timings for actions with three different window manager styles

	Actions	Activate new window	Mouse action in other window	Type in other window
Manager types
Click to type	Sequence	H M P K	H M P K M K	H M P K H M K
	Time	3.05	4.6	5.0
Follow mouse	Sequence	H M P	H M P M K	H M P H M K
	Time	2.85	4.4	4.8
Paned	Sequence	M K K	H M P M K	M K K M K
	Time	1.75	4.4	3.3

As the table above shows, the least efficient style for a window manager is "click to type". That it is also the one used by most people is unfortunate, and if anyone cares to estimate the number of years of life wasted by hundreds of millions of people using click to type instead of follow mouse, I would be interested in the results.

The most efficient is the paned manager, taking about two-thirds of the time taken by a follow mouse style manager for any task that doesn't require the mouse. The reason it is more efficient is obvious — the user doesn't have to find the mouse from the keyboard. While I didn't analyze tasks involving windows that aren't visible, paned window managers do equally well there, as activating a hidden window in the current pane is also done without needing to access the mouse.

The reason that paned window managers aren't popular is just as obvious — it requires the user to learn the appropriate keystrokes to change panes, or to activate windows. As someone who uses a computer several hours a day, many days a week, I find that the time to learn the keystrokes a small price to pay for a window manager that is that much more efficient than the other alternatives for those common activities.

My behavior

Which brings us to my window manager. It is obviously a paned window manager. It uses the plwm package. This package allows users to construct a customized window manager with very little effort. I can move to an exposed window with a single character. Two characters brings up a menu of all windows, windows occupying the current frame, or windows not associated with any frame. Those menus allow a selection with a single character, or with arrow keys or editing motion keys. This particular window manager is available in the plwm package as an example, plpwm. If you are running a system that uses X for window management, you might want to take the time to learn it. Better yet, take the time to customize it to your tastes, use it for a while, and see if you aren't more productive.

Citations

plwm. http://plwm.sourceforge.net/, March 15, 2002.

Raskin, Jeff. The Humane Interface, pg 71-76. Boston: Addison-Wesley, 2000.