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 57 A novice user or an occasional user is not likely to remember much about how to use the system. Thus a direct manipulation interface may be the most suitable approach. But an experienced and frequent user may be frustrated by an interface designed for novices and may prefer shortcut commands and/or a command line interface. For example, a number of applications provide a macro facility, in which a series of commands can be grouped together, parameterized and invoked as a single command. Again the need for flexibility in the interface becomes apparent. The skill level of the end user has a significant impact on the ability to extract meaningful information from the user interface, respond efficiently to tasks that are demanded by the interaction, and effectively apply heuristics that create a rhythm of interaction. It seems that context- or domain-specific knowledge is more important than overall education or intelligence. For example, an engineer who uses a computer-based diagnostic system to find faults in automobiles understands the problem domain and can interact effectively through an interface specifically designed to accommodate users with an engineer’s background. This same interface might confuse a physician, even though the physician has considerable experience of using a computer for diagnosing illnesses in patients. The software developer may unconsciously incorporate into the user interface some assumptions about the implementation that are irrelevant or even confusing for the users. Consider a word processor, for example. What the user wants is to create and edit documents, and they know that documents reside in files on a disk. The user probably understands the concept of opening a file, because this is a familiar concept in using manual files, but the idea of saving a file may well be completely mysterious to them. The reason is that the concept of saving a file derives from the developer’s mental model of how a word processor works, that is, it keeps all or part of the document in main memory. This example illustrates how the designer can get it wrong and therefore the importance of the involvement of the user in design. In conclusion, there are a number of different viewpoints taken by the users and developers of a user interface. There is scope for either conflict or harmony between these views. Conflict between the users’ perception and the developers’ concepts can make for a system that is difficult to use, but involving the users in the design can assist in recognizing users’ views, and flexibility in the interface can help cater for different users. 5.5 ● Design principles and guidelines Design principles are high-level principles that can guide the design of a user interface. Three overall principles are: ■ learnability – how easily can new users learn to use the system? ■ flexibility – does the interface support a variety of interaction styles? (We have already seen why this is an important consideration.) ■ robustness – how much feedback does the system give the user to confirm what is going on?
58 Chapter 5 ■ User interface design Each of these qualities can be specified in greater detail as follows: Learnability involves: ■ predictability – is the effect of any of the user actions predictable? A user should never be surprised by the behavior of a system. ■ synthesizability – can the user see the effect of their actions? A counter-example of this characteristic is some Unix commands, which give the user no information or even a confirmation of what they have accomplished. ■ familiarity – are the facilities familiar to the user from their previous experience? The interface should use terms and concepts which are drawn from the anticipated class of user. This attribute will clearly be more easily achieved with an direct manipulation interface. ■ generalizability – can the user safely assume that the same operation in different circumstances gives the same outcome? For example, does clicking the mouse button on a folder icon have the same effect as clicking on a file icon? ■ consistency – are comparable operations activated in the same way? For example, in a word processor, is the selection of a single character, a word, a line or a paragraph achieved in a consistent manner? Flexibility involves: ■ user initiative – can the user initiate any valid task whenever they desire? This is an issue of who is in control, the user or the machine. ■ multi-threading – can several tasks be carried out concurrently? For example, carrying out text editing while printing is in progress? ■ task migratability – can particular tasks be undertaken either by the user or the system, or some combination of the two? For example, some e-mail systems provide for automatic response to e-mail while the user is on vacation. ■ substitutivity – can a facility be used in different ways? For example, selecting font size either from a menu or by typing font size explicitly. ■ customizability – can the user change the user interface? For example, hiding an unwanted tool bar, adding macros or scripts. Robustness involves: ■ observability – does the system display information that allows the user fully to know what is going on? Again, this attribute will clearly be more easily achieved with a direct manipulation interface. ■ recoverability – does the system allow the user to recover from an unintended situation? For example, the provision of an undo button can help rectify certain user mistakes. ■ responsiveness – does the system respond in a reasonable time? Response time has two characteristics, length and variability. Variability refers to the deviation from average response time, and is in some ways more important than length, because it can affect the user’s rhythm. So it is sometimes better to have equal length
- Page 30 and 31: 100% 10% 1970 SELF-TEST QUESTION Ha
- 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 82 and 83: 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
5.5 Design principles and guidelines 57<br />
A novice user or an occasional user is not likely to remember much about how to<br />
use the system. Thus a direct manipulation interface may be the most suitable<br />
approach. But an experienced and frequent user may be frustrated by an interface<br />
designed <strong>for</strong> novices and may prefer shortcut commands and/or a command line<br />
interface. For example, a number of applications provide a macro facility, in which a<br />
series of commands can be grouped together, parameterized and invoked as a single<br />
command. Again the need <strong>for</strong> flexibility in the interface becomes apparent.<br />
The skill level of the end user has a significant impact on the ability to extract meaningful<br />
in<strong>for</strong>mation from the user interface, respond efficiently to tasks that are demanded<br />
by the interaction, and effectively apply heuristics that create a rhythm of interaction.<br />
It seems that context- or domain-specific knowledge is more important than overall<br />
education or intelligence. For example, an engineer who uses a computer-based diagnostic<br />
system to find faults in automobiles understands the problem domain and can<br />
interact effectively through an interface specifically designed to accommodate users<br />
with an engineer’s background. This same interface might confuse a physician, even<br />
though the physician has considerable experience of using a computer <strong>for</strong> diagnosing<br />
illnesses in patients.<br />
The software developer may unconsciously incorporate into the user interface some<br />
assumptions about the implementation that are irrelevant or even confusing <strong>for</strong> the<br />
users. Consider a word processor, <strong>for</strong> example. What the user wants is to create and edit<br />
documents, and they know that documents reside in files on a disk. The user probably<br />
understands the concept of opening a file, because this is a familiar concept in using<br />
manual files, but the idea of saving a file may well be completely mysterious to them.<br />
The reason is that the concept of saving a file derives from the developer’s mental model<br />
of how a word processor works, that is, it keeps all or part of the document in main<br />
memory. This example illustrates how the designer can get it wrong and there<strong>for</strong>e the<br />
importance of the involvement of the user in design.<br />
In conclusion, there are a number of different viewpoints taken by the users and<br />
developers of a user interface. There is scope <strong>for</strong> either conflict or harmony between<br />
these views. Conflict between the users’ perception and the developers’ concepts can<br />
make <strong>for</strong> a system that is difficult to use, but involving the users in the design can<br />
assist in recognizing users’ views, and flexibility in the interface can help cater <strong>for</strong> different<br />
users.<br />
5.5 ● Design principles and guidelines<br />
Design principles are high-level principles that can guide the design of a user interface.<br />
Three overall principles are:<br />
■ learnability – how easily can new users learn to use the system?<br />
■ flexibility – does the interface support a variety of interaction styles? (We have<br />
already seen why this is an important consideration.)<br />
■ robustness – how much feedback does the system give the user to confirm what is<br />
going on?