LAS POLÍTICAS DE GESTIÓN Y DESEMPEÑO DE LA DGB

By far the most popular class of interactive computer systems are those based on the windowing model of interaction. The idea behind windowing systems is that they enable users to maintain a number of simultaneous tasks on a computer screen at the same time by presenting these tasks in separate windows. Windows support different user-machine dialogues as disparate entities giving the user freedom to shift attention from one task window to the other. The underlying window system manages the production, placement and destruction of windows on the screen as well as managing the raw events generated by input devices such as the mouse and keyboard. Figure 4.6 is taken from Myers’ taxonomy of graphical user interface development tools (Myers 1995). It illustrates the layering of tools that have emerged to support the development of interactive

computer systems conforming to the WIMP style of interaction. A taxonomy of window systems can be found in Jones et al (Jones 1991).

A variety of tools have emerged to support the development of applications which run on windowing systems such as X (Scheifler 1986) and Microsoft Windows. These tools define a particular look and feel on the user interface to an application by prescribing what interface entities such as buttons and menus should look like, and how they should behave. Just above the window system, the first layer of tool support takes the form of a user interface toolkit.

User interface toolkits support the construction of graphical user interfaces by providing libraries of interaction techniques that can be invoked by application programs (Myers 1995, page 331).

An interaction technique is a mechanism for supporting user interactions and takes the form of a graphical object with associated user-generated event handling capabilities. Interaction techniques, more commonly referred to as ‘widgets’, can be combined to specify an interface, the behaviour of that interface and in some cases the connections the interface maintains with the underlying application (Bentley 1994). Interaction techniques provide the system with a view of the user by supporting communication between the user and the application through events generated within the interface.

4.4.1 Toolkits

There are two forms of user interface toolkit, libraries of procedures such as TCL/Tk (Ousterhout Application

Higher-Level Tools Toolkit Windowing System

Operating System

produce common functionality within the interface of an application. TCL/Tk is a purpose built scripting language, which provides an abstraction over libraries of useful interface procedures implemented in the C language. Although users of TCL/Tk do not require an intimate knowledge of C in order to create a user interface, they do need to understand the TCL scripting language, and scripting is just an another form of coding, albeit using a higher level syntax.

Object-oriented interface classes such as those in Smalltalk and Java’s AWT (Flanagan 1997) can be instantiated in order to create user interface widgets. As with procedural libraries, creating user interfaces with object classes involves low-level coding, despite the availability of graphical drag and drop interface building tools. There are, however, several benefits of object-oriented toolkits over procedural toolkits. To begin with objects are a natural way to think about the components that make up the interface, having both representation (state) and a method of interaction (procedures to operate on that state). Object-oriented toolkits also provide more structure than procedural libraries to the process of user interface creation, as the design of widgets within object oriented toolkits is strictly hierarchical. This hierarchical structure is reflected in the architecture of the interface to an interactive application (see Figure 4.7).

Due to the expense of developing toolkits the initial set of interaction techniques provided by them is necessarily small. Of course it is impossible for their developers to envisage all potential modes of interaction that will be required in future applications. Addition of new interaction techniques into procedural libraries involves coding them from scratch. Object-oriented toolkits are a little better in that new interface entities can be created by sub-classing existing classes.

ScrolledWindow

PushButton PushButton PushButton PushButton

ScrolledWindow

Figure 4.7 A class hierarchy and a user interface hierarchy, after Smith (Smith, 1995)

Object libraries also tend to have larger initial widget sets than those provided by procedural toolkits.

Toolkits provide code for the instantiation of common interface widgets such as buttons, menus and text dialogues. The aim of toolkits is to support rapid prototyping of user interfaces and shorten the implementation time by providing useful code that can be reused in the implementation of many interfaces. At the beginning of development, using a toolkit is not particularly rapid, even for experienced programmers as it takes a while to become familiar with the available interaction techniques and how they can be used.

From a design point of view, the main disadvantage of interface toolkits is that their procedural interfaces make them difficult to use by anyone other than application programmers. Building an interface with one of these tools involves hand coding, as there is no support for laying interfaces out graphically. To find out what a particular interface configuration looks like involves an extended code, compile and review cycle.

Frameworks such as MacApp (Schmucker 1986) provide a level of support above that of toolkits and effectively provide rules of ‘good design’ in the form of semantic structures. A complete application or interface framework is presented in the form of a generic structure of classes. By sub-classing the framework’s classes, a system developer can provide and connect to suitable, application- or interface-specific functionality. As with toolkits, frameworks are designed to support the developmental work of experienced programmers, who are required to understand both the framework and a suitable programming language. Used in conjunction with toolkits, frameworks aim to support both interface design and usability through the use of consistent layout, use of metaphor and action.

Fortunately, many toolkits are supported not only by frameworks but also by graphical interface builders, which offer support to both the design and development of user interfaces. Interface builders, such as XF builder (Delmas 1993) which supports TCL/Tk, overcome the limitations of the toolkit elements’ procedural interfaces by providing a graphical environment that supports both direct manipulation of components and access to their functionality via graphical widgets.

4.4.2 User Interface Management Systems

User interface management systems (UIMSs) correspond to the ‘windowing system’ layer shown in Figure 4.6 above. Dix (Dix 1998, page 395) defines a UIMS as being “a conceptual architecture for the structure of an interactive system which concentrates on the separation between application semantics and presentation.” UIMS bring visual programming techniques

together with toolkits and frameworks as well as code generation and compilation facilities. Together these tools provide integrated environments for the prototyping, implementation and in some cases evaluation of interactive interfaces. Within a UIMS, provision is made for developing not only the interface and related parts of the application but also the communication that is to take place between the interface and application.

UIMSs often profess to support the activities of non-programmers, although not all UIMS offer visual programming techniques but rather require users to learn a special purpose programming- like language in order to specify the contents of an interface. Druid and Garnet (Myers 1990) are UIMS that do allow interface designers to draw aspects of the user interface directly onto the

screen using a mouse. Lapidary, the interface builder in Garnet, enables relationships between interface objects to be established through the drawing of lines between interface objects. A designer can then either visually demonstrate the response an interface object should provide to user-generated mouse actions, or specify these responses using a dialogue box.

Some UIMSs, such as XXL (Lecolinet 1996) support the integration of both visual and textual programming styles within a single framework. This means that all interface components have both a visual and a textual representation. Both types of representations can be mixed in the construction space, which is a graphical direct manipulation environment. XXL is built to provide support to the Motif toolkit. This means that the only widgets available within the environment are those provided within Motif.

The problem of restricted numbers of interaction styles in interface toolkits obviously propagates up to the graphical editors that support them. Adding new interaction techniques to most UIMS involves low-level coding by an experienced programmer. Although user interface management tools such as Peridot (Myers 1989) try to overcome this requirement for hand coding by allowing users to create new interaction techniques by editing the functionality of existing techniques using direct manipulation of a graphical representation of the original. The user can demonstrate the

new functionality of the interaction technique by using the mouse to show the system how an object should respond to user input. Interaction rules provided by the system are used to infer behaviour from these user actions. Peridot attempts to infer relationships between objects within the interface from set of rules.

UIMSs are designed to support the development cycle of user interfaces. Tools such as Gamut (McDaniel 1997) are beginning to emerge that support the development of entire interactive applications. Gamut is a tool for building complete interactive applications such as games and educational software. Development takes place via programming-by-demonstrations (PBD) and unlike many UIMS there is no need to look at or modify code to create any behaviour. An interface developer draws interface configurations directly on screen and then indicates the desired behaviour of objects in the interface by demonstrating the desired program response to input events using the mouse. Gamut is able to infer single conditional relationships between objects (respond or not depending on some condition). It can also infer chains of relationships between objects.

4.4.3 Supporting Interaction

It is possible to identify and support common modes of interaction based on the types of user- system dialogues that occur within a particular class of system. An important concept in interactive systems development is the notion of device independence, which involves classifying input devices within generic classes of what are known as virtual devices (Buxton 1990). The

form that a dialogue for a given application takes is described in terms of the virtual input devices that that application supports. Once defined, an application’s dialogue can be supported by any of the associated class of virtual devices. So, for example, interactive systems with WIMP interfaces support both mouse- and keyboard-generated events. Communication between the user and the machine takes the form of a turn-taking dialogue, usually within a graphical, direct manipulation environment, driven by the generation and processing of discrete, user-generated input events (key presses and mouse button press, drag and release actions). A conventional QWERTY keyboard, a Dvořák keyboard or a chord keyboard could theoretically be used to generate the keyboard events. Similarly a joystick, trackball or trackpad could replace the mouse.

4.4.4 Discussion

The relationship between virtual device and interaction dialog is the reason why tools for developing WIMP-style applications cannot easily be applied to the development of systems requiring non-WIMP interaction. WIMP tools support dialogues based on discrete user-generated events whereas gestural input devices such as those employed within virtual reality applications require user-system exchanges based on continuous user-generated event streams. The controller that exists within the application to multiplex input events to their meaning works in conjunction with the windowing system on which the application is based.The lack of support for alternative methods of user input in user interface development tools reflects what Buxton (Buxton 1990) identifies as the low priority input devices are given in the overall development considerations of interactive systems.

What can be gleaned from this overview of WIMP systems development is that an understanding of high level conceptual models of interaction eases the design of tools that support the development of these systems. The two key features provided by conceptual models of interaction are:

1. A set of clearly identifiable high level components 2. A well defined architecture

By examining the process model adopted for the development of interactive systems an emergent requirement is to provide tools that support the broadest possible involvement in system development. With these issues in mind, it will be helpful to look at tools that have been created to support the development of non-WIMP systems. To this end, the following section reviews tools for developing virtual reality applications that incorporate both continuous and discrete input and output devices.