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

Search Results

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

Chapter 4 Usability paradigms and principles Task conformance Page 175

Discuss the ways in which a full-page word processor is or is not a direct manipulation interface for editing a document using Shneiderman's criteria. What features of a modern word processor break the metaphor of composition with pen (or typewriter) and paper?

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 4 Usability paradigms and principles Exercises Page 177

4.1 What was the problem with the synthesis example comparing a command language interface with a visual interface? Can you suggest a fix to make a visual interface really immediately honest?

Chapter 5 The design process 5.2.4 Interactive systems and the software life cycle Page 187

The life cycle for development we described above presents the process of design in a somewhat pipeline order. In reality, even for batch-processing systems, the actual design process is iterative, work in one design activity affecting work in any other activity both before or after it in the life cycle. We can represent this iterative relationship as in Figure 5.4, but that does not greatly enhance any understanding of the design process for interactive systems. You may ask whether it is worth the intellectual effort to understand the interactive system design process. Is there really much design effort spent on the interactive aspects of a system to warrant our attention? A classic survey in 1978 by Sutton and Sprague at IBM resulted in an estimate that 50% of the designer's time was spent on designing code for the user interface [234]. A more recent and convincing survey by Myers and Rosson has confirmed that that finding holds true for the 1990s [169]. It is definitely worth the effort to provide structure and techniques to understand, structure and improve the interactive design process! In this subsection, we will address features of interactive system design which are not treated properly by the traditional software life cycle.

Chapter 5 The design process 5.3.1 Standards Page 192

Figure 5.6 provides examples of the language of standards for displays. Note the increasing generality and vagueness of the language as we progress from the hardware issues in a UK defence standard for pilot cockpit controls and instrumentation through a German standard for user interface design of display workstations to a US military standard for display contents.

Chapter 5 The design process 5.3.2 Guidelines Page 193

We have observed that the incompleteness of theories underlying the design of interactive software makes it difficult to produce authoritative and specific standards. As a result, the majority of design rules for interactive systems are suggestive and more general guidelines. Our concern in examining the wealth of available guidelines is in determining their applicability to the various stages of design. The more abstract the guideline, the more it resembles the principles which we outlined in Chapter 4, which would be most suited to requirements specification. The more specific the guideline, the more suited it is to detailed design. The guidelines can also be automated to some extent, providing a direct means for translating detailed design specifications into actual implementation. There are a vast amount of published guidelines for interactive system design (they are frequently referred to as guidelines for user interface design). We will present only a few examples here to demonstrate the content of guidelines in that vast literature.

Chapter 5 The design process 5.3.2 Guidelines Page 195

A major concern for all of the general guidelines is the subject of dialog styles, which in the context of these guidelines pertains to the means by which the user communicates input to the system, including how the system presents the communication device. Smith and Mosier identify eight different dialog styles and Mayhew identifies seven (see Table 5.1 for a comparison). The only real difference is the absence of query languages in Mayhew's list, but we can consider a query language as a special case of a command language. These interface styles have been described in more detail in Chapter 3.

Chapter 5 The design process 5.3.2 Guidelines Page 196

In moving from abstract guidelines to more specific and automated ones, it is necessary to introduce assumptions about the computer platform on which the interactive system is designed. So, for example, in Apple's Human Interface Guidelines: the Apple Desktop Interface, there is a clear distinction between the abstract guidelines (or principles), independent of the specific Macintosh hardware and software, and the concrete guidelines, which assume them. The abstract guidelines provide the so-called philosophy of programming that Apple would like designers to adopt in programming applications for the Macintosh. The more concrete guidelines are then seen as more concrete manifestations of that philosophy.

Chapter 5 The design process 5.3.2 Guidelines Page 196

We considered issues of dialog initiative in Chapter 4 under the general usability category of flexibility. As we mentioned there, the issue of dialog initiative involves a trade-off between user freedom and system protection. In general, single-user computer systems operate in strict abidance of this guideline for user control; the user is allowed to initiate any dialog at all with the computer, whether or not it will have the intended result. Part of the success of direct manipulation interfaces lies in their ability to constrain user interaction to actions which are both syntactically correct (for example, preventing errors due to slips in typing) and will probably correspond to the intended user tasks.

processed in 0.007 seconds