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 manipula- tion interface. ■ generalizability – can the user safely assume that the same operation in different cir- cumstances 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, carry- ing out text editing while printing is in progress? ■ task migratability – can particular tasks be undertaken either by the user or the sys- tem, 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 situ- ation? 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 BELL_C05.QXD 1/30/05 4:15 PM Page 58 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 met- rics 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 prin- ciple 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 prin- ciple, 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 prin- ciples 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 dur- ing 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 BELL_C05.QXD 1/30/05 4:15 PM Page 59 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. 5.6 ● Interface design 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. Construct prototype Check with user Refine prototype [User requires change] [User happy] Figure 5.1 Using prototyping in user interface design BELL_C05.QXD 1/30/05 4:15 PM Page 60 5.6 Interface design 61 SELF-TEST QUESTION 5.2 What problems can you see with this approach to design? In Chapter 2 we identified requirements analysis as an important early part of any software development project. The process of user interface design, described above, is similar to the requirements analysis phase. In interface design, the user of a system plays a central role and thus user evaluation of prototypes is probably essential. Once a user interface prototype has been created, it is evaluated to determine whether it meets the needs of the user. Evaluation can range from an informal test drive to formally designed studies that use statistical methods for the evaluation of ques- tionnaires completed by a population of end users. The evaluation cycle proceeds as follows. After a preliminary design has been com- pleted, a first prototype is created. The prototype is evaluated by the user or users, who provide the designer with comments about the efficacy of the interface. Design modifi- cations based on the user comments are then made and the next prototype is created. The cycle continues until no further modifications to the interface design are necessary. A user interface evaluation is concerned with assessing the usability of the interface and checking that it meets user requirements. Ideally, an evaluation is conducted against a usability specification – the specification of a system should include, wherever possible, quantitative values for usability attributes. Possible usability attributes are: ■ learnability – the time taken to achieve a specified level of performance ■ throughput – the speed at which the user can carry out tasks ■ robustness when confronted with user errors ■ recoverability from user errors ■ adaptability – the extent to which the system can accommodate tasks that were not envisaged during design Metrics for each of these usability attributes can be devised. For example, a learn- ability metric might state “a user who is familiar with the work supported by the system will be able to use 80% of the system functionality after a three-hour training session”. A recoverability metric might state that “a user who is familiar with the computer sys- tem will be able to recover from an error that they made in less than two seconds”. There are a number of techniques for user interface evaluation. Some involve directly monitoring users as they use the system. There are several techniques: ■ observation – someone watches users as they use the system ■ video recording – users are video recorded as they use the system ■ software monitoring – monitoring software is included to collect information as the system is used ■ verbalizing – the user speaks aloud as they use the system, relating what they are doing and what they are thinking. BELL_C05.QXD 1/30/05 4:15 PM Page 61 62 Chapter 5 ■ User interface design Most large software development organizations maintain dedicated usability labora- tories in which numbers of users are monitored while using prototypes of software products under development. An alternative approach is to use questionnaires or rating sheets to elicit views after people have used the system. Questions may ask for: ■ a simple yes or no response. For example, “Is the clear button easy to use?” ■ a numerical score on a scale of, say 1 to 10. For example, “How easy is the clear button to use?” If desired the designer can extract quantitative feedback from this information, for example, “70% of users found the clear button easy to use.” As an example we will look at the development of the ATM software specified in Appendix A. We start with the specification, which describes the functions that the ATM must carry out when requested by a bank customer. These functions are to withdraw cash and display a balance. The specification also tells us that part of the dialog with the user is the entry of a PIN and its authentication. 5.7 ● Case study Figure 5.2 Simulated ATM user interface BELL_C05.QXD 1/30/05 4:15 PM Page 62 5.8 Help systems 63 Our plan is to use prototyping to design the user interface. We assume that a decision has been taken to provide a screen that displays characters, a keyboard (with numeric keys, a cancel key and an enter key), a card reader, a printer and a cash dispenser. We assume that the system is for occasional untrained users rather than experts. We should also realize that some users will be visually impaired and/or have difficulty pressing keys. We begin by roughly sketching an interface on paper. In constructing this first pro- totype we note a list of guidelines. For example, in order to minimize overloading the user with information, we design a number of screens. We can then easily translate this into a simulated ATM using Visual Basic (or similar). One possible design is shown in Figure 5.2. This prototype user interface does everything a real system would do except read a card, dispense cash and print statements. We now show several users the proposed interface. As they use the system, we observe them, noting their difficulties, frustrations and annoyances. Help systems are just one aspect of user guidance, which deals with three areas: 1. the messages produced by the system in response to user actions 2. the on-line help system 3. the documentation provided with the system. The design of useful and clear information for users should be taken seriously and should be subject to the same quality process as designs or programs. Here are some guidelines for error messages. Error messages should always be polite, concise, consistent and constructive. They must not be abusive and should not have associated beeps or other noises which might embarrass the user. Error messages should: ■ describe the problem in jargon the user can understand ■ provide constructive advice for recovering from the error ■ spell out any negative consequences of the error ■ be accompanied by a visual cue ■ not blame the user. Help facilities may be either integrated or add-on. An integrated help facility is designed into the software from the beginning. It is usually context-sensitive, providing information relevant to what the user is doing. An add-on help facility is added to the software after the system has been built. It is often merely an on-line manual with query capability. A num- ber of design issues should be considered when a help facility is considered: ■ will help be available for all system functions at all times? ■ how will the user request help – help menu, function key, HELP command? 5.8 ● Help systems BELL_C05.QXD 1/30/05 4:15 PM Page 63 64 Chapter 5 ■ User interface design ■ how will help be represented – separate window, reference to printed document, one-line suggestion in a fixed screen location? ■ how will the user return to normal interaction – return button, function key, con- trol sequence? ■ how will the information be structured – flat, layered, hypertext? Summary There are a number of different views of the user interface – the software engi- neer’s, the user’s, the psychologist’s, the sociologist’s. A number of design guidelines and principles are available to assist in user interface design. Prototyping is currently the most effective method for user interface design. It means repeated evaluation of an interface until it meets usability standards A set of guidelines is available to assist in the design of help systems. Exercises 5.1 Identify a set of functions that might be provided by a word processor (Appendix A). Design an interface. Suggest how the interface could be evaluated. 5.2 Design a user interface for a desk calculator. It must include at least one display to show the number currently being used. It must have buttons for the functions pro- vided. These include a button for each of the digit buttons and buttons for the com- mon arithmetic operations. It should also have a clear button and an undo button. Use the guidelines and principles from the text during the design, construct a pro- totype and carry out an evaluation of the design. 5.3 Design a user interface for a website that allows the user to browse a catalog of books and choose to buy selected books by entering a credit card number, a name and address. 5.4 Perhaps the most notorious example of a poor user interface is the VCR. Design a user interface for programming a VCR to record one or more television programs using a remote control device. Assume that the television can be used as a display device during programming. • BELL_C05.QXD 1/30/05 4:15 PM Page 64 Further reading 65 5.5 Design a user interface for a mobile phone. Design suitable buttons and assume that a small display is available as part of the phone. Make assumptions about the tasks that users of the phone want to carry out. Suggest criteria for evaluating your design and suggest how the design could be evaluated (and thereby improved). 5.6 Suggest features for a web browser. Design a user interface for the browser. Suggest how the interface of the browser could be evaluated. 5.7 “User interface design is in its infancy.” Discuss. 5.8 “User interface design methods are little more than a set of guidelines. There is no proper methodology for user interface design.” Discuss. 5.9 Suggest features for a toolkit to assist in the development of graphical user interfaces. 5.10 Assess the strengths and weaknesses of user interface design methods. 5.11 Suggest a future for user interface devices and methods. Answers to self-test questions 5.1 A principle is general, abstract; a guideline is specific, concrete and applicable. 5.2 Who is the user? How many users do you involve? How many times should you go round the loop? Further reading • Wilbert O. Galitz, The Essential Guide to User Interface Design, John Wiley, 2nd edn, 2002. Susan Weinschenk, Pamela Jamar and Sarah C. Yeo, GUI Design Essentials, John Wiley, 1997. This book by one of the gurus gives good accounts of guidelines for user interface design: B. Schneiderman, Designing the User Interface: Strategies for Effective Human–Computer Interaction, Addison-Wesley, 2nd edn, 1998. A widely used and liked textbook on the subject is: Alan Dix, Janet Findlay, Gregory Abowd and Russell Beale, Human–Computer Interaction, Prentice Hall, 2nd edn, 1998. BELL_C05.QXD 1/30/05 4:15 PM Page 65 66 Chapter 5 ■ User interface design Another popular textbook book is wide-ranging, readable and comprehensive. It presents the views of a variety of people from different disciplines: Jenny Preece et al., Human–Computer Interaction, Addison-Wesley, 1994. Some light reading, guidelines and practical advice on designing GUI interfaces from the creator of Visual Basic: Alan Cooper, About Face: The Essentials of User Interface Design, IDG Books, 2003. Alan Cooper has also written this valuable book: The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore The Sanity, Sams, 1999. Well worth a read, an oldie but a goodie is: Donald Norman, The Psychology of Everyday Things, Perseus Books, 1988. This book shows how to implement GUIs using statecharts: Ian Horrocks, Constructing the User Interface with Statecharts, Addison-Wesley, 1999. BELL_C05.QXD 1/30/05 4:15 PM Page 66 Modularity is one of the key issues in software design. Modularity is to do with the structure of software. This structure is the end product of all of the major current design methods, such as functional decomposition, object-oriented design and data structure design. A perfect design is the almost unobtainable Holy Grail. If we were asked to design an automobile, we would probably design it in terms of several subsystems – engine, transmission, brakes, chassis, etc. Let us call these subsys- tems components. In identifying these particular components for an automobile, we have selected items that are as independent of each other as possible. This is the essence of good modularity. The guidelines we shall describe in this chapter help to answer questions like: ■ how big should a component be? ■ is this component too complex? ■ how can we minimize interactions between components? Before we embark on these questions, we should identify what a “component” is. Usually this is dictated by practical considerations, such as the facilities provided in the available programming language and operating system. 6.1 ● Introduction CHAPTER 6 Modularity This chapter explains: ■ the reasons for modularity ■ a classification of component types ■ considerations for component size and complexity ■ the argument against global data ■ information hiding and encapsulation ■ the terms coupling and cohesion ■ how object-oriented programming supports modularity. BELL_C06.QXD 1/30/05 4:18 PM Page 67 . interface. We assume that a decision has been taken to provide a screen that displays characters, a keyboard (with numeric keys, a cancel key and an enter key), a card reader, a printer and a cash. suitable buttons and assume that a small display is available as part of the phone. Make assumptions about the tasks that users of the phone want to carry out. Suggest criteria for evaluating. 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