HUMAN-COMPUTER INTERACTION SECOND EDITION
Dix, Finlay, Abowd and Beale

Search Results

Search results for interfaces
Showing 130 to 139 of 331 [<< prev] [next >>] [new search]

Chapter 5 The design process 5.3.2 Guidelines Page 196

Other popular graphical user interface (GUI) systems have published guidelines which describe how to adhere to abstract principles for usability in the narrower context of a specific programming environment. These guidelines are often referred to as style guides to reflect that they are not hard and fast rules, but suggested conventions for programming in that environment. Some examples are the OPEN LOOK and the Open Software Foundation (OSF) Motif graphical user interfaces, both of which have published style guides [233, 186]. Programming in the style of these GUIs involves the use of toolkits which provide high-level widgets, as we have mentioned earlier in this book and will discuss in more detail in Chapter 10. More importantly, each of these GUIs has its own look and feel which describes their expected behaviour. The style guides are intended to help a programmer capture the elements of the look and feel of a GUI in her own programming. Therefore, style guides for the look and feel of a GUI promote the consistency within and between applications on the same computer platform.

Chapter 5 The design process 5.3.2 Guidelines Page 197

We discussed menus in Chapter 3 as one of the major elements of the WIMP interface. As one example of a guideline for the design of menus, the OPEN LOOK style guide suggests the following for grouping items in the same menu:

Chapter 5 The design process 5.3.2 Guidelines Page 197

Brown, C. Marlin, Human-Computer Interface Design Guidelines, Ablex, 1988.

Chapter 5 The design process 5.3.2 Guidelines Page 197

Mayhew, Deborah J., Principles and Guidelines in Software User Interface Design, Prentice Hall, 1992.

Chapter 5 The design process 5.3.2 Guidelines Page 198

Sun Microsystems, Inc., OPEN LOOK Graphical User Interface Application Style Guidelines, Addison-Wesley, 1990.

Chapter 5 The design process 5.4 Usability engineering Page 199

The ultimate test of a product's usability is based on measurements of users' experience with it. Therefore, since a user's direct experience with an interactive system is at the physical interface, focus on the actual user interface is understandable. The danger with this limited focus is that much of the work that is accomplished in interaction involves more than just the surface features of the systems used to perform that work. In reality, the whole functional architecture of the system and the cognitive capacity of the users should be observed in order to arrive at meaningful measures. But it is not at all simple to derive measurements of activity beyond the physical actions in the world, and so usability engineering is limited in its application.

Chapter 5 The design process Storyboards Page 208

Probably the simplest notion of a prototype is the storyboard, which is a graphical depiction of the outward appearance of the intended system, without any accompanying system functionality. Storyboards do not require much in terms of computing power to construct; in fact, they can be mocked up without the aid of any computing resource. The origins of storyboards are in the film industry, where a series of panels roughly depicts snapshots from an intended film sequence in order to get the idea across about the eventual scene. Similarly, for interactive system design, the storyboards provide snapshots of the interface at particular points in the interaction. Evaluating customer or user impressions of the storyboards can determine relatively quickly if the design is heading in the right direction.

Chapter 5 The design process High-level programming support Page 211

Though not usually considered together with such simulation environments as HyperCard, a user interface management system -- or UIMS (pronounced 'YOU-imz') -- can be understood as providing such high-level programming support. The frequent conceptual model put forth for interactive system design is to separate the application functionality from its presentation. It is then possible to program the underlying functionality of the system and to program the behaviour of the user interface separately. The job of a UIMS, then, is to allow the programmer to connect the behaviour at the interface with the underlying functionality. In Chapter 10 we will discuss in more detail the advantages and disadvantages of such a conceptual model and concentrate on the programming implementation support provided by a UIMS. Of interest here is that the separation implied by a UIMS allows the independent development of the features of the interface apart from the underlying functionality. If the underlying system is already developed, then various prototypes of its interface can be quickly constructed and evaluated to determine the optimal one.

Chapter 5 The design process 5.6 Design rationale Page 213

There is usually no single best design alternative. More often, the designer is faced with a set of trade-offs between different alternatives. For example, a graphical interface may involve a set of actions that the user can invoke by use of the mouse and the designer must decide whether to present each action as a 'button' on the screen, which is always visible, or hide all of the actions in a menu which must be explicitly invoked before an action can be chosen. The former option maximizes the operation visibility (as discussed in Chapter 4) but the latter option takes up less screen space. It would be up to the designer to determine which criterion for evaluating the options was more important and then communicating that information in a design rationale.

Chapter 5 The design process 5.6 Design rationale Page 213

The usability of an interactive system is very dependent on the context of its use. The flashiest graphical interface is of no use if the end-user does not have access to a high-quality graphics display or a pointing device. Capturing the context in which a design decision is made will help later when new products are designed. If the context remains the same, then the old rationale can be adopted without revision. If the context has changed somehow, the old rationale can be re-examined to see if any rejected alternatives are now more favourable or if any new alternatives are now possible.

processed in 0.006 seconds