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

Search Results

Search results for screens
Showing 111 to 120 of 281 [<< prev] [next >>] [new search]

Chapter 4 Usability paradigms and principles Predictability Page 164

As another, possibly more pertinent example, imagine you have created a complex picture using a mouse-driven graphical drawing package. You leave the picture for a few days and then go back to change it around a bit. You are allowed to select certain objects for editing by positioning the mouse over the object and clicking a mouse button to highlight it. Can you tell what the set of selectable objects is? Can you determine which area of the screen belongs to which of these objects, especially if some objects overlap? Does the visual image on the screen indicate what objects form a compound object which can only be selected as a group? Predictability of selection in this example depends on how much of the history of the creation of the visual image is necessary in order for you to determine what happens when you click on the mouse button.

Chapter 4 Usability paradigms and principles Customizability Page 171

Adaptability refers to the user's ability to adjust the form of input and output. This customization could be very limited, with the user only allowed to adjust the position of soft buttons on the screen or redefine command names. This type of modifiability, which is restricted to the surface of the interface, is referred to as lexical customization. The overall structure of the interaction is kept unchanged. The power given to the user can be increased by allowing the definition of macros to speed up the articulation of certain common tasks. In the extreme, the interface can provide the user with programming language capabilities, such as the UNIX shell or the script language Hypertalk in HyperCard. In these cases, Thimbleby points out that it would be suitable to apply well-known principles of programming languages to the user's interface programming language.

Chapter 4 Usability paradigms and principles Task conformance Page 175

Visibility of the objects of interest The most important objects of interest in a word processor are the words themselves. Indeed, the visibility of the text on a continual basis was one of the major usability advances in moving from line-oriented to display-oriented editors. Depending on the user's application, there may be other objects of interest in word processing that may or may not be visible. For example, are the margins for the text on screen similar to the ones which would eventually printed? Is the spacing within a line and the line breaks similar? Are the different fonts and formatting characteristics of the text visible (without altering the spacing)? Expressed in this way, we can see the visibility criterion for direct manipulation as very similar to the criteria for a WYSIWYG interface.

Chapter 4 Usability paradigms and principles Task conformance Page 175

incremental action at the interface with rapid feedback on all actions We expect from a modern word processor that characters appear in the text as we type them in at the keyboard, with little delay. If we are inserting text within a paragraph, we might also expect that the format of the paragraph adjust immediately to accommodate the new changes. Various word processors do this reformatting automatically, whereas others do it occasionally or only at the explicit request of the user. One of the other important actions which requires incremental and rapid feedback is movement of the insertion point, usually by means of arrow keys. If there is a significant delay between the input command to move the insertion point down one line and the actual movement of the cursor on screen, it is quite possible that the user will 'overshoot' the target when repeatedly pressing the down-arrow key to move down a few lines on the screen.

Chapter 5 The design process 5.3 Using design rules Page 191

This chapter is about the process of design, and so we are concerned with when in that process design rules can be of use. Design rules are mechanisms for restricting the space of design options, preventing a designer from pursuing design options which would be likely to lead to an unusable system. Thus, design rules would be most effective if they could be adopted in the earliest stages of the life cycle, such as in requirements specification and architectural design, when the space of possible designs is still very large. However, if the assumptions underlying a design rule are not understood by the designer, it is quite possible that early application can prevent the best design choice. For example, a set of design rules might be specific to a particular hardware platform and inappropriate for other platforms (for example, colour vs. monochrome screens, one- vs. two- or three-button mouse). Such bias in design rules causes them to be applicable only in later stages of the life cycle.

Chapter 5 The design process 5.3.2 Guidelines Page 197

Use white space between long groups of controls on menus or in short groups when screen real estate is not an issue.

Chapter 5 The design process Storyboards Page 208

Modern graphical drawing packages now make it possible to create storyboards with the aid of a computer instead of by hand. Though the graphic design achievable on screen may not be as sophisticated as that possible by a professional graphic designer, it is more realistic because the final system will have to be displayed on a screen. Also, it is possible to provide crude but effective animation by automated sequencing through a series of snapshots. Animation illustrates the dynamic aspects of the intended user-- system interaction which may not be possible with traditional paper-based storyboards.

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

HyperTalk was an example of a special-purpose high-level programming language which makes it easy for the designer to program certain features of an interactive system at the expense of other system features like speed of response or space efficiency. HyperTalk and many other languages similar to it allow the programmer to attach functional behaviour to the specific interactions that the user will be able to do, such as position and click on the mouse over a button on the screen. Previously, the difficulty of interactive programming was that it was so implementation dependent that the programmer would have to know quite a bit of intimate detail of the hardware system in order to control even the simplest of interactive behaviour. These high-level programming languages allow the programmer to abstract away from the hardware specifics and think in terms that are closer to the way the input and output devices are perceived as interaction devices.

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.3 Psychological design rationale Page 219

For each question, a set of scenarios of user-- system behaviour is suggested to support the user in addressing the question. For example, to address the question 'What can I do?', the designers can describe a scenario whereby the novice programmer is first confronted with the learning environment and sees that she can invoke some demo programs to investigate how Smalltalk programs work. The initial system can then be implemented to provide the functionality suggested by the scenarios (for example, some demos would be made accessible and obvious to the user/ programmer from the very beginning). Once this system is running, observation of its use and some designer reflection is used to produce the actual psychological design rationale for that version of the system. This is where the psychological claims are made explicit. For example, there is an assumption that the programmer knows that what she can see on the screen relates to what she can do (if she sees the list of programs under a heading 'Demos', she can click on one program name to see the associated demo). The psychological claim of this demo system is that the user learns by doing, which is a good thing. However, there may also be negative aspects which are equally important to mention. The demo may not be very interactive, in which case the user clicks on it to initiate it and then just sits back and watches a graphic display, never really learning how the demo application is constructed in Smalltalk. These negative aspects can be used to modify later versions of the system to allow more interactive demos which represent realistic, yet simple, applications whose behaviour and structure the programmer can appreciate.

processed in 0.008 seconds