This Powerpoint accompanies a lesson plan for AS91371 (2.44) that is available via (level 2

Transcription

1 This Powerpoint accompanies a lesson plan for AS91371 (2.44) that is available via (level 2 computer science). We encourage you to improve and share this document. It is Licensed under a Creative Commons Attribution-Noncommercial-ShareAlike 3.0 License: You may use these slides, alter them, and share new versions, as long as you retain the credits on this page, and license a new version under the identical terms. The slides are intended for presentation, not for giving to students, as they aren t self explanatory. We provide notes for each slide that you can use as a prompt when you present them. 1

2 The heuristics used in this presentation originate from Nielson s book (chapter 5) although it is a lot more detailed than needed for NCEA, and is fairly old. Johnson s book is a very approachable read that will help sensitise you to general issues in HCI. 2

3 It is easy to think of a digital system as an entity in itself, but really the actual system involves a user who uses a device through a user interface. The system that has to work well is everything inside the box. A computer scientist needs to understand all those parts of the system, and not just the device. The study of Human Computer Interaction involves a lot of psychology (how people behave) because this affects how they will use a system. As a simple example, human short term memory is typically around 8 seconds. If a device delays for more than 8 seconds, the user has to make a conscious effort to remember what they were doing, and that s extra work for the user (from their point of view, the system is more tiring to use). Another example (used later on) is that people are better at recognising things than remembering them. 3

4 There are many books about using digital devices marketed to dummies. Of course, most of those people aren t dummies, but they feel dumb because the device isn t ideally designed well for real humans. Even worse, some computer developers think that their users are dummies and that any interface problems are the user s fault and not the developer s, but the real problem is that the developer knows the system really well, whereas the user just wants to get their job done without having to spend a lot of time learning the software if the software is too hard to use, they ll just find something else that s easier. Good interfaces are worth a lot in the market. 4

5 User interfaces are all over the place, and for this standard it s easier to pick a simple device with just a few buttons rather than complex software with hundreds of options. Just setting the time on an alarm clock can be frustrating for many people, and usability evaluation can help to explain why, and point to how you might design a better system. 5

6 The heuristics discussed here are from Jakob Nielson s website: This slide is just an overview of the ten heuristics; we will look at examples for each one. A heuristic is just a rule of thumb or guideline. The main point of these is that you can consider aspects of an interface design, and decide if it obeys all these heuristics. They aren t hard and fast rules, and it s very hard to design an interface that always follows all the heuristics. But if something is frustrating about an interface, it s likely to be going against one or more of these heuristics. 6

7 Looking at examples is a good way to sensitise students to the kinds of issues that can be commented on. We have provided some examples in the following slides, but teachers are encouraged to substitute examples from their own experience. Many of them are humorous, but some have serious consequences (including deleting important files or booking a flight for the wrong day). There are other examples not used here where bad interface design has led to loss of life e.g. in aircraft controls, but the emphasis here is differentiating between adequate designs that do the job, and great designs where the user feels empowered by the interface rather than frustrated. Many of the problems students find might be relatively minor, but bear in mind that millions of people might experience the small frustration from that small problem, or a few people might have to experience those frustrations many times each day as they do their work. 7

8 This is the first heuristic in Nielson s list. As an example, some people complain about devices where an indicator light comes on to show that it is in standby mode and switches off when the device is switched on the appropriate feedback for showing that the power is on is usually having the light on, not off, to show that the power is on. 8

9 What is a reasonable amount of time for this heuristic? For humans, the above time scales are reasonable (this is discussed in Johnson s book). If computer responds in about 1/10 th of a second (e.g. clicking on a checkbox and it activates) it will appear to be instant, and if it takes longer, it may seem that it hasn t activated and the user will click it again, usually leading to confusion because in the real world we re used to instant response (e.g. you turning on a tap or switching on a light). Around 1 second is what people are used to in conversation, so if a series of interactions suddenly has a delay of more than 1 second (maybe while a disk is starting up or a large image is loading in a web page) it can throw the user s train of thought, much like an interrupted conversation. Around 8 seconds is the length of short-term memory, so systems that take longer than 10 seconds to respond need to keep the user informed about what is happening, usually with a progress indicator, which ideally should indicate how long the process will take. The speed of feedback is one of the strong motivators for knowing about fast algorithms (which was covered in AS91074/1.44); if one algorithm takes 2 seconds to sort a list and another takes 1 second, the latter is going to seem a lot more interactive; and if another takes 1/10 th of a second, the user will perceive that the system couldn t be faster. 9

10 The examples here are from on-line banking. In each case the amount is incorrect because of the use of $,, or an extra space (after the ), but in the world that the user is familiar with, these are usual conventions. The was pasted from another document, so the user wouldn t even be aware that a space had been copied with it, and the space isn t visible. These examples also relate to the later heuristic about errors, and the previous one about visibility of system status (you can t see the space in the ). 10

11 A common error with matching with terms familiar to the user is cultural assumptions. In some countries 12/11/2011 would be December 11. Giving prices without currency leaves the user wondering (or making a wrong assumption). Having switches where up is on is confusing for NZ users. Another example would be requiring users to enter a 5-digit zip code or their state (which don t apply in NZ). 11

12 Sometimes the presentation is misleading e.g. green usually means go and yellow/orange means caution, but in this dialogue the green button will wipe all the previous data the user has entered, and orange is the one to press to go ahead. 12

13 It is very frustrating to make a mistake and not be able to get out of it; having undo encourages users to explore more. It is particularly bad if one small action can wipe a lot of work that can t be recovered (the reset button on web forms is infamous for this you can wipe all your data and not retrieve it by pressing one button at the end of the form; in the example on this slide, missing the submit button by a few pixels can do that). 13

14 In this case the computer will reboot in 4:20 minutes, and the user cannot press the No button. They are trapped. Too bad if they are about to give a presentation in 3 minutes time. 14

15 This page warns that the user may be subject to penalties, fines or imprisonment if they access the system inappropriately. However, with only an OK button, the user has no choice but to carry on and enter the system, even if they decide they don t want to agree to the conditions given. 15

16 Consistency is sometimes called the golden rule of HCI. If an interface is consistent with other interfaces then learning in one interface transfers directly to another. A positive example of consistency is copy and paste, which works the same in most software, so users only have to learn the concept once. But in some software (e.g. Excel) copy/paste behaves differently, and this can be confusing for users. Even within Excel actions can have inconsistent responses; things like clicking on a cell or typing control-a (select all) depends on whether you are editing a cell or not (this particular problem is called a mode ). Users can get very confused when the same action causes a different response. 16

17 The system shouldn t make it easy for people to make serious errors. For example, if a menu item isn t relevant at the moment, it is usually made grey and won t work; sometimes you ll find a menu item that can be chosen, but then says you ve made an error by choosing it! 17

18 The system gives good feedback on this error, but it would have been a lot easier for the user if it was programmed so that single digit months were detected and had a 0 put in front of them automatically, rather than making the user type it. Bear in mind that in this situation the user may be under pressure to complete the transaction before it times out. 18

19 In this case the error might have been prevented by not even asking the user to enter a number! 19

20 This system waited until after the user had entered a large amount of text, and then warned that it was too long. It could have been improved by saying in advance that there is a limit, or even better, showing how many remaining characters can be typed after each keystroke. Again, bear in mind that the user may be under stress when using this site. 20

21 Often a problem will correspond to a number of heuristics. For example, on this phone, if you type a text message and then press the Send button, it will delete the message and make a phone call. This is because on early phones Send meant to connect for a phone call, but in the user s world, Send means to send the message. It is poor error prevention an obvious mistake deletes the message and it can t be recovered, and it s inconsistent on most modern phones Send is what you do for text messages, not for making a call. 21

22 Computers are good at remembering precise details like URLs and codes, whereas humans are better at recognising them. Automatic completion of URLs is a positive example of this, where the computer only asks the user to recognise the details of the URL. Negative examples are when the user has to remember commands or codes and type them exactly. 22

23 Keyboard shortcuts are a good example of allowing expert users to work faster, while still providing (slower) menus for new users. Experts will use the system enough that they can recall commands, but new users are best with recognition. The shortcut information remains in the menu so that if an expert forgets a shortcut (perhaps they haven t used the software for a while) or starts using a new feature frequently for a particular task, they can identify it easily. The software should allow users to make their own shortcuts; for example, Paste special in this example doesn t have a shortcut, but if it is needed a lot then the settings can be changed to allocate a keystroke to it. 23

24 Large panels of buttons may be intimidating and confusing for users, even if they make the software look impressive. The image above is from Band-in-a-box, which is a very clever program, but was once voted the worst interface on the planet due to its massive array of icons and strange behaviour! 24

25 It s not hard to find error messages that don t really tell you what s wrong! 25

26 This error message for a hotel reservation doesn t say what the problem is it could be a wrong credit card number, no rooms available on the dates requested, or a missing detail. The feedback provides no help in working out how to fix it, and the user is likely to try booking a different hotel instead of trying out various options to get rid of the error. This also relates to the first heuristic (keep users informed about what is going on, through appropriate feedback) 26

27 The feedback gives two possible reasons for the error. The computer should be able to work out which of the problems has happened, and give the user more precise feedback so they can address the problem. 27

28 Vague error messages are very frustrating, and number codes are meaningless (or at least, the user is forced to search for them in the hope they ll find some help). 28

29 Not only does the error not say what the error is, it essentially encourages the user to ignore the error. Even worse, the three buttons, skip, cancel and ignore, all seem to mean the same thing. (The actual error is the configuration of a router i.e. the configuration may mean that access to the internet doesn t work properly, which is a different concern to having a flashing light on the unit!) 29

30 Often help is an afterthought, and tends to be feature-centred (e.g. a catalogue of menu items), rather than task-centred (the series of actions needed to complete typical tasks, which is more useful for the user). 30

31 It s not unusual for the help to be unhelpful for common problems. 31