Human-Computer Interaction

1  Abstract

This article introduces the topic of human-computer interaction (HCI). It covers a range of concepts which will be revisited later in this blog, but it does attempt to introduce the whole of the topic as it is too broad. Instead a few key concepts are discussed and you will be encouraged to develop a critical attitude to interface design.

2  Introduction

This article assumes that you understand the basics of how to use your computer’s operating system. It is assumed that you have read the “Computing” article and gain a good understanding of its concepts and that you now understand computing in general.

The aim of this article is to develop your understanding of human-computer interaction. This article provides the necessary terminology for understanding applications that will be introduced in the next articles.

Human-computer interaction is concerned with how users interact with computers. Users interact with computers through some form of user interface thus HCI involves a consideration of a wide variety of issues, including the following:

• Input and output devices: for example, if users are blind, the technology must meet their particular needs.
• The cognitive characteristics of the users: how much information can they remember?
• The background and knowledge of the users: for example, are they young children or business users?
• The tasks which the users wish to carry out: for example, are they controlling a nuclear power station or writing letters?
• The types of interface available. Most modern interfaces are graphical user interfaces (GUIs). However there are alternative kinds such as command-line interfaces, menu-driven interfaces and prompted-user interfaces.

3  User-centered design

For many years, software developers produced software for specialist users who were able to spend time learning complex user interfaces. This has changed with computers being used by a wide variety of people for vast range of tasks. To enable users to access the full potential of computers, the users’ needs and characteristics must be central to the design of the user interface. There is no place for badly designed, confusing interfaces.

3.1  The importance of the user

In the early days of computing, the majority of computer users were specialists, working for the military or in the scientific laboratories of big corporations. They worked on large mainframe computers and wrote programs in languages which only they understood. Such users had input and output devices such as teletypewriters which to the present day user seem slow, noisy and inflexible.

Since the early 1980s this has all changed. The introduction of Apple Macintosh, IBM PC and other personal computers transformed the way in which non-specialists perceived the computer. For the first time it became available to ordinary people in their offices and homes. One consequence of this was that the computer user became a consumer. Thus the uninformed user wanted to be able to purchase a computer system which matched their needs with the minimum effort.

The market developed rapidly in response to this demand with different organization targeting different sectors. For example, in the UK Clive Sinclair targeted home users with the ZX81 and the Spectrum, the BBC B was aimed at the education market and the IBM PC was aimed at business users. The lack of consistency between both the hardware and the software made transferring between computer platforms difficult. There was a pressing need for standards to be established.

As the market developed during the 1980s and 1990s, the IBM PC became a widely copied standard. This resulted in rapid reduction in prices and increasing market domination. When the IBM PC was first released, it was bundled with an operating system called PC-DOS (Personal Computer Disk Operating System). On compatible personal computers, produced by other computer manufacturers, the operating system was called MS-DOS (Microsoft Disk Operating System). This was an example of command-line interface, which required the user to memorize the name of the command, the way it was used and the names of the files to be manipulated. If the command was typed with even smallest error it would not work at all and usually provided little indication of to enter it correctly. For example, in order to delete a file (named TEST.DAT) from floppy disk you would type DEL A: TEST.DAT in response to a prompt of C:\>.

In the early 1970s Alan Kay set up a research group at Xerox Palo Alto Research Centre. This group created Smalltalk. Linked in with this, they also developed many features o modern GUI interfaces. Thus Smalltalk and GUI interfaces have grown from the same root.

In the 1980s, Apple developed a range of general purpose computers. The most of these was Apple Mac. For this Apple used many of Alan Key’s ideas to create a GUI interface which is the precursor to all GUIs. This interface was much more usable than MS-DOS: users could achieve what they wanted relatively easily, without getting confused or needing to ask for help. It took some time for this approach to become recognized and accepted but, ultimately, consumer pressure forced Microsoft to develop a GUI interface. This interface was called Windows.

One of the most significant theoretical aspects of this development is that GUI interfaces can have the same functionality as command-line interfaces. In other words, you can carry out the same tasks but in a different way. For example, to delete the file TEST.DAT on a floppy using Windows 95 GUI interface, you simply drag the icon for file into the Recycle Bin. This has the same functionality as the MS-DOS command:

C:\>DEL A:TEST.DAT

We say that the domain model can be separated from the interface. The domain model can be thought of s a n underlying computer program that carries out abstract functions (such as deleting a file, and cutting and pasting objects) while the interface can be thought of as an additional layer of software that gives concrete versions (such as dragging and dropping, and highlighting) of these abstract functions. This separation allows us to consider the features of a good user interface, distinct from the application domain model.

There are a number of GUI interfaces available. There is high degree of visual and functional consistency between these interfaces. This means that moving between them is relatively straightforward – knowledge of one can help the user operate the others.

Figure 1 Mac OS, Windows 3.1, OS/2 and Motif interfaces

In the 1990s there is a home and small business market dominated by personal computers running Windows which has resulted from consumer pressure for cheap computers running usable software. This introduces a key theme in HCI: the development of all software must be user-centred. There is no point in developing software that the user is unable to operate or which does not perform the tasks the user wishes to carry out. Good interface design means the difference between software that is used effectively and software that is discarded.

3.2  Designing for users

In Computing article, we loosely defined computer systems as being the combination of hardware and software. However in most situations, tasks are carried out by computer systems operated by one or more people. Thus, we have socio-technical systems, which comprise technical and human elements. In order to maximize the effectiveness of such systems, not only do we need to understand the technology, but we also need to understand the human element and the way the two interact. In considering this task, it should be remembered that the human mind is many times more complex than the most sophisticated computer.

The behavior of users can be very varied and unexpected. For example, the Microsoft Usability Laboratory found that when the mouse was first introduced, some users ran the mouse up and down the leg of the table (presumably thinking that a real mouse would act in this way). Other users waved it in the air – why is not recorded! It is easy to laugh at such examples and ridicule those early users. However, the cause is often poorly designed interfaces which do not take into account the characteristics and background of users. These examples are trivial, but there have been numerous serious accidents and near accidents which have been blamed upon interface design. One of the better known of these is the near meltdown of the nuclear power station at Three Mile Island in 1979. Thus the study of how humans interact with computers is important enough to be considered as a distinct field in the discipline of computing.

An understanding of a variety of academic disciplines is necessary to design interfaces which do take these characteristics into account. Some are given below.

• Cognitive psychology: This provides us with theories about the way we think, the way we remember, and the way we tackle problems.
• Sociology: This provides us with an understanding of the cultural issues involved, such as the way people interpret icons or the way in which people use computers within an organizational context. User interface design is very much a cultural issue: with every new version of a popular interface the culture of its users alters ê the expectations of experienced users’ increases and the problems which new users experience alter.
• Linguistics: This provides us with an understanding of the syntax and semantics of language. This is essential not only for the correct wording of menu items, but also for any type of linguistic input or output.

In utilizing the findings of these disciplines, an understanding of a range of other disciplines, such as ergonomics, engineering, design and (of course) computer science is also needed. All that you need to know about these various disciplines will be taught within the course.

In the face of such complexity, the question arises:  How do we design good interfaces? There are two answers to this.

1. Design principles: A number of design principles and design guidelines have been developed. At a low level, these might cover such issues as font type and size. These would usually be referred to as design guidelines as they are content dependent. At a higher level, there are design principles such as visibility, affordance and feedback, which are content independent. These are described in more detail in the next section.
2. User needs analysis If you are a software developer it is important that you find out as much as possible about the people who will be using your software. Thus, you would need to consider the following questions.

1. What is the typical user like? For example, an interface which is appropriate for young children (large icons and simple language) might not be appropriate for rocket scientists. This is referred to as user characterization.
2. What does the user want to do? For example, the requirements for a cash-dispenser machine are likely to be different to those of a home banking system. This is referred to as task analysis.

• Where will the system be used? Continuing the banking example, the cash-dispenser machine needs to be easy to learn as a customer is unlikely to want to read a user manual standing outside the bank! This is referred to as situational analysis.

Each of these areas is quite involved, and we could include a lot more detail. However, at this stage it is only necessary for you to be able to reflect upon these issues.

Answering these questions will usually require the use of empirical methods such as questionnaires and interviews. The answers to these questions make up the user needs analysis.

The result of applying the appropriate design principles and the findings of the user needs analysis to the design of an interface should be a usable interface. Usability is a used widely term in HCI. The definition of the term varies, but typically it refers to the following.

• How easily and quickly users can achieve their goals.
• How quickly users can learn to use the interface.
• The attitude of the users to the interface – do they like it?

In order to assess usability, it is usually necessary to employ empirical methods.

This usually results in the interface being redesigned. Thus interface design should be seen as an iterative process.

4  Design principles

It would be very useful to have a definitive set of rules for designing usable interfaces. Some attempts have been made to achieve this, but it is very difficult for the following reasons.

• There are so many variables: ideally each interface needs to be considered as a special case.
• Combining research from different academic disciplines, each with its own methodology, is very difficult. For example, most HCI books have one or more chapters on cognitive psychology. These chapters are often intellectually separate from the rest of the book because they require a different perspective on the problem.

However, many of the standards texts include design principles. These vary in level of detail. For example:

Evenly spaced text with a ragged right margin is easier to read than right justified text with variable spacing between the words.

And

Restrict the amount of information on the screen. Only present what is necessary to the user.

The level of detail is significant. The first principle is easier to interpret and implement than the second. In the second principle we need to ask ourselves further questions such as ‘how do we know what is necessary?’. These additional questions can be difficult to answer and each person’s response will probably be different. Thus, even when using design principles there is a significant element of subjectivity and choice in the design of interfaces. The key to handling this choice is to make thoughtful, informed decisions based upon knowledge of the user and the tasks they wish to carry out.

4.1  Visibility, affordance and feedback

The cognitive psychologist, Don Norman, has researched into the problems that people experience using everyday objects, such as doors, lifts, cars and video recorders. From this he has abstracted some general design principles.

Consider an office block which contains three lifts side by side. On each floor there is a light above the door to each lift. A person wants to travel in a lift, so he presses the lift button. The light above one lift comes on and then goes off. Similarly the light above another lift comes on and then goes off. However, none of the doors open. Finally, two of the lights come on together and he suddenly realises that the lights indicate movement between floors, not the arrival of a lift.

This example demonstrates a number of principles. First, the feedback should be of an appropriate nature: movement between floors is relevant information, but it is not as useful as knowing when the lift has actually arrived. Second, the feedback should be consistent with the type of feedback that you get with other lifts – it is not.

We can develop this example: the user had to press a button. How did he know that he had to press the button? Presumably, it had the following properties:

• It was raised from the surface of the wall.
• It was a typical button shape.
• It was labeled ‘press’

Using Norman’s terminology, these properties resulted in the button affording being pressed. In other words, the properties of the button suggest to the user that it should be pressed. If the button had been flush with the surface (as quite a lot of buttons now are), or had been a different shape (a star?) or had been unlabelled, the user might have been less sure about what to do.

Another issue: how did the user know the effect of pressing the button? The positioning of the button by the lift suggests that the button has something to do with the lift, but unless it is labelled there is still some uncertainty – it could be an emergency stop button. This phenomenon is called visibility. In other words, it is necessary for the relationship between the action and its effects to be self- apparent.

This example may seem remote from the design of computer interfaces, but the principles of good feedback, affordance and visibility still apply. To demonstrate this, look at the window illustrated in Figure 2.

• The horizontal bar at the bottom of the window is called a slider bar. It is operated by dragging the block in the middle to the left and right using the mouse (or by clicking on the arrows). This action is suggested to the user by the arrows, by the raised appearance of the block (the dark lines around the block suggesting a shadow) and by the parallel lines which indicate that it should be moved between them. Thus the slider bar affords being used in the correct manner.
• It may initially be less obvious when it would be appropriate to move the block. This is because the effect of moving the block is not self-apparent.

However, the proximity of the slider bar to the window should suggest that the movement afforded by the slider bar will have a direct influence upon the window. Proximity is an important variable in interface design. Thus the visibility is not particularly good.

• The feedback takes the form of a different set of icons in the window and the block in a different place.

Figure 2 An example window

This window satisfies these principles reasonably well. However, there is still room for confusion. For example, the concept of dragging using the mouse may be unfamiliar or users may think that the contents of the window are fixed. In this latter situation they would have difficulty guessing what the slider bar was for. If these eventualities seem unlikely, just ask a complete computer novice to explain to you what Figure 2 means and you might be surprised by what is said. The exciting and frustrating part of working in HCI is the infinite variety which users present.

GUI interfaces represent the dominant interaction style for a turn of the century computer. Before this time, command-line interfaces were the usual method for controlling computers. Operating systems such as MS-DOS and UNIX both use this style. In such systems the user has to type in commands which the computer carries out. The permitted commands make up the command language. Figure 3 illustrates the start up sequence for MS-DOS.

Figure 3 The start up sequence for MS-DOS

The C:\> is called the prompt and it indicates that the user is expected to enter a command. For example the user could enter:

CD DOS

This command means ‘change default directory to DOS’. You may well not understand this. If you do not, it is hardly surprising as it is uses a lot of computing jargon and can appear impenetrable to the novice computer user. As well as using arcane terminology, it requires the user to remember both cd and dos. Also the syntax must be correct: if the space between cd and dos is omitted, the system will come back with an unhelpful error message Bad command or file name. This is unhelpful because it indicates that the error must either be in ‘cd’ or in ‘dos’ – it is in neither. Also it does not make any suggestions to help remedy the situation. Thus, the feedback is poor and it would be difficult to improve it significantly.

As the commands need to be remembered and knowledge of their effects depends upon an understanding of arcane terminology, the visibility of the interface is very poor. It would be very difficult either to guess the commands or to know when to use them. It is difficult to know how to interpret affordance in this context. It could be argued that the C:\> prompt affords being written after. To some extent this is true because a flashing cursor normally appears where the text should be entered. However, this is very limited when compared with the affordance of a slider bar.

Thus MS-DOS does not satisfy the good feedback, affordance and visibility design criteria at all well. However, it should be noted that both MS-DOS and UNIX have their enthusiasts. Expert users can use these interfaces very quickly and accurately to achieve what they want. They can also be used for creating batch files and writing particular types of software. Thus they are appropriate for experienced users with a good understanding of the computer and how it operates. Also, users may well stay with a sub-optimal interface with which they are familiar rather than incur the intellectual cost and loss of time which learning a new interface would involve.

Command-line interfaces represent an extreme contrast to GUI interfaces.

First article of this blog describes menu-driven user interfaces and prompted user interfaces. These categories of user interfaces have different characteristics to both command-line interfaces and GUIs, but they can also be critiqued against the principles of visibility, affordance and good feedback.

4.2  Interface metaphors

The advent of GUI interfaces has allowed the concept of metaphors to be explored in HCI. Metaphors have traditionally been linguistic devices. Thus, someone may refer to a glaring error, food for thought or the evening of one life. None of these examples can be interpreted literally: errors don t shine in a dazzling way, thinking does not involve eating and life does not have an evening. However the us e of the metaphor adds expressiveness and draws in knowledge of other comparable situations with which the speaker and listener are familiar.

Interface metaphors work in a similar way. For example, Figure 4 represents the calculator program, packed with Windows.

Figure 4 A calculator metaphor

This interface metaphor assumes that the user is able to recognise and use a simple hand-held calculator. In a well-thought-out metaphor (which this is), this knowledge results in the user being able to infer how to operate the calculator program. Thus the user should be able to work out that clicking on the buttons is equivalent to pressing the buttons on the hand-held calculator and also realise that the * sign stands for multiplication and SQRT is an abbreviation for square root . Thus we have a program which most users will be able to use without any training.

The choice of metaphor is extremely important. For example, a complex scientific or graphical calculator could have been chosen. This would be functionally more powerful, but it might confuse users unfamiliar with the hand-held version. Thus we return again to the central importance of the users for whom the interface is being developed.

A common fault with screen metaphors is that they are inconsistent with the real world analogue. The calculator metaphor is quite good, but you do not find calculators with menu bars at the top. Even less do you find calculators with a button in the top right-hand corner which will make them disappear! However, such inconsistencies can add value to the interface object, but they must be used with care.

4.3  Direct manipulation

The user interfaces that you have been using so far on the course all share an important characteristic: when you have used a command you have applied it ‘directly’ to representations of objects that the command has to change or use.

For example, you have clicked on icons in order to run programs and you may well have dragged icons between windows in order to copy files. This style of interaction is widely used by GUI interfaces and is referred to as direct manipulation. The representations may take a number of forms, such as illustrations, text or windows.

In the previous paragraph we were careful to use the term representation. In

Section 4.1 we made the distinction between the domain model and the user interface. In direct manipulation the user interface is made up of visual representations of some of the objects which make up the domain model. Similarly, while you may appear to drag one of these representations, in reality underlying software is causing the necessary changes to be made to the domain model. This will typically involve objects sending messages to each other in order to achieve the desired effect. Thus objects can never be seen, only representations of objects.

5  Summery

In this article we talked about the usability of an interface is defined by the ease with which users can achieve their goals, the ease with which the interface can be learnt and the attitude of users to the interface. Understanding the characteristics of users, the tasks which they wish to complete and the environment in which the system is being used are all central to good interface design. Affordance, visibility and good feedback are key design principles. Interface metaphors and direct manipulation can make an interface easier to learn because they are more intuitive. GUI widgets should be combined to create an attractive and usable interface. Interface design is a subjective process and the only real test of the usability of an interface is some type of formal evaluation. GUI widgets can be viewed as objects to which messages are sent by the user.