Rethinking the Window

Litestep is probably one of my favorite Windows apps. As a litestep developer (the word “programmer” doesn’t seem right here) I do a lot of thinking about efficiency; ways of making desktop environments that are more fluid and intuitive than the one that comes with Windows. At the same time, coding litestep themes makes me painfully aware of the things I can’t control.

In lecture, a couple of weeks ago, Prof. Harvey showed a video of Alan Kay discussing UI design. It’s an excellent video that discusses a number of major breakthroughs in human-computer interaction. At one point, he starts going over the capabilities of the infant Smalltalk environment. One of the things that gets him most excited is the ability to create and manipulate windows. It was a revolutionary idea at the time, and one that has stayed with us to this day. But why?

Obviously, an idea doesn’t stick around this long without having some merit. The metaphor of programs as little, self-contained boxes full of content is a powerful one. In a threaded, multitasking environment, it’s convenient to have everything on the screen at once. It’s also critical to be able to compare and transfer content across applications and windows, and compare things side-by-side. Windows are friendly and understandable.

But can we do better?

In spite of the massive plasma displays they’re turning out nowadays, screen space is a real concern. Ideally, we would be able to use 100% of the screen to display our content, with no “dead space” (Figure 1). Maximized windows can do a perfectly acceptable job of this.

Figure 1

The difficulty starts to arise when there are multiple applications that need to be viewed and interacted with simultaneously. I remember one incident when I had to make nametags based on information contained in a spreadsheet. It involved a constant “type ALT+TAB look ALT+TAB type ALT+TAB”, and I was pissed off the entire time. If I had been thinking clearly, I would have taken the time to resize the two windows to fill the entire screen (Figure 2) and hopefully fit all of the information I needed. Instead, it ended up looking a lot more like Figure 3.

Figure 2

Figure 3

Indeed, Figure 3 is the archetypal “windowed environment” set up. One active window and one control mechanism (in green) and a whole lot of dead space (red). This is bad for two reasons.

1. Obviously, it wastes space. What good is your expensive new monitor if all you do is look at the picture on your desktop?
2. It wastes memory. Depending on the application, your machine may be putting a lot of effort into drawing a window that you’re not interested in.

It’s important to note at this point that you can make windows efficient - just like Figure 2 with the name tag example. The problem is that the window concept is not conducive to efficient use of space. Moving and resizing windows is a (relatively speaking) time-consuming process. What is necessary is a system that encourages and facilitates efficiency.

The way I always envisioned my ideal environment was one covered with a set of “frames”. These could be divided up by simply drawing or erasing lines on the screen. Applications would “project” their contents onto the frames created. A taskbar-style list of running apps would sit off to one side, and it just takes dragging applications off the bar and onto screens to show them where to display (Figure 4).

Figure 4

I thought I was the first person to come up with this idea until I discovered Emacs. Emacs uses a similar concept: “windows” display the contents of selected buffers, while other buffers reside elsewhere waiting to be displayed. While Emacs is a command-line app, the concept is basically the same, and I’m surprised it hasn’t been continued.

So what does it take to make this new setup a reality? Obviously, neither Windows nor Mac is about to risk a major interface change anytime soon, but a tweaked-out window manager for Linux might just do the trick. Time to start coding….