Methodology of Window ManagementJump Over Left Menu
8. Standards Activities
John Butler
8.1 INTRODUCTION
The ANSI X3H3 (Graphics) arena is concerned with standardization of data exchange, virtual terminals, and the user interface. Over the last six months a number of meetings have taken place between people interested in the Window Management area, beginning with a request for a standard expressed at SIGGRAPH 84. During December of the same year an ad hoc meeting of 12-15 people was held, where it was clear that there was enough interest to proceed. In January 1985, at a meeting of the X3H3 Committee which had some European involvement, interest initially centred on the Computer Graphics Interface (CGI) proposal [30]. The group felt that some modifications to this proposal were called for, such as the introduction of complex clipping areas and the ability to direct primitives to a specific window. A further ad hoc meeting was held in February, where it was decided to explore standards based on the shared resource model, and standards at the applications interface level. A useful line to explore is whether there are limited ways to construct systems; if so it may be possible to build configurable interfaces.
As part of the SIGCHI 85 conference in April a User Interface Workshop was held. The view from the Human Factors community expressed there was that it might be possible to standardize at the application program interface level, but not at the user interface level. A further workshop is to be held in May at the Boston meeting of X3H3.
Other ANSI committees with interests in Window Management are X3H5 (Virtual Terminal and User Interface), X3T5 (OSI), and X3Vl (Documents). The ad hoc group feels that there is a need for a new committee to consider virtual terminal and user interface standardization, and to coordinate with the existing standards committees.
As a caveat, the author would like to state that this presentation represents his personal opinions, and little has been presented to X3H3 yet. Other workers have advocated a more limited view; for example, that at present only the application interface can be standardized. Possible Committee actions range from none, to the formation of a new task group. The X3H3 members at the Workshop [Butler and Bono] were interested both in raising the level of awareness of issues already formulated, and in learning as much as possible about implementation issues from other Workshop attendants.
8.2 MODELS
8.2.1 Basic Program Models
Present models of interactive systems have evolved each with its own terminology. There needs to be agreement on terminology and the basic model before standards can be defined. At the most basic level the model in Figure 8.1 can be drawn. A more detailed version of the model is shown in Figure 8.2.
Figure 8.1
Figure 8.2
Specific knowledge about the interactive hardware is needed by an application to interact with a user, and abstraction is required to enable portability. The adaptation layer is provided as a layer below the system level to provide abstraction from real devices. A language for portable systems is at this level; below this, items are system-specific.
Reference Model
Figure 8.3 shows a reference model for interactive programs (DI = Device Independent, DD = Device Dependent).
Figure 8.3
The centre column of functions shows links or sneak paths which might be utilized to short-circuit the complete user-to-application sequence if necessary. At the lowest level this is tracking (for example, of the cursor) while at the DI level it is echo (using the GKS input model terminology). Multiple stream and UIMS levels generate links corresponding to segment transformations and menus, forms or dialogues respectively. Languages are needed (and exist) to allow the application to control these sneak paths. Not all architectures support such controls.
Model of User
Similar notions and levels exist in the model of a user given in Figure 8.4. Note the similar cross links to those in the graphics model; for example the knee jerk reflex at the lowest level, hand withdrawal at pain or pressure, head turning to sound of thunder/flash of lightning, and a greeting at the complex multisense level. The tactile feedback of a key click is different in type to the character feedback on screen or paper.
Figure 8.4
8.3 UNRESOLVED MATTERS
The models described in the preceding section raise many issues; some of these are:
- Bandwidths - the PC, for example, can use all its CPU bandwidth in handling the display.
- Task-virtual terminal mapping.
- Parameter lists - who owns the parameter, eg bitmaps; applications can have difficulties if there are very long parameter lists.
- Parameter types and default actions; some examples are:
- file (static - can be edited, eg a menu);
- procedural (installed, pseudo-static);
- event (dynamic).
- Are window contents stored as bitmaps or as procedures to draw them?
- Strong (task) versus weak (thread) - ie styles imposed by multiple process (for example. Unix) operating systems against single process systems.
Several terms require definition, such as:
- window/virtual terminal;
- task;
- synchronous/asynchronous;
- lock/unlock;
- mode versus parameter;
- settable versus intrinsic;
- state (strong thread) versus stateless (weak thread);
- efficiency versus exactness - there needs to be graceful degradation if exact requirements cannot be matched, and hence guidelines on such degradation.
Standards in this area will have several parts, including a window language (create, move, size and so on), user interface tools (menus, forms, dialogues), models, data exchange formats (eg extracting cells from a spreadsheet to pass to another program), and bindings (both procedural and datastream).