Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
5.5 Design principles and guidelines 59 response times (even if they are long) in preference to response times that are unpredictable. ■ task conformance – does the system do everything that the user needs to do? Is some facility missing? It should be emphasized that this list of principles, useful though it is, constitutes just one of several possible categorizations of desirable attributes. Alternative factors that might be considered equally important include user error prevention, minimizing the user’s memory requirements and maximizing productivity. Principles like these are distilled from practical experience, controlled experiments and an understanding of human psychology and perception. They serve as goals to aim for during development. They can also act as quality factors (see Chapter 29 on metrics and quality assurance) that can be used to assess the quality of a completed design. For example, if recoverability is important for a particular application, an assessment of this quality can be made in order to evaluate the success of the product. Let us see how a principle, such as those above, differs from a guideline. The principle of task conformance, for example, tells us what to look for, what to aim for, but not how to achieve it – and it can sometimes be difficult to identify something that is missing. By contrast, a guideline, such as “black text on a white background is easier to read than the opposite”, is immediately useful and applicable. The drawback of principles is that they are not immediately applicable, but have to be interpreted and applied (as with real life principles). The last example of a principle, task conformance, illustrates a major problem with using these principles for user interface design – it is not always obvious how or when to use them. The designer could post the principles up above their desk so that they can see them and use them while they carry out design, but there is no explicit way of using the principles as part of a well-defined design methodology. Thus they are more akin to goals than principles. Design guidelines or rules give the designer more detailed and specific advice during the process of designing an interface. There are many long lists of guidelines in the literature and we give here only a sample of typical guidelines. If you were asked to design an interface for an application running under Microsoft Windows, for example, you would be provided with a comprehensive manual of guidelines specific to the look and feel of Windows applications. Among the many guidelines this would stipulate, for example, that the icon to close an application must be displayed at the top right of the window as a cross. Using guidelines such as these promotes the principle of consistency mentioned above. Here, for illustration, are some examples of guidelines for designing GUI interfaces: ■ ask the user for confirmation of any non-trivial destructive action (e.g. deleting a file) ■ reduce the amount of information that must be memorized in between actions ■ minimize the number of input actions required of the user, e.g. reduce the amount of typing and mouse travel that is required ■ categorize activities by function and group related controls together ■ deactivate commands that are inappropriate in the context of current actions
60 Chapter 5 ■ User interface design ■ display only the information that is relevant to the current context ■ use a presentation format that enables rapid assimilation of information, e.g. graphs and charts to present trends ■ use upper and lower case, indentation and text grouping to aid understanding ■ use windows to compartmentalize different types of activity ■ consider the available geography of the display screen and use it efficiently ■ use color sparingly. (Designers should take account of the fact that a significant number of people are color-blind.) These guidelines are more detailed and specific than the rather more generalized principles given earlier. SELF-TEST QUESTION 5.1 Distinguish between user interface design guidelines and principles. 5.6 ● Interface design The process for designing a user interface begins with the analysis of the tasks that the user needs to carry out. The human- and computer-oriented tasks are then delineated, general design principles and guidelines are considered, tools are used to prototype a system, and the result is evaluated for quality. The prototype is then refined repeatedly until it is judged satisfactory. This can be visualized as shown in Figure 5.1. [User happy] Construct prototype Check with user [User requires change] Figure 5.1 Using prototyping in user interface design Refine prototype
- Page 32 and 33: Analysis and design 1 /3 Coding 1 /
- Page 34 and 35: SELF-TEST QUESTION 1.7 Maintenance
- Page 36 and 37: 1.8 Reliability 13 in the first pla
- Page 38 and 39: 1.8 Reliability 15 contain a comma
- Page 40 and 41: Ease of maintenance Reliability Con
- Page 42 and 43: Exercises 19 • Exercises These ex
- Page 44 and 45: Further reading 21 Analyses of the
- Page 46 and 47: ■ documentation ■ maintenance
- Page 48 and 49: 2.2 The tasks 25 An important examp
- Page 50 and 51: 2.4 Methodology 27 reality. Like an
- Page 52 and 53: ■ error free ■ fault ■ tested
- Page 54 and 55: 3.2 ● Technical feasibility 3.3 C
- Page 56 and 57: 3.5 Case study 33 The hardware cost
- Page 58 and 59: Answers to self-test questions 3.1
- Page 60 and 61: 4.2 The concept of a requirement 37
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 64 and 65: 4.5 The requirements specification
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 78 and 79: 5.3 Styles of human-computer interf
- Page 80 and 81: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 90 and 91: CHAPTER 6 Modularity This chapter e
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- Page 106 and 107: > } public void setY(int newY) { y
- Page 108 and 109: • Exercises 6.1 What is modularit
- Page 110 and 111: CHAPTER 7 Structured programming Th
- Page 112 and 113: 7.2 Arguments against goto 89 If we
- Page 114 and 115: ■ if-then-else ■ while-do or re
- Page 116 and 117: 7.3 Arguments in favor of goto 93 l
- Page 118 and 119: 7.4 Selecting control structures 95
- Page 120 and 121: while do if endif then else endWhil
- Page 122 and 123: • Exercises 7.1 Review the argume
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
- Page 128 and 129: start button event create defender
- Page 130 and 131: 8.3 ● Discussion Abstraction One
60 Chapter 5 ■ User interface design<br />
■ display only the in<strong>for</strong>mation that is relevant to the current context<br />
■ use a presentation <strong>for</strong>mat that enables rapid assimilation of in<strong>for</strong>mation, e.g. graphs<br />
and charts to present trends<br />
■ use upper and lower case, indentation and text grouping to aid understanding<br />
■ use windows to compartmentalize different types of activity<br />
■ consider the available geography of the display screen and use it efficiently<br />
■ use color sparingly. (Designers should take account of the fact that a significant<br />
number of people are color-blind.)<br />
These guidelines are more detailed and specific than the rather more generalized<br />
principles given earlier.<br />
SELF-TEST QUESTION<br />
5.1 Distinguish between user interface design guidelines and principles.<br />
5.6 ● Interface design<br />
The process <strong>for</strong> designing a user interface begins with the analysis of the tasks that the<br />
user needs to carry out. The human- and computer-oriented tasks are then delineated,<br />
general design principles and guidelines are considered, tools are used to prototype a<br />
system, and the result is evaluated <strong>for</strong> quality. The prototype is then refined repeatedly<br />
until it is judged satisfactory. This can be visualized as shown in Figure 5.1.<br />
[User happy]<br />
Construct<br />
prototype<br />
Check with<br />
user<br />
[User requires change]<br />
Figure 5.1 Using prototyping in user interface design<br />
Refine<br />
prototype
Change language