Window States

A programmer would call an application's primary window its top-level window. The intrinsic behavior of a top-level window includes the capability to overlap other top-level windows, but this is not how they are normally used. Each top-level window has the native capability to be in one of three states (in Windows and some Unix GUI platforms), depending on how they are programmed. Oddly, only two of these three states have been given names by Microsoft: minimized and maximized.

In Unix GUIs like Motif, and on pre-95 versions of Windows, minimized windows were shrunk to boxy icons (usually larger than normal desktop icons) that stacked on the desktop. As of Windows 95, minimizing a window collapses the window into the button that represents it on the taskbar. Maximized windows fill the entire screen, covering up whatever is beneath them.

Microsoft somehow manages to avoid directly referring to the third state, and the only hint of a name is on the system menu (click the upper-left corner of the title bar to see it) where the verb Restore describes how to get to it. This function restores a maximized or minimized top-level window to that other state. In the interests of sanity, we will call this third state pluralized, although it has also been called restored.

The pluralized state is that in-between condition where the window is neither an icon nor maximized to cover the entire screen. When a window is pluralized, it shares the screen with icons and other pluralized windows. In Mac OS X, all windows are pluralized if they aren't iconized (Mac OS 9 only permits windows to be collapsed to their title bars, not fully iconized). Pluralized windows can be either tiled or overlapping.

Back in the days of Windows 1.0, the states of minimization and maximization were called iconized and zoomed, terms that were more descriptive and certainly more engaging. IBM, then enjoying a cozy relationship with Microsoft, demanded the change to corporate-speak in the mistaken impression that America's executives would feel more comfortable. The weaker appellations have stuck.

The normal state for a sovereign application is the maximized state. There is little reason for such a program to be pluralized, other than to support switching between programs or dragging and dropping data between programs or documents (the latter could be cleverly accomplished using a toolbar control instead). Some transient applications, like the File Manager or the Explorer are appropriately run pluralized, but these transient programs are used primarily as springboards for sovereign applications.

Why minimize?

Any application in Windows can be minimized, but why go to the trouble? On systems without a Taskbar or similar idiom, it is often necessary to minimize to switch from one application to another, an ungainly procedure. You minimize the active program (which was likely maximized), then maximize (or pluralize) the icon of the desired program—if it isn't already pluralized or maximized, but lurking behind the previous application. To switch back, you reverse the sequence. You must move the mouse all over the screen; and the process is slow, complicated, and tiresome.

The Windows 3.x Alt+Tab key sequence was a much more useful method of switching between applications (and still supported even in XP). However, it's obscure, not visual, demands a high level of user expertise, is relatively unknown outside of the power-user community, and operates unlike any other idiom in Windows. Pressing Alt+Tab moves you quickly and directly to the next running program. Holding down the Alt key and repeatedly pressing the Tab key cycles you through each running program. It does this by showing a small window in the center of the screen with the name and icon of the candidate program. The trick is that the actual selection of a program occurs when the user releases the Alt key! Nowhere else in Windows does an action occur on the release of a shifting key. This idiom is weird enough that most people don't know about it, and learning it can be difficult. After the idiom is learned, however, it is a remarkably fast way to navigate between applications. Besides the speed of the technique for switching from program to program, the great advantage is that the various programs can each remain in their natural state, either maximized or pluralized, but usually maximized.

The Alt+Tab idiom is a classic example of how a programming team can ingeniously solve a significant problem that baffled the experts. Many sharp software designers tried to create convenient program-switching idioms, but none are the equal of this one. The solution is brilliant, but virtually undiscoverable—it's not documented and it doesn't appear on any menu, so someone must tell you about it. The solution is fabulously economical in overhead but requires a deep familiarity and dexterity with the computer, coupled with a clear sense of dominance over it—a good description of your average code-slinger. What we really needed was a more benign version of Alt+Tab that wasn't just for power-users and hackers. In Windows 95, we got this solution with the Taskbar.

The Windows Taskbar finally acknowledges that most people want to work on one maximized sovereign application at a time, and that they want a more accessible idiom for accomplishing this. A significant slice of the screen's real estate is devoted to this ever-present gray bar, but it is worth it for everyone but the most hard-core programmer (who can always hide it). The Taskbar contains a button for every running program/open document, regardless of its current state (except daemonic posture programs, and even some of these make it into the status area). The button for the active program is shown in its pushed-in state.

The Taskbar is a simple and visual implementation of the Alt+Tab idiom: You click the button of the application you want and it moves to the front of the screen and becomes active. If it was last in a maximized state, it will still be maximized. If it was last in a pluralized state, it will still be pluralized and in the same position it was in before, just moved to the top of the window pile. If it was minimized, it will open to its prior maximized or pluralized state. You can imagine the running programs as channels on your TV—pressing buttons that allow you to jump from channel to channel.

The other reason to minimize a program is to reduce clutter on your screen. If you run several pluralized sovereign applications, it can simplify your screen to minimize some of them. However, this is treating the symptom rather than the cause of the problem. If each application is maximized in turn, there will be no apparent clutter, and minimizing won't be necessary, as long as you have the Taskbar or the Alt+Tab to navigate between them. The only remaining rationale for minimization is to clear space to get at icons on the desktop. The Taskbar in windows includes a button in its quick start area that instantly minimizes all windows. On the other hand, Windows 2000 and XP Taskbars include a desktop access toolbar that eliminates even this need (although this feature is off by default).

Current versions of Windows remove the few rationales for minimizing a program. Managing your programs as a set of channels is superior given adequate tools. The Alt+Tab has long allowed power users to work this way, and the Taskbar finally brings the capability to the rest of us.

Minimized applications before the advent of the Taskbar, as well as those on Unix GUI platforms, were sometimes used in innovative ways to display dynamic or animated status information. This is still the case on Unix, and it may end up being the case for Mac OS X, now that it has true minimized apps but no fully maximized ones. But on Windows, using items on the desktop to display useful information has all but died as an idiom, as programmers have come to realize that maximized program windows almost always obscure these items.

Why pluralize?

Is there any reason for a program to be pluralized? Well, maybe. Sometimes obscure situations require two or more programs to be juxtaposed. If all the user wants to do is run one sovereign program after another, with a sprinkling of smaller transient programs temporarily overlaid on them, pluralization is unnecessary. If the user wants to cut and paste information between sovereign programs, the clipboard will work just fine. However, if the user wishes to take advantage of the program-to-program drag-and-drop facility, the two programs doing the dragging and dropping must both be visible, sharing the screen. In other words, both programs must be pluralized. At least this was true until the advent of the Taskbar in Windows, which allows you to drag and hold an object over a minimized application to open it. Although this idiom requires some excise dragging, it eliminates excise window manipulation: Take your pick.

Modern XGA computer screens range from 640×480 pixels to 1600×1200 pixels. 1024×768 is probably the most common resolution at the beginning of the 21^st century. In such limited physical environments, modern sovereign programs such as word processors or graphics programs are difficult and unpleasant to use when they own less than half of the screen. When giving demonstrations to the press or captains of industry, Microsoft proudly demonstrates the drag-and-drop of a spreadsheet into a word processor. The windows of the two applications are carefully posed in advance to illustrate this single function in isolation. What they don't show you is that the management overhead of pluralizing two windows and then adjusting them manually so that each one gets sufficient exposure is considerably greater than the management overhead of using the clipboard and Taskbar and merely swapping between the two sovereign programs.

Program-to-program drag-and-drop is a powerful idiom, and one that we may see with increasing frequency in the future. However, we won't see it used too often between sovereign applications until our computer screens get a lot bigger, which doesn't promise to happen for several more years. However, program-to-program drag-and-drop can be a boon for moving information between a sovereign application and a transient application. For example, look at the process of adding a piece of clip art to a word processing document.

The word processor is the sovereign application, and it is running maximized. The clip art librarian is a transient application and would normally run as a fixed-size window approximately one-quarter of the full size of the screen (one half of the width and one half of the height). The clip art librarian could be easily positioned in the least obtrusive quadrant of the screen and, after the desired image is located, the image could be dragged directly into the appropriate place in the word processor. Another click and the clip art librarian is stored away on the Taskbar, and the user can proceed. Window management overhead is a mere two clicks, one to open and one to close the librarian, with a possible click-and-drag operation to move the librarian out of the way so the critical area of the word processor's display can be seen more easily. Neither application needs to be pluralized.

Windows software can be effectively built without supplying the capability to either minimize or pluralize. Programs occupying the in-between state of pluralization are dying out, and Windows is helping to kill them. The programs never have to pass through the pluralized or minimized state. Of course, that doesn't mean that you can actually dispense with these options. You must be able to minimize for backwards compatibility, and every program that can maximize must be able to be pluralized for those cases when a user needs to tile the screen with the application. Experienced users will probably be upset if the application can't acquit itself of this basic expectation, even though it is more an exercise in adaptability than in practical software design.

For practical purposes, we are left with only two program configurations: maximized sovereign programs and pluralized transient programs. The sovereign programs endure while the transient programs appear briefly on top of them. When you design your application, you must make this fundamental design decision: dominant or temporary. This will dictate the type of main window you will use.