Informatics Informatics Department Methodology of Window Management

Jump To Main Content

Jump Over Banner


Jump Over Left Menu

18. User Interface Working Group Final Report


The Working Group categorized the influences on user interface design and styles of interaction; these categories are shown in Figure 18.1.

User Interface Evaluation Existing Designs Application Domain User Type Interface Techniques User's Model of the Window Manager Guidelines and Principles

Figure 18.1

The following sections consider these influences in turn, and list the options under these headings, attempting categorizations where possible. These should only be seen as a first pass and further work is needed in all areas to improve the classification of influences on user interface design and to enumerate the options in each area.

For each combination of system/application/task/user, the interface option selected changes. Almost all How should...? issues were changed into What are the options for...?.

Group Motto: IT DEPENDS.

A need for a design methodology for user interfaces was agreed. Central to such a methodology must be a means of representing the user interface design so that it can be specified, discussed, tested and implemented. For example, the user interface can be represented in terms of its command language and its conventions for information display. It is essential to apply such descriptive representations to window manager user interfaces so as to provide a basis for discussing their properties.


Figure 18.2 is a proposed taxonomy of window manager user interface issues, based on a proposal by Brad Myers. This taxonomy attempts to list most of the properties that differentiate different window managers' user interfaces. It seems that a window manager can be characterized by choosing among the various issues listed here. Sub-issues listed depend on the decisions on the higher level issues. This list can serve as a guide to what choices need to be made when designing future window managers.

Presentation of Windows Overlapped Tiled fixed columns [Cedar] arbitrary [Microsoft, ITC] off-screen not partially [Sapphire] update to covered not [Interlisp-D] listener can be covered [Sapphire] not [Lisa] Multiple screens (views, desktops, pan, ...) [Tek 4404, Smalltalk] Subwindows Other groupings visible? user specifiable? saved? (desktop) full capabilities [Sapphire] limited [SunWindows] (tiled) grow? Title lines state pictures? application text commands How listener shown? title line border tracking cursor position blinking caret Colour available? user specifiable meaning?

Figure 18.2a

Icons and Special Areas Icons associated alternative commands in icons menu? type to it? user can move? pictorial textual shape + size fixed? static application update extra information window data entity Exists special areas? for icons input + prompts (versus in windows) coverable? removable?

Figure 18.2b

Operations Supported Top, bottom, arbitrary place in Z direction Move and Grow arbitrary special [Cedar] while covered shown dynamically? from various control points? Operations disabled by application? Operations performed by application? Shrink to icon etc (other ops: colour, full screen, splitting) UNDO? Abortable after started? Available from cursor? multiple clicks? feedback in cursor picture? always or after press mouse-ahead listener change press [Sapphire] move [SUN] combination [ICL] press through Menus pop-up fixed reserved button fixed area invisible areas [Sapphire] displayed [Macintosh] hidden [Cedar] location window or screen relative submenus pop-up stacked fixed [not possible?] selected by cursor? selected by keyboard?

Figure 18.2c

Operations Supported Menus selected by keyboard? pictorial text only [Cedar] mixed [Macintosh] scrollable? 1D, 2D retain info (as default) only legal options displayed all those unavailable greyed? arguments? (see forms) exact sequence of operations to invoke menu multiple selections possible only one Available from keyboard? reserved shift [Macintosh] reserved prefix [Sapphire] reserved keys (eg function keys) [Apollo, SUN] type ahead keyboard change listener? User tailorable interface assign buttons pick commands higher level properties output pictures (eg background colour) [Macintosh] Application tailorable interfaces? High level functionality supported by window manager? typescript conventional editor based graphics package scrolling general menus etc [Macintosh] forms for argument specification support inter-window transfer (cut and paste) etc

Figure 18.2d

In addition, as a measure of the level of constraint placed on the user interface by different systems, window managers can also be described schematically, as shown in Figure 18.3.

level of constraint by window manager impossible BLIT Sapphire (Icons) Cedar Mac none little some a lot example system

Figure 18.3


The Working Group believes that the publication of guidelines and the demonstration of systems with consistent default user interface choices is of value. Some relevant guidelines are given here, based on a list prepared by Warren Teitelman; the context is oriented to a program development environment where the user would be expected to be in control.

  1. Be intuitive: use icons and cursor images suggestive of the operations being performed, menu highlighting, previewing, etc.
  2. Accommodate novices and experts: there is a range from ease of use to power and expressibility. Techniques such as double click to override confirmation mechanisms. complex operations attached to multiple buttons, keyboard metashift keys, function keys, and so on can all be used as accelerators for expert users.
  3. Allow customization: default settings should be used (perhaps depending on user type such as novice, occasional user, expert). Configuration languages or files can also be provided to associate window manager operations with buttons, keys, sequences, etc. Macro mechanisms can be made available for expert customization (as in Emacs).
  4. Provide extensibility: again macros can be used to extend basic functionality, and languages to map user actions onto window manager functions. Use of a language such as PIT (Programmable Input Translation) should be considered (previously called TIP).
  5. Use lots of feedback: normal interaction with a user should not be intrusive. For example, a blinking caret may be suitable to show type-in position, but a flashing window is marginal - some users will object or get concerned - while a blinking screen is objectionable and should only indicate impending doom! Pop-up prompt or reminder boxes may be objectionable after the one thousandth use, and should be capable of being overridden. In general, taking and using a user resource should only be done in extreme circumstances; consider that a prompt or reminder in a typescript window may ruin the user's data, and the Unix man entry should perhaps use a separate window to help preserve the user's data at the current working point.
  6. Be predictable: use the principle of least astonishment. A consistent, uniform, easily remembered set of basic actions which is extended in obvious ways should be used. Use of buttons, keys, etc should be regular, and icon interpretation should be uniform.
  7. Be deterministic: type ahead and mouse ahead effects should be considered, and deterministic (hence predictable) methods preferred.
  8. Avoid modes: states that persist should be avoided. If modes are necessary make the feedback and paths out highly obvious. For example, guarded buttons (which fall out of a state after a time) could be used rather than confirmation boxes.
  9. Don't pre-empt the user: users should not be forced to respond, and user resources which are expected to be used for an application should not be grabbed.


Insufficient attention has been paid to user's models, which enable window manager concepts to be taught more easily. The model that the user has of the system is meant here, rather than the model the system has of the user or that the designer has of the user. The window manager has enriched the user's model of the system as a whole with several new concepts. These concepts need to be clear and simple in order to maintain the usability of the system. There is a danger that a window manager with a poorly conceived user's model will have an adverse effect on usability. Ways in which users would conceptualize the window manager were considered during the Working Group discussions; this is still a research area and ways of describing user's models are still being developed.

One way of representing the user's model is to describe it in terms of objects, actions, and modes. Objects are the entities of which the user is aware, actions are performed on the objects by the user, and modes are states in which objects exist that affect how they respond to actions. This object model is hierarchical and should be viewed at a number of levels. An initial. incomplete breakdown gives:

Objects Actions Modes
Window move
listener/not (per device)
Application Control
Menu select
Screen (output) resource
Input resource

At some level, objects that are relevant to the user's model will include window, task, icon, menu, cursor, and screen. There are others which appear to occupy a less prominent position in the user's model, for example, a window title line or an attached menu. Various user's models of icons. windows and tasks were discussed. with the following comments:

  1. The task is a more abstract concept that appears in some user's models of some systems.
  2. In some user's models the window is used as a means of accessing and controlling a task.
  3. An icon may be thought of as an alternative representation of a window, ie a mode of a window. Alternatively it can be considered as a separate object, such as a representation of a task, a data item or a function. In many systems the relationship between icons and windows is not very clear.

Actions on tasks can include create and kill operations, while windows can move, grow, be altered in screen priority (top/bottom in window managers which permit window overlap), and be closed to icons. Icons can be moved, or opened.

The separation of the user's model of the window manager and the user's model of the application is not clear; for example there are operations such as scroll and zoom which the user may perceive to be under the operation of the window manager but which are in fact an operation of the application.


The user's model should be considered in any attempt to define standards for window manager user interfaces.

Present ways of representing the user's model are not satisfactory - and there is no obvious route to standardization of the user interface.

More research is required, and where there is development work it should consider user's model issues. Research work could include the study of existing window manager user's models, and better ways of representing user's models.


There is a wide range of applications domains across which a window manager may be used. These include:

There is also a wide range of applications within each domain, for example office automation includes word processing, spreadsheets, databases, electronic mail and so on. Across these domains and applications various styles of dialogue are appropriate, for example user-in-control (Office Automation), system-in-control (CAI), and mixed-initiative (Process Control). Tasks in different application domains have many variables, eg they may be continuous, interrupted or occasional.

Some window manager user interface decisions are a function of the application domain and others are reasonably independent. For example, don't be too intrusive is a good principle for the design of a programming or word processing system, but not for the design of a critical real-time process control system; whereas be intuitive and use lots of feedback seem to be application independent.


A configurable toolkit approach should be taken. This should provide an extensive set of defaults to provide a house style, encouraging consistency in future applications, plus access to lower-level facilities to enable inclusion of applications for which this style is inappropriate.

The window manager should provide generic select, cut and paste operations to be interpreted according to application semantics.

Categorization of application domains, the applications within them, and the tasks performed should be undertaken. Some axes for classification are: the distribution of control in the dialogue; the temporal nature of the task (eg continuous/occasional/interrupted); and the difficulty of the task (data entry <----> problem solving).

An adequate abstract window manager model should be created and related to the application and task categories. The Card, Pavel and Farrell model [15] is a useful starting point.

User Interface Management Systems should be developed which enable the rapid tailoring of window managers to application requirements.


It is unlikely that just one window manager will be appropriate for all types of user. Users vary in many ways, having differing amounts and types of ability, motivation and experience.

These user characteristics can be further subdivided as shown below:

  1. Ability: cognitive, manual.
  2. Motivation: to use computers, and to complete the task.
  3. Experience: of systems that could serve as metaphors; computers in general; the underlying operating system; the application program; the task; window managers in general; and the particular window manager being used.

It is not clear at present how each of these factors maps onto window manager features (if at all). However, some examples can be given where common sense suggests there will be an effect. Cognitive ability has implications for the ease of initial use of the window manager and the degree to which it supports accelerators, combined operations, customizability, etc. Poorly motivated users (such as senior executives!) place great demands on the window manager design to ensure that it does not need much effort to interact effectively with it. Users' experiences have implications for the selection of metaphors such as the desktop model, the nature of help, error messages, the complexity of facility provided, and so on.


A customizable/configurable/extensible window manager system is necessary to cope with the requirements of a wide range of users. If the characteristics of the target user group are known the default settings of the window manager system should be matched to their needs/preferences.

More work is needed to:

  1. determine good way~ of classifying and describing users and how far it is possible to go beyond a simple novice/expert categorization;
  2. determine the window manager system requirements of different user groups;
  3. develop ways of enhancing window manager system configurability, such as configuration languages.


More work is needed on measurement and testing methods for assessing the user interfaces of window management systems. Some work has been done on analysing human-computer interaction using formal grammars and then applying metrics (eg counting the number of grammar rules needed to generate a command language) to estimate ease of initial use, learnability, error rate, etc. These techniques can be applied at an early stage in the design of a system and can guide the design process. This work should be encouraged and augmented in order to develop methods of analysing and predicting performance with window-based systems.

Usability assessment involving tests of representative users interacting with simulated, proto typed or real systems is currently the only way of determining how well-matched a system is to its users. The evaluation of text editors forms one focus of this work. Techniques appropriate for the assessment of window managers should be researched; for example, a collection of benchmark tasks should be developed for use in user tests with such systems.

An important related effect is to provide tools to aid in the development of user interfaces easily and quickly. These tools, often called User Interface Management Systems (UIMSs) are now progressing to the point where they can be used to generate window managers, but more work is needed.


A series of questions of the form:

How should the user do this?

Is paradigm X the correct one?

was presented to the Working Group. It was felt from the start that, given the range of possible applications and users, these were the wrong sort of questions and that it was not possible to be dogmatic about anyone position in questions of this form.

Some specific issues required resolution of whether the user should be allowed to do X,Y,Z and whether the applications should be allowed to do similar things. It was felt that the window manager should allow, in principle, an application to be able to do anything that a user can do and vice versa. In an extensible system the distinction between user and application may be arbitrary.

18.8.1 Consideration of End-users

The designer of the window manager must consider who the end-users are. In the ideal case all possibilities should be catered for, but it is recognized that this will be prohibitively expensive. The design choices must therefore be based on the needs of the end-user community. As an example: a general purpose undo command may not be relevant for professional users since most window manager commands are reversible. However the ability of users to make use of accelerators may require the window manager to maintain too long a history of commands to guarantee reversibility.

If the user type is not pre-decided then the window manager must be more general and configurable, which will clearly increase the cost of providing the window manager and may be less satisfactory for any particular user group.

18.8.2 Responsibility for the User Interface

In most of today's non-adaptable systems, the responsibility for the user interface does not lie with the user. In the future, however, when the interposing of a User Interface Management System (UIMS) between user and application allows the users to customize the interface to their own requirements, consistency across applications as well as within them can be maintained. By and large the application should not be interested in acquiring data via the interface and passing data out in some form. For instance, an application may require the user to scroll but neither the application nor the window manager should really be concerned with where the scroll bar is placed either in or around the window. Similarly, 'selection from a list' is another operation whose accomplishment via a static or pop-up menu is unlikely to be of serious concern to an application. In general, window manipulation functions (such as the meaning of keystrokes, mouse movement and button action) should be specified separately from their user interface. This will require adaptable layers and configuration tools.

This level of customization is now being demonstrated in some window managers.

18.8.3 Control of Interaction Style

Given the range of applications and users, it is not practicable to prescribe styles of interaction - consider. for example, the different styles required by a Command and Control system and a program development environment. In the first case user control is necessarily restricted, while in the latter a high degree of customization is desirable. Questions to be considered are such as the following:

All have the same answer: it is dependent on the application and the user.

18.8.4 Icons

Icons are regular (small) pictograms which may be defined and changed by applications. They can serve many functions, frequently to conserve screen real estate. They can be used as an alternative to a window as in Cedar; as an alternative representation (perhaps concurrently visible) of the window (Sapphire); or as a representation of a task to be invoked or data which is to be operated on (STAR, Macintosh). The icon can thus range from an application-prescribed static bitmap representation to an entity which has all the attributes of a window (eg can receive all types of input). Since use of icons in user interfaces is commonplace. the provision of support in the window manager for operations on them is desirable.

18.8.5 Window Size Alteration

A user in a given application may have the ability to alter the size of the window. In such circumstances. the action taken is application dependent (although it may be under user direction). For example, if a window expands, the extra area may be used to provide a larger image of the object previously there; alternatively, the new area might be required to provide annotation of, say, the previous image which is unchanged. Similarly, if a window shrinks, a previous image may be shrunk to fit, or clipped, while text may be clipped or reoutput so that the last part of the previously displayed text is seen. Alternatively. a new, concise, representation may be used.