4. Human-computer interaction

Warning

This chapter is still in development

Warning

This chapter hasn’t been written yet, but in the meantime there is a lesson plan that covers the material available from the NZACDITT site level 1 plan and the NZACDITT site level 2 plan. The content of this chapter will mainly support these lesson plans.

Note

For teachers

This chapter supports the user interfaces and usability part of the NZ achievement standard AS91074 (1.44) and the Human-Computer Interfaces and Usability Heuristics part of the NZ achievement standard AS91371 (2.44). The level 1 standard requires a general critical view of interfaces, whereas the level 2 standard requires the usability heuristics (section xxx) to be applied.

Brainstorming section moved to end of document

4.1. What’s the big picture?

Computers are becoming thousands of times more powerful every (decade?), yet there is one important component of the computer system that hasn’t changed significantly in performance since the first computers were developed in the 1940s: the human. Our responses are typically a tenth to one second, our immediate range of movement is mainly within a metre, and the number of items that most people can deal with at a time is typically around 5 to 9. For a computer system to work really well it needs to be designed by people who understand the human part of the system well.

For example, [sample good and bad interface]

In this section we’ll look at what typically makes good and bad interfaces. The idea is to make you sensitive to the main issues so that you can critique existing interfaces, and begin to think about how you might design good interfaces.

4.1.1. Key concepts

Key concepts that are likely to be encountered are: Algorithms: Techniques: Applications: Possible activities:

4.2. Getting started

[some introductory activities/ideas to open up the topic]

4.3. Subtopic 1

[an area that is worth knowing about, including activities/exercises to explore it, and guidance for teachers (possibly to be separated) on how to help students use this topic for A/M/E

4.4. Subtopic 2

[an area that is worth knowing about, including activities/exercises to explore it, and guidance for teachers (possibly to be separated) on how to help students use this topic for A/M/E

4.5. Subtopic 3

[an area that is worth knowing about, including activities/exercises to explore it, and guidance for teachers (possibly to be separated) on how to help students use this topic for A/M/E

4.6. Subtopic n

[an area that is worth knowing about, including activities/exercises to explore it, and guidance for teachers (possibly to be separated) on how to help students use this topic for A/M/E

4.7. The whole story!

In this chapter we’ve mainly looked at how to critique interfaces, but we haven’t said much about how to design good interfaces. That’s a whole new problem, although being able to see what’s wrong with an interface is a key idea. Many commercial systems are tested using the ideas above to check that people will find them easy to use; in fact, before releasing a new application, often they are tested many times with many users. Improvements are made, and then more tests need to be run to check that the improvements didn’t make some other aspect of the interface worse! It’s no wonder that good software can be expensive - there are many people and a lot of time involved in making sure that it’s easy to use before it’s released. [explain where the material above has oversimplified things, and if there are any well-known concepts or techniques that have been deliberately left out because they are too complex for this age group. This may include things that require advanced maths, advanced programming, or things where students have seen the problem but not a thorough solution]

4.8. Further reading

How difficult an interface looks can affect how people perceive it, even if it’s easy to use: http://www.cs4fn.org/usability/importanceofsushi.php

RITE interface evaluation: http://www.cs4fn.org/usability/wixon.php