The Working Group membership was as follows:
(Warren Teitelman joined the Architecture Working Group after the first two sessions.) The main goal of all the Working Groups was a better understanding of the issues involved in their respective areas. Given the wide range of user types, applications, and window managers seen by the Working Group, the difficulty of providing concrete, all-embracing decisions can readily be envisaged. The Final Report in the next chapter attempts to classify the influences on the User Interface (UI), and presents conclusions on some of the issues discussed. This chapter is essentially (if not essential) background reading to that report, providing some of the more detailed reasoning that underpinned some of the decisions, and presenting some matters which, although they did not appear in the report, nevertheless are of interest. The following sections are, for convenience of cross reference. numbered as in the final report.
As background, the seven functional uses that have been identified for windows [15] are worth quoting:
These functions are needed to make a model of a window manager for a user, and are part of the problem-solving strategy.
The components of the user interface are the command language, information display techniques and feedback techniques. The command language has commands (operations on selected objects), objects to be operated on, and states (or modes). Information display methods include displaying the state of the system (choosing an abstract representation (icons) when needed) and enabling the next command or task, with access to the relevant information. Feedback mechanisms - which might be considered as part of information display - are needed for immediate device feedback (eg cursors), echoing, and selection feedback. Consideration of the influences on the user interface leads to the diagram in Figure 18.1.
Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time.
Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines. which can be considered as a form of subwindow. may need to be accessible to the application.
Icons were considered to have a number of possible functions; for example in Cedar an icon is a representation of a window, while in Sapphire it is another. concurrent form of the window, displaying information such as completeness of the task being performed, and status. After some discussion, it was decided that icons. which should be associated with the application, could be representations of, or alternatives to, a window; a representation of a task; or a representation of data, plus some (implied) potential for functions which could be done. These last might not be conceptually consistent - for example, opening a document icon in one system gives a window with an editor operating on that document, but moving the document icon to the trash can icon deletes the document, not the editor ...
There was little discussion on colour. Non-application-oriented uses envisaged included highlighting to show the listener window, display of error messages, and so on.
The taxonomy presented in the final report provides a fairly complete structure and list of the various features and techniques available in the three main sections window presentation, operations, and high level functions.
The final report contains a list of relevant guidelines to user interface design. During the discussion of these in the Working Group some other useful points came out which are recorded here.
Graphics such as icons can be very powerful if used intuitively - international road traffic signs give examples of good and bad usage of icons; the bad ones are non-intuitive. A cursor should be used to tell the user the current state, or next action available. All these exploit the bandwidth of the display. The spread of user experience can (at least partly) be accommodated by, for example, allowing holding a mouse button down to display help information. As user experience increases, the feedback used decreases. Another consideration is ease of use against power - a novice, when editing a document, could select a word by pointing at the first character and then extending the selection, while an expert would use a double click.
Cedar attempted to be consistent in its use of keys and buttons on the mouse. If <key> meant do <function>, then shift <key> meant do <reverse function>, so that a function key for (forward) search could be used with shift to provide a backward search, and shift with the again (repeat previous operation) key meant undo. Similarly, the left mouse button could be used for simple tasks and the right for more heavyweight ones; in a debugger, the left button could clear a breakpoint while the right could clear all breakpoints.
Modes in general should be avoided where possible; shift is acceptable but caps lock is not. An experienced user could be allowed to specify modes, but these should persist visibly. One option used in Cedar was the concept of the guarded button - the first hit removes the guard for a few seconds, after which it returns. As a general rule, anything the user does is precious - for example, if a confirmation is required, any existing type ahead should be saved, and restored following the confirmation.
This section also records some points arising during the discussion of this topic which are not recorded in the final report ( section 18.4).
It is common to regard the screen as a fixed area that windows get placed in; an alternative, useful concept is to see the screen as a window on the user workspace, and the screen itself is moved over that workspace. In Cedar, the screen is just the current working set of a large (overlapped or tiled) system workspace; the system has the notion of multiple desktops. Alternatively, the total user view can be considered as a plane or a hyperspace. The system can save a screen set of windows, and restore a saved set of others.
A list of functions does not represent a conceptual model of a window manager; this model is high level, independent of the information displayed and the command language. It acts as a basis to start with when addressing a new user. The model describes what a window is and what can be done with it; the question of how the operation is done is separate. It is worth remembering the Foley and Van Dam description of the four parts of the user interface [conceptual, semantic (move window), syntactic (how to move window) and lexical (press left button)]. In general users have tasks to be done: they don't begin by moving windows, but by considering more macro-level tasks such as moving information between windows.
Representing the user model is difficult; many psychologists would say too difficult even to discuss. User interface designers tend to be more confident in talking about it as they don't understand well enough the complexity of the problem. It is worth bearing in mind that although the user has models of the window manager, the application and so on, these models are not additive. An outstanding issue is the need to separate the user's view of the window manager from that of the application - an example is that scroll and zoom are not part of the window manager.
The Working Group decided that there was a need to look at a set of applications and extract generic functions, common to a range of applications. Ideally, the whole universe of window manager uses should be considered; it might be that some areas could not be tackled: if so, reasons should be given. Subordinate applications should be noted - for example, in a spreadsheet system there might be a requirement for word processing software. There were some obvious implications, such as that a real-time application would require its windows to be unobscured, probably militating against the overlapping style of window management.
It was noted that. in terms of the functionality required. the window manager seemed slightly insignificant; research on commands and functions might be more worthwhile.
The common split between novice and expert was too simple. Users could be expert in one area and novices in another, or a computer-naive user could require a very sophisticated applications interface - consider an air traffic controller. The effects of stress might also need to be taken into account - users under pressure can revert to habits developed on a previous system. These ideas are taken further in section 18.6.
Xerox PARC have done a lot of work in this area. At PARC, there was a feedback loop between the psychologists and the implementers of user interfaces; however it takes much longer to do a psychological study than to build the interface. The existence of a large community of critical users helped. but the psychologists tended to verify what was already known. The PARC measurements on keystroke efficiency and cursor movement overall had disappointing results. In a comparative study of editors (Roberts [56]), the only statistically significant result was that Teco was harder to use than the others. (As an aside, Teco was implemented by a very slow typist - slow typists are more willing to accept the cognitive load of short command names.) It is necessary to distinguish between metaphor and model - the metaphor is not a total function, and maps to a separate domain. With the desktop metaphor, one is mapping onto the paper office, but differences soon become important.
User interface characteristics are dependent both on the characteristics of the user and on the task being executed. It is important to consider the context in design; even using Teitelman's guidelines (see section 18.3) an enormous search space exists, and other methods must be used. Formal evaluation of a paper design for the interface can be undertaken; using formal methods means that tools can be used to estimate how appropriate the design is for a particular user and task. The process is time consuming, and there are often surprises when the interface is actually implemented. Various methods are available, including prototyping, when the general style of working is provided, not full functionality. Performance problems in prototypes can also affect the assessment of the interface.
Testing can be done by simulation (eg by using overhead projector slides for screen artwork, icon design and so on), trial implementations (with the need for feedback from users), and formal testing (classical human factors, laboratory condition experiments, statistics to make decisions about, for example, multiple button clicks).
Current work is patchy, based on comparative studies of single issues or small parts of a system. Methods that need to be used in the future can be classified into two types:
The list of issues assigned to the Working Group is to be found in section 14.5.2.
In addition to the issues covered in section 18.8, the Working Group also discussed the need to support some form of dialogue between disjoint applications. In cut and paste type operations support of dialogue between disjoint applications is required. In cut and paste type operations, the cut can be considered as bitmap, text or graphics, or the relationships between the items in the cut (consider a spreadsheet, for example). The requirements are application-dependent; all the window manager can do is to provide invocation mechanisms and a conduit for information flow between the applications, which can define what the data means.
The Working Group saw the need for much more research in the user interface area especially in areas such as user's model issues, measurement and testing methods for assessing user interfaces, and User Interface Management Systems. An analysis of applications and their requirements would also be helpful.
