Chris's Wiki :: blog/tech/OverlappingWindowsThoughts

When overlapping windows do (and don't) make sense

July 12, 2008

The more I think about it, the more I think that there are a number of conditions that need to hold in order for overlapping windows to make sense (or at least to be attractive). I also think that these conditions are not necessarily all that prevalent, which may go a long way towards explaining why tabs and maximized windows are so popular.

First, small displays lead to maximized windows (and thus tabs) because there isn't enough space to go around. This isn't just resolution, it is also the physical size of the display, since you need windows that are big enough to read no matter how many (or few) pixels are involved.

Once you have physical space and enough pixels to do something useful with it, you run into a paradox:

The best way to use overlapping windows is to arrange them so that they don't overlap.

It's rare that you need to see only part of a window, which is the only time that significant overlap is useful; at other times you might as well iconify the mostly covered up windows. So to be happy with overlapping windows, you need to have enough space and to set up an organizing scheme so that they don't usually overlap. If you don't, overlapping windows will just irritate you (especially if your window system auto-places them in bad ways), and I suspect that this is one reason that many people don't like and don't use overlapping windows very much.

Or in short: the best way to use overlapping windows is to tile them most of the time, and overlap them only occasionally when you really need it.

Unfortunately, setting up an organizing scheme for this is a lot of work. Not only do you have to figure out where you want things to go and how to fit everything in but you have to carefully make sure that all of your windows are the right size and stay the right size, often without very good tools for it.

(I have an entire set of infrastructure to make sure that my terminal windows come out right and for resizing things into the sizes that I have determined tile together the way I want them to. As a result I am fanatical about things like the width of my browser windows, because if they grow too big my tiling scheme breaks down.)

Comments on this page:

By rdump at 2008-07-12 23:54:20:

I'm forced to deal with a web-based ticketing system that has a number of bad assumptions regarding window width. It could be a poster child for why you don't want full screen takeover.

This app actually attempts to hard-wire the web browser window width. Amusingly (in a very sad way), the developers' chosen width is wider than the display on a couple of my machines. Even when I'm on a machine that has a display wider than 1400 pixels, however, I'm not seeing a significant portion of the buttons and pop-up menus without doing a lot of back-and-forth horizontal scrolling. Compounding the problem, the buttons and pop-ups which are "mandatory" selections are scattered across the entire interface. It's quite the usability disaster.

Worse, the developers in charge just don't seem to get the fact that they're sharing screen real estate with other work. Their advice is to just maximize the window to take up the full screen. Aside from this not being workable due to their app wanting a wider display than I often have, it's also fundamentally disrespectful of everything else I'm doing.

My browser windows are set to a given width in order to fit in with the rest of my work on the same screen. Changing that is not done lightly, if at all, as most browsers tend to remember any size change, and use it as a default for new windows. This means one encounter with that web-based ticketing system results in disruption of real work.

In my quest for workarounds, I did find one browser that will open all new windows using a standard width regardless of what resizing games were done on previous windows. However, this merely led to the discovery that the web-based ticketing system is really an IE-based ticketing system, with an occasional nod to Firefox. Its scripting has all kinds of leaks and infinite loops built into it. The answer to bug reports is "that's unsupported." So we're stymied by the recalcitrant vendor, who already has our money and is therefore done with us.

In the end, it's tremendously insulting of any developer to demand that I mess up all the rest of my work to accomodate a misdesigned web interface which in effect tries to force maximization of all my web browser windows. I'm not liking this shoddy ticketing system, to say the least.

From 168.158.30.235 at 2008-07-17 23:40:27:

I have always been more productive when I'm able to turn off most kinds of window raising. I grew accustomed to non-auto-raised windows using twm, the Tab Window Manager for X11R4.

The default behavior for Microsoft Windows, and metacity under GNOME, is to bring a window forward when you click in it. Anywhere. Plus, in order to activate a window at all, you have to click in or on it. I don't know how MacOS works now, except that OS 8 and below were also this way.

For Windows users, installing the PowerToys gets you an Xmouse control panel, which permits settings for "focus follows mouse," and also an option to auto raise a window after N milliseconds, or not. However, many Windows apps do not expect this environment, so your UI might act strangely if this is always on.

I used metacity quite a bit more, but on my desktop I've recently moved to compiz. metacity has a setting for "focus follows mouse," but no obvious setting to disable click-raise behavior. Now, compiz has a zillion settings, and I was finally able to find a way to turn off click-raise, and evidently it is something which metacity obeys from the GConf system, because when I briefly switched back to metacity, it was still operating with that setting the way I wanted it.

So, the moral of the story is that I can overlap some windows, and be able to switch to one and type something into it, or even click through a menu or something, without having it raise to the front and obscure my main window. My main window is usually a web browser; my accessory windows include a gnome-terminal instance running TinyFugue, and an OpenOffice Calc window with a spreadsheet where I can enter data from a web page.

Written on 12 July 2008.

«	The case of the mysteriously failing connections

The problem with big RAID-5 arrays