The Working Group categorized the influences on user interface design and styles of interaction; these categories are shown in 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.
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.
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.
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 grow top bottom |
full/icon listener/not (per device) |
Application Control Task |
scroll create destroy |
|
Menu | select | |
Cursor Screen (output) resource Input resource |
select |
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:
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:
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:
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.
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.
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.
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.
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.
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.