Window content management

Contents

• Overview
• Responsibility
• Facilities
  • Toolbars
  • Tool palettes
  • Panes
  • Scrolling window body
  • Tabs
• Concepts
  • Inactive windows
• Implementation

Overview

Responsibility

The controls page covers individual controls such as buttons and list boxes. At a more general level, there is a need for all manner of window content management. Responsibility for this may lie with the same framework as the control library, or it may have a library of its own. In either case, it would be separate from the Window Manager which is responsible only for the management of whole windows and, possibly, menus (where in-window menu bars would be placed outside of a window’s content area).

Some interaction between the Window Manager and the window content management may be necessary in order to deal with dividing the window’s content area into sub-panels, depending who is responsible for drawing the border around a window’s content area.

Window layout—especially dialog box layout—will be dynamic, to accommodate live resize, localisation and content scaling. Therefore there will need to be interaction between the window layout system and the control system to determine the size requirements of controls and to resize and potentially even rearrange controls accordingly.

Facilities

Toolbars

Whether toolbars are considered to be part of the window (how Mac OS X appeared to treat them) or part of the window contents (as is the case under Microsoft Windows) needs to be decided. Toolbar customisation is a complex facility that may warrant a library of its own. Toolbars alone can be a complex matter; Mac OS X introduced a standard but rudimentary toolbar system and Windows introduced a similarly simplistic ribbon, but more complex software can require multiple toolbars along multiple window edges. It is common for such toolbars to have inconsistent styling and behaviour at various levels, including customisation or the complete lack thereof.

Tool palettes

Tool palettes straddle the boundary between managed window content and higher-level presentation. Inkscape demonstrates a very good example of this objective; it supports multiple tool palette implementations in a clear and flexible way.

There are static toolbars embedded around the sides of the Inkscape window, whose contents can be interchangeable (in the case of the active tool controls) but cannot as a whole be undocked or moved. Most other palettes (Fill and Stroke, Document Properties, XML Editor etc) can be arranged by the user as they see fit. These palettes can be docked into side panels to either side of the window or displayed as floating windows. The side panels and the floating windows can take multiple palettes shown either as tabs, or sub-panels, or both. Being able to place lots of palettes side-by-side and above-and-below in a separate window allows for the user to dedicate a whole monitor to the editor window and place all the palettes onto a second monitor out of the way, in a configuration that is retained across program sessions.

The palette layout is memorised on program exit and restored on launch.

Panes

Windows may be divided into panes (or panels) with support for draggable dividers.

Scrolling window body

Not be confused with scrolling controls, the body of a window should itself support being larger than the window. This ensures that the window contents are still functional when the desired window size is larger than the display. By way of an example, consider the default set of mail rules shipped with Apple Mail in Mac OS X 10.4 (Tiger):

This is not the only place in Mac OS X where window content was not designed to cope with the 1024×768 resolution of the iMac. From the screenshot above it is evident that scrolling the window body (in this case, the sheet body) is insufficient, because this would still place the OK and Cancel buttons out of reach. By counter-example, consider Adobe Reader’s Preferences dialog box on a netbook:

The window is scrollable but it is still shown too tall and the OK and Cancel buttons are still out of sight:

Key components of a window should be sized or placed according to the window. Taking the Adobe Reader example above, the OK and Cancel buttons should be in a fixed pane at the bottom and the view selector list should be in a non-scrolling pane above it on the left side. Only the contents pane should be scrolling; the view selector list is already flexible in size and will show an internal scroll bar when its contents are taller than the available space.

Ultimately, if the application requests a window larger than the available space, the Window Manager will cap its size and the window content management system will force any oversized panels to scroll. Where at all possible, window content should be divided cleanly (so as to only need to scroll the relevant portions) and dialog box buttons should always be placed into a dedicated panel. The most practical approach would be to have the application supply a set of buttons to be positioned automatically by the OS, just as with the window layout and the menus.

Tabs

Tabs serve multiple purposes. They allow for a single window to hold multiple documents (in almost always a fully custom implementation with no visual consistency), allow a dialog box to hold multiple panels without needing to show all of them at once, and can provide access to the various steps of a wizard.

The term “tab” and a tabbed UI is only valid when switching between tabs does not result in the loss of any data within the tabs: the contents of all tabs must be loaded simultaneously or must behave in this manner. Websites commonly show simulated tabs where switching tab throws away anything entered into the tab being exited. Further, tabs must not hold the user hostage: content validation failure within one tab must never prevent the user from switching tab. The tab may show a warning symbol or other visual highlight but must not trap the user; they may need to refer to another tab for information first.

For wizards, there may the need to be able to disable tabs, to block access to each tab until the user has completed the previous tab; the tabs let a user revisit prior tabs but not skip across steps where the various steps are conditional upon previous steps.

Tabs are useful for adapting dialog boxes for varying screen sizes, although the likelihood now of a dialog box not fitting on the screen is far less likely than it was in the past. In most cases, a dialog box at risk of overflowing a modern high-resolution monitor is too complicated and should be split up. Psion EPOC32 handhelds used tabbed dialog boxes to accommodate their 640×240 and 480×160 displays, although frustratingly this was not opened up to OPL programs (this was C++ only).

Preferences dialog boxes are however a common situation for needing to divide up a window into tabs. There are various styles that have seen widespread use. Microsoft Windows uses top tabs with textual captions; when the number of tabs is too great to fit on a single row, two or more rows of tabs are used:

This multi-row technique was available under the Mozilla Firefox browser for the page tabs by way of third-party add-ons, that was destroyed by the Add-on Apocalypse.

On Macs, side tabs are more common for preferences windows, often using graphical captions. For example, the old Mac colour selector dialog box:

Note that the tab column is scrollable, which is arguably nicer than the Windows multi-row tabs, which can be taken to the extreme:

The Mac OS 9 Internet control panel used both graphical side tabs and top textual tabs at once:

Concepts

Inactive windows

Macintosh convention was to show inactive windows with all controls disabled. On the Mac, mouse clicks on inactive windows would only ever focus the window (so long as it was not blocked by a dialog box): clicking on a control on an inactive window would raise the window but not click the control. This makes activating a background window much easier as the whole window is a click target; moving from a Mac to another OS was painful as you would end up issuing unwanted commands when trying to raise a window.

For windows that are modally blocked, this visual principle is still wise, although it straddles multiple boundaries of responsibility: content management, controls and custom window content. On the Mac, the controls were physically disabled when the window lost focus, which meant tampering with control state; the program was required to do this itself.

Implementation

Should windows be described using a mark-up language, or programmatically?