Serie 3 Interaction Design Basics, HCI in the Software Process & Design Rules Vorbesprechung: Dienstag, den 21. Oktober 2008 Abgabe: Dienstag, den 28. Oktober 2008 zu Beginn der Übungsstunde Rückgabe und Nachbesprechung: Dienstag, den 4. November 2008 Übungsteil Aufgabe 1 Look at some or all of the following objects: a book, a pair of scissors, a cup, a corkscrew. Discuss the affordances of the objects and the constraints that these place on their use. Aufgabe 2 Imagine you have been asked to produce a prototype for the diary system discussed in the worked exercise from Section 7.2.3 from the HCI book (see appendix). What would be an appropriate prototyping approach to enable you to test the design using the usability metrics specified, and why? Pflichtteil The following exercises refer to the nuclear reactor scenario (see the following section). Aufgabe 3 Comment on the use of colour in the Alarm Control, Emergency Shutdown and Emergency Confirm panels (figure 2). Aufgabe 4 Comment on the use of layout and other elements in the control panels (figures 1, 2 and 3), including the way in which various visual elements support or hinder logical grouping and sequence. Aufgabe 5 Working through the accident scenario explain why the various problems arise. Aufgabe 6 Suggest potential ways of improving the interface to avoid a similar problem recurring. Nuclear Reactor Scenario 1 Note: This does not represent any real reactor although the sorts of problems it highlights do occur in real control rooms. Figure 1 shows a sketch of the control panel of a nuclear power plant. The actual panel is very large covering the whole wall of the control room and contains many subpanels and controls. The locations of some controls at the two ends of the panel are 1 text and figures from http://www.hcibook.com/e3/scenario/nuclear/ 1
Figure 1: nuclear reactor main control panel shown in figure 1, although it should be noted that the panel is much wider than the illustration. A few of the sub-panels are important for this case study: Alarm Control panel Emergency Shutdown panel Emergency Confirm panel Reactor Targets display Manual Override panel Numeric Keypad for the Manual Override panel Details of the first three of these are shown in figure 2 and details of the last three in figure 3. How it works The system can be in one of three alarm states: Green, Amber or Red. 2
Figure 2: alarm and emergency sub-panels Figure 3: reactor targets display and manual override 3
Figure 4: STN for alarm state (i) Green alarm state means everything is operating normally (ii) Amber alarm state is for when there is a minor problem with reactor operation. Workers in the reactor area are warned and take additional precautions, but no external services are involved. (iii) Red alarm state is raised when the reactor is operating outside normal parameters and there is a possibility of external contamination. The police and other emergency services are alerted. Typically Amber state is raised once or twice a week and red state only a few times a year (so far only false alarms!). Raising a Red alarm unnecessarily causes significant inconvenience and cost both to the station staff and the external emergency services. Original design of the alarm control panel When the plant was commissioned, the alarm system controls worked as follows. The current alarm state is indicated by which of the coloured lights on the Alarm Control panel is lit.. The + and buttons on this panel increase or decrease the alarm state. Figure 4 shows a state transition network of the effects of the + and buttons on the state as the system was initially installed. Emergency Shutdown When there is a very serious problem the operator can press the large red button labelled Immediate Shutdown Commence on the Emergency Shutdown panel, which initiates an emergency shutdown. This needs to be confirmed by pressing the Confirm button on the Emergency Confirm panel. (This is to prevent accidental shutdown of the plant.) The Confirm button is normally green, but glows red after the Immediate Shutdown Commence button has been pressed to remind the operator. Emergency shutdown causes explosive bolts to blow that drive control rods into the reactor completely stopping the nuclear reaction. Restarting the reactor after emergency 4
Figure 5: STN for revised alarm state shutdown may take several weeks and costs many millions of pounds in lost production and replacement of parts damaged during the shutdown procedure. Reactor targets and manual override The Reactor Targets panel shows the current target state of several reactor operating parameters. These are normally set by an automatic control system to values that ensure optimal energy production. In an extreme emergency the operator may need to control these targets. The Manual Override panel allows this. Manual override is only enabled in Red alarm state. To override a particular target the operator selects the desired target (Pressure, Temperature or Flow Rate) from a dropdown menu, types in the desired value using a numeric keypad and then confirms the value using the Set button. (The Set button is necessary to prevent part-typed numbers being treated as the new value.) Revised Alarm Control Operation Some while after the plant was running a consultant suggested changing the operation of the Alarm Control panel and the software and hardware was revised in line with his recommendations. The current design works as follows. Raising the alarm state from Green to Amber and back uses the + and buttons as before. However now to raise the state from Amber to Red it is necessary to both press + and also confirm this by pressing the Confirm button on the Emergency Confirm panel. Figure 5 shows the state transition network of the revised system. Emergency Scenario Jenny, the Nuclear Power Plant operator has normal sight and no physical or perceptual impairments. Her shift started at 11pm and it is now 5am in the morning. So far 5
the plant has been operating within normal parameters and the current alarm state is therefore green. 1. Jenny notices the core reaction rate has risen very rapidly 2. she realises she must immediately change the reactor target pressure to correct this 3. she goes to the Alarm Control Panel on the far right of the main reactor control panel and presses + twice (as it is starting off in green state) 4. the Emergency Confirm button glows red 5. she moves across to the Manual Override panel on the far left of the main reactor control panel 6. she selects Pressure from the pull down on the Manual Override panel 7. she types the new value 6000 using the keypad 8. she notices that the number on the Reactor Targets panel has not changed 9. she realises she forgot to press the Set button on the Manual Override panel 10. she presses the Set button 11. the value still doesn t change 12. an automatic audio warning sounds 60 seconds to core meltdown 13. she presses the Set button repeatedly 14. still the value doesn t change 15. she starts again, selects Pressure from the pulldown, types 6000 and presses Set 16. still the value doesn t change 17. the audio warning says 30 seconds to core meltdown 18. Jenny runs across the room to the Emergency Shutdown panel 19. 20 seconds to core meltdown 20. she presses Immediate Emergency Commence button 21. the emergency confirm button glows red 22. 10 seconds to core meltdown 23. she presses the Emergency Confirm button 24. she hears the crash of the explosive bolts sending the control rods into the reactor 25. the audio system announces reactor shutdown successful 6
Attribute: Measuring concept: Measuring method: Now level: Worst case: Planned level: Best case: Guessability Ease of first use of system without training Time to create first entry in diary 30 seconds on paper-based system 1 minute 45 seconds 30 seconds (equivalent to now) Table 1: A sample usability specification Appendix: Worked Exercise 7.2.3 2 Worked exercise Look at some of the principles outlined in this section, and use one or two to provide a usability specification (see Chapter 6, Section 6.3) for an electronic meetings diary or calendar. First identify some of the tasks that would be performed by a user trying to keep track of future meetings, and then complete the usability specification assuming that the electronic system will be replacing a paper-based system. What assumptions do you have to make about the user and the electronic diary in order to create a reasonable usability specification? Answer This exercise could be easily extended to a small project which would involve the design of such an electronic diary or calendar. The purpose of this smaller usability engineering exercise is to show how usability goals can be formulated early on to drive the design activity. We will select two of the usability principles from this chapter, which will serve as attributes for separate usability specifications. In the first example, we will consider the interaction principle of guessability, which concerns how easy it is for new users to perform tasks initially. The measuring concept will be how long it takes a new user, without any instruction on the new system, to enter his first appointment in the diary. A sample usability specification is given in table 1 The values in the usability specification from table 1 might seem a little surprising at first, since we are saying that the best case is only equivalent to the currently achievable now level. The point in this example is that the new system is replacing a very familiar paper and pencil system which requires very little training. The objective of this system is not so much to improve guessability but to preserve it. Earlier, we discussed that the worst case level should not usually be worse than the now level, but we are hoping for this product to improve overall functionality of the system. The user will be able to do more things with the electronic diary than he could with the conventional system. As a result, we worry less about improving its guessability. Perhaps we could have been more 2 from Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale Human-Computer Interaction, 3rd edition, Pearson Education, 2004, pages 273 275 7
Attribute: Measuring concept: Measuring method: Now level: Worst case: Planned level: Best case: Task migratability Scheduling a weekly meeting time it takes to enter a weekly meeting appointment (Time to schedule one appointment) (Number of weeks) Time to schedule two appointments 1.5 (Time to schedule one appointment) time to schedule one appointment Table 2: Another sample usability specification ambitious in setting the best case value by considerung the potential for voice input or other exotic input techniques that would make entry faster than writing. As another example we want to support the task migratability of the system. A frequent sort of task for a diary is to schedule weekly meetings. The conventional system would require the user to make an explicit entry for the meeting each week - the task of the scheduling is the responsibility of the user. In the new system, we want to allow the user to push the responsibility of scheduling over to the system, so that the user need only indicate the desire to have a meeting scheduled for a certain time each week and the system will take care of entering the meeting at all of the appropriate times. The task of scheduling has thus migrated over to the system. The usability specification for this example can be found in table 2. In the specification from table 2, we have indicated that the now level is equivalent to the time it takes to schedule each appointment separately. The worst, planned and best case levels are all targeted at some proportion of the time it takes to schedule just a single appointment a dramatic improvement. The difference between the worst, planned and best case levels is the amount of overhead it will take to indicate that a single appointment is to be considered an example to be repeated at the weekly level. What are the assumptions we have to make in order to arrive at such a usability specification? One of the problems with usability specifications, discussed earlier, is that they sometimes require quite specific information about the design. For example, had we set one of our measuring methods to count keystrokes or mouse clicks, we would have had to start making assumptions about the method of interaction that the system would allow. Had we tried to set a usability specification concerning the browsing of the diary, we would have had to start making assumptions about the layout of the calendar (monthly, weekly, daily) in order to make our estimates specific enough to measure. In the examples we have provided above, we have tried to stay as abstract as possible, so that the usability specifications could be of use as early in the design life cycle as possible. A consequence of this abstractness, particularly evident in the second example, is that we run the risk in the usability specification of setting goals that may be completely unrealistic, though well intentioned. If the usability specification were to be used as a contract with the customer, such speculation could spell real trouble for the designer. 8