Introduction and Motivation

Why bother?
This chapter presents some of the motivation for and background to Human Computer interaction (HCI) and Interactive Systems Design, in particular. We will discuss broad trends in the development of computer applications. These developments have created the comparatively recent problems associated with mass-market systems. They have also created many niche markets where the users are specialists in their particular field but have little or no interest in information technology.

Here are a few reasons why we should `bother' about HCI:

• Too often HCI is considered as an afterthought on the development process. As with most things in large projects, the later you leave it the worse it gets.
• If the interface is wrong then users suffer from high fatigue, stress, irritation, medical problems (backs, wrists, eyes). Clients suffer from high training costs, fast staff turnover, long learning periods and extented training. Developers suffer from poor customer reaction, high maintenance costs, penalty clauses and increased development costs.

Glossary
Textbooks on human computer interaction are full of jargon. Here are a few of the more general terms that you might come across in the rest of this course.

HCI - Human Computer Interaction is concerned with studying and improving the many factors that influence the effectiveness and efficiency of computer use. It combines techniques from psychology, sociology, physiology, engineering, computer science, linguistics...

Ergonomics is the study of work. The term is most widely used in the United Kingdom and Europe, in contrast to the United States and the Pacific basin where the term `Human Factors' is more popular (see below). Ergonomics has traditionally involved the design of the `total working environment'; this includes the height of the chair, table etc. Health and safety legislation, such as the UK Display Screen Equipment Regulations (1992), is increasingly blurring the distinction between HCI and ergonomics. In order to design effective user interfaces, we must consider wider working practices. For instance, the design of a tele-sales system must consider the interaction between the computer application, the telephone equipment and any additional paper documentation.

Human Factors is used to describe the study of user interfaces in their working context. It addresses the `entire person' and includes:

• physiology, our physical characteristics such as height and reach.
• perception, our ability to sense information, such as hearing loss and visual impairment.
• cognition, the way we process data, such as the information we extract from a display.

`Usability' and `ease of use' are often put in quotation marks. They are too vague to be meaningful. Do we mean that a system is easy to use for novices or experts? Do we mean that they have low learning times or lead to few errors? As a rule of thumb, if you claim a system is easy to use there will always be at least one client or user who will contradict you. To avoid this, it is useful to back claims with more specific evidence. This may be increasingly important as the market becomes increasingly discriminating.

Historical Context

The Middle Ages

The Persian astrologer, Al-Kashi (1393-1449) built a device to calculate the conjunction of the planets. Records of this work survived and were transported to Europe, although the device itself was lost. The German mathematician, Wilhelm Schickard (1592-1635) developed a much less sophisticated tool to perform simple addition and subtraction. The Schickard machine was destroyed during the 30 Years War. Blaise Pascal (1612-1662) was forced to replicate much of Schickard's work but only succeeded in building an even more simplified version of his machine.

There was no gradual improvement in our knowledge over time. War, famine, plague interrupted the development of mechanical computing devices. This, combined with the primitive nature of the hardware, meant that user interfaces were almost non-existent. The systems were used by the people who built them. There was little of no incentive to improve HCI.

The Eighteenth And Nineteenth Century.

The demand for navigational aids fuelled the development of computing devices. Babbage's (1791-1871) early attempts were funded by the Navy Board. As in previous centuries, the difference engine was designed to calculate a specific function (6th degree polynomials):

a + bN + cN^{2} + dN^{3} + eN^{4} + fN^{5} + gN^{6}

The Early Twentieth Century.

Never Trust Designers' Intuition...

This section isn't intended as an attack on commercial software designers. Instead, it argues that you should always question designers' intuition about the usability of interactive systems. There are very few systems whose designers are typical of the user population. One of the reasons for this is the sheer diversity of many user populations:

• expertise. The way in which a system is designed, built and sold differs if the intended users are to be `experts' or `novices'. In the former case, designers must build upon existing skills. Issues such as consistency with previous interfaces are absolutely critical. In the latter case, designers must provide a higher level of support. They must also anticipate some of the learning errors that can arise during interaction. It is difficult to begin the development process if designers are unaware about such general characteristics of their user population.
• age. The average age of the user population affects interface design. Age can affect the amount of expertise that may be assumed. In many instances, it affects the flexibility and tolerance of the user group. This does not always mean that younger users will be more flexible. They are likely to have used a wider range of systems and may have higher expectations. Age also determines the level of perceptual and cognitive resources that are to be expected from potential users. By this we mean that our ability to sense (perception) and process (cognition) information declines over time. Many user interfaces fail to take these factors into account. This can create particular problems in safety-critical systems where user interface design may be assessed by the Health and Safety Executive.
• disability. In many European nations, including Sweden and Norway, there is a statutory obligation to provide access for blind users when designing computer systems. This user population must also be considered when supplying products to the U.S. government. Section 508 of the US Rehabilitation Amendments Act (1986) applies to all products in government offices, bought or rented. Such considerations will have a profound impact upon the development of your user interface if these groups are within your target market.
• nationality. Interface development and documentation are affected by the particular characteristics of their eventual market. It is important to allow for help facilities in several different languages. Command languages may have to be changed. For example, `hit e to exit' may not translate into the target language (`taper s pour sortir'?).

Designing For Novices?

So far, so good. An inevitable consequence of having a large novice population is, however, that some of them will carry on to become expert users. This creates problems because WIMPs can be frustrating during frequent use. The user has to move their hand away from the keyboard. They have to find the mouse, typically hidden under 20 or 30 paper documents, and pull it over to the appropriate menu etc etc. In the Macintosh this has led to the use of keyboard accelerators. By hitting chords (this involves pressing several keys at the same time), users can by-pass the menu structure and directly issue commands from the keyboard. This saves a lot of time but some of the chords are far more obscure than in DOS, (shift, command, 3, to print the image of my desktop!). The success of the Macintosh can partly be explained by the support it provides at both ends of the expertise spectrum.

Novices quickly turn into experts if your interface is well-designed.

Designing For Experts?

In the opposite manner to the Apple Macintosh, the success of UNIX as a platform for expert users meant that increasing numbers of people were being expected to learn the system. Some of these were `novices' in the classic sense. They were intermittent users who only wanted to exploit programs or results that were generated on UNIX machines. At the same time, expert users became familiar with some of the advantages that WIMP interfaces provide for particular tasks, such as reading news or composing letters. In consequence, window managers were developed to provide the graphical environment of the Macintosh and Windows together with the flexibility of the UNIX command language.

The moral of UNIX and the Macintosh is that if your system is successful you will need to support both novices and experts. When first designing your system, however, you must be aware of the existing level of computer literacy in the target population. UNIX would not have been appropriate for many of the users who were first introduced to the Macintosh. Conversely, a WIMP style of interaction would not have been appropriate for the scientific and high-volume data entry tasks that were first supported by UNIX.

Nobody becomes an expert if your interface is poorly designed, they just stop using it.

A Model Of Interaction
Donald Norman is Emeritus Professor at Apple's research laboratories. One of his most important ideas is that human-computer interaction is based around two gulfs that separate the user from their system.

The Gulf Of Execution

The model would be of little benefit if it didn't provide designers with a framework for understanding why things occasionally `go wrong' in user interfaces. For example, problems might arise if users have inappropriate goals and intentions: `I'll print out an executable file' or `I'll remove my operating system'. Other problems can arise through inappropriate action specifications: `First, I'll delete this old file, then I'll see if I can find my really important collection of e-mail addresses'. Finally, there may be problems with the interface mechanisms themselves. The bottom line from this analysis is that in order to understand good and effective interface design we must also understand the goals and intentions of our users. Mistakes, errors and frustration can occur even if we have high-quality interaction mechanisms.

The Gulf Of Evaluation

As with the gulf of execution, the gulf of evaluation illustrates the point that usability problems can occur even in systems with well designed displays. If users cannot interpret and evaluate the information on their screen then issues of presentation and layout are irrelevant.

Different Models
One of the biggest dangers when designing a user interface is to lapse into `introspection'. Users' tasks are, typically, very different from those anticipated by most designers. For example, I frequently use the picture drawing tool in my word processing package to produce graphs and tables. The designer of this system probably never anticipated that someone would use their tool for this purpose. These different patterns of usage lead to different goals and intentions. I want to be able to measure angles in my drawing tool so that I can integrate complex graphics in my pie charts.

Why do such irritations occur? The package includes both a spreadsheet and a graphics application. I want to be able to use the drawing tools with the graphs from the spreadsheet and vice versa. My model or idea of the system is as a tool that will help me to complete my task: I want to combine graphs and pictures. The designers' model of the system was different. Their view was one in which a distinction existed between drawing a picture in the graphics tool and drawing a chart in the spreadsheet. It might have been possible to avoid this problem if they had been more aware of my model for an ideal system.

The Designer's System Model

The User's Mental Model

The biggest danger in user interface design is to pretend that you are a `typical' user.

Tasks.

A task is a high-level activity that motivates the user to operate their computer system in the first place. Identifying these tasks is a critical design activity. Traditionally, research in HCI has been heavily dominated by techniques for task analysis. Most of these approaches exploit some form of hierarchical structuring:

1. Arrange a meeting:
	1.1. Suggest a date:
	1.2. Book participants:
		1.2.1 Check participants free:
			1.2.1.1 if yes then to 1.3
			1.2.1.2 if no then to 1.1
	1.3 Book room:
		1.3.1 Check room free:
			1.3.1.1 if yes then exit
			1.3.1.2 if no then to 1.1

It is important to note that task analysis is like many other design activities. It is essentially a cyclic process. The introduction of a computer system will often change the nature of a users' task completely. At its best, information technology re-distributes tasks between the system and the user. Therefore, do not rely upon previous questionnaires etc to provide evidence about operator tasks for subsequent generations of user interfaces.

The Marketing Department's Model

Having said all that, the second principle of human-computer interaction is know your marketing department. It takes time to understand your users. If the marketing department impose tight deadlines then this may be impossible. The best that you can do is exploit some basic guidelines (we'll discuss these in later sections). These are rules of thumb or heuristics that have guided the development of successful interfaces in previous systems. The worst thing that you can do is design the interface as if you were the intended user. Get other people to try your system as you develop it from initial design to final implementation.

A second reason for communicating with the marketing department is that a successful user interface can drive the commercial exploitation of your products. The recommendations of a satisfied user population provide important propaganda for continued investment in HCI. This implies that designers must maintain some contact with their users after software has been delivered. If these links are not maintained then companies sacrifice valuable opportunities for gathering evidence about future interfaces. An additional benefit of such after-delivery contacts is that they increase participation in systems development. Even horrendous displays can be well received providing the operators' feel as though they have a `stake' in the system.

User Centred Design
In the previous talks we identified some important differences between designers and users. It was argued that the designer's model of an interface may be very different from that of their users. Engineering concepts, such as bytes or records, must be mapped into user abstractions, files and folders. It was also argued that designers must appreciate the differences between different groups of users. In particular, the way in which we design a user interface can be profoundly affected by the distinctions between novices and experts.

In this section we will explain why differences exist between novices and experts. We will also explore some of the other differences in a user population that must be considered when developing and installing computer systems. In particular, we will identify the effects that perception, cognition and physiology can have upon human performance. The discussion will be pitched at a general level to provide a complete overview of the main problems that these differences can cause. It is important to emphasise that not al of this information will be relevant to all commercial problems. For instance, the developers of a mass market database system may have little or no control over the workstation layout of their users. In other contexts, particularly if you are asked to install equipment within your own organisation, these factors are under your personal control.

Once we have identified the key characteristics that distinguish different users we will be well prepared to discuss some of the more concrete ways in which they can be recruited to support the development lifecycle. The next section will present practical techniques for eliciting the perceptual, cognitive and physiological requirements that constrain many user interfaces.

Perception, Cognition And Physiology
We can characterise user resources into three categories. Perception: the way that they detect information in their environment. Cognition: the way that they process that information. Physiology: the way in which they move and interact with physical objects in their environment.

Perception

It's no use displaying it if people can't see it or hear it in their normal working environment.

Cognition

Short term memory has a relatively low capacity. We'll find out exactly how much in a moment. It is fast, if we have something on our mind then we can talk about it almost instantly: what do the letter HCI stand for? If we have to trawl it up from our long term memory it may involve several moments thought: name the seven dwarfs? Short term memory also has a relatively short retention period. This is because we actually have to work to keep items in it.

Long term memory, in contrast, has a relatively high capacity. As its name suggests it can store information over a much longer period of time. Access is much slower.

Clearly from the previous observations, we should like to design interfaces that make efficient use of short term memory. Users should only be required to remember a few items of information and they should not be forced to trawl back through dim and distant memories of traing programs in order to operate the system. An increasingly common trick in user interface design is to support short term memory by representing additional information on the display or on index cards. This is effectively what a menu does: it provides fast access to a list of commands that do not have to be memories. In contrast, help facilities are more like long term memory. We have to load them and trawl through them to find the information that we need.

Do not rely on help facilities to substitute for poor interface design. They can be very irritating, slow to access and rely upon good indexing.

Seven is often regarded as the `magic number' in HCI. We can see this all around us. Important information is kept within the seven item boundary. For instance, postcodes have up to seven components G12 8QT etc. In some cases, it is necessary to break this rule. In these circumstances, the information is broken up into components with less than seven items. In the United Kingdom, phone number are usually divided in this way, (0141) 339 8855. As a rule of thumb or guideline, never expect the user to hold more than seven items of information at any one time. It follows that users will have difficulty in remembering the contents of menus with over ten items. Command languages with many different options will need additional visual cues if operators are to learn them.

Why is is seven the magic number? It is as easy for users to hold seven words in short term memory as it is for them to hold seven unrelated items. Additional information can be held but only if users employ techniques such as chunking. This involves the grouping of information into meaningful sections. It can also involve the use of mnemonics and acronyms to prompt the user to recall additional detail. All of this involves work on the user's part. This can jeopardise the success of a user interface.

As mentioned, it takes effort to hold things in short term memory. We all experience a sense of relief when it is freed up. For example, you may have felt this when you finished reciting the remembered items in the previous exercise. As a result of the strain of maintaining short term memory, users often hurry to finish some tasks. They want to experience the sense of when they achieve their objective, this is called closure: This haste can lead to error. The early cash dispensers suffered from this problem. Users experienced a sense of closure when they satisfied their objective of withdrawing money. They then walked away and left their cards in the machine. As a result cash will now not be dispensed until you take your card.

An important aim for user interface design is to reduce the load on short term memory. We can do this by recording information `in world' not `in the head'. This involves the use of prompts on the display and the provision of paper documentation. Beware, however, it is very easy for users to lose these vital pieces of paper...

People make mistakes if they can't wait to finish using your system.

Knowledge, Rules and Skills

Up to this point we have been rather vague about the differences that exist between different elements in a user population. A number of models, such as the one shown opposite, have been developed to provide a more precise explanation. It shows the differences between the different degrees of information that people might have about an interactive system. In the worst case, they may only be able to use general knowledge to help them understand the system. Designers can exploit this to support novice users. For example, in the Apple desktop inexperienced users can apply their general knowledge in several ways ; `To undelete a file I'll empty the wastebin...'. This is a dangerous approach, however, if this knowledge fails then users are reduced to making guesses.

The second level of interaction introduces the idea that users exploit rules to guide their use of a system. This approach is slightly more informed than the use of general knowledge. For example, users will make inferences based on previous experience. This implies that, whenever possible, designers should develop systems that are consistent. Similar operations should be performed in a similar manner. If this approach is adopted then users can apply the rules learned with one system to help them operate another. 'To print this page, I go to through file menu and select the option labelled Print one' There are two forms of consistency:

• internal consistency refers to similar operations being performed in a similar manner within an application. This is easy to achieve if designers have control over the finished product.
• external consistency refers to similar operations being performed in a similar manner between several applications. This is hard to achieve as it involves the design of systems that the designer may not have an involvement in. This is the reason why companies such as Apple and IBM publish user interface guidelines.

Errors

The more we have to think about using the interface the less cognitive and perceptual resources we will have available for our main task.

Physiology

As a minimum requirement users must be able to view the display, reach the input devices etc. A number of factors may intervene to restrict prevent operators from achieving this:

• paper documentation. If your manuals are badly designed and produced then users can become extremely irritated within a few seconds of starting with the system. I know of at least two systems ran into problems with this. Documentation must not be so bulky that it dominates the users working environment. It must lie open without breaking the spine.
• other users, cups of coffee etc. You cannot rely upon system operators to prevent bad things from happening. Unexpected events in the environment can create the potential for disaster. There was a US patient monitoring system that relied upon a touch screen until a consultant brushed against it...

Don't make interface objects so small that they cannot be selected by a user in a hurry, carrying a stack of books. Don't make disastrous options so easy to select that they can be started by accident

Designers often have relatively little influence on the working environments of their users. If you are lucky enough to have some power, here are a few guidelines:

• Visual display units. They should always be within the visual angle of the user. In other words, even relatively short periods of rotation on the neck can lea to long periods of pain in the shoulders and lower back.
• Keyboards Prolonged periods of data entry place heavy stress upon the wrist and upper arm. A large range of low-cost wrist supports are now available. They are a lot cheaper than the expense of employing and re-training new members of staff. Current attention focuses upon the problems of RSI - repetitive strain injury and carpal tunnel syndrome. Frequent breaks can help to reduce the likelihood of these conditions.
• Chairs and office furniture: It's no good providing a really good user interface if your employees spend most of their time with a chiropractor. It really is worth investing in well designed chairs. Lower back support is particularly important. The Health and Safety Executive produce a number of posters and leaflets on good posture for computer operation. If you are unconvinced about the importance of this issue ask how many of your staff have suffered or do suffer from back pain.
• Placement of work materials. Finally, it is important that users are able to operate their system in conjunction with other sources of information and documentation. Repeated gaze transfers lead to neck and back problems. Paper and book stands can reduce this.

• Noise. Distraction can be caused by the sounds of other workers (phone calls, beeps); pieces of equipment (fans, printers) etc. There are a number of low cost solutions, for example you may introduce screens around desks or cover devices such as printers. Higher cost solutions involve the use of white noise to mask intermittent beeps. Another technique that is widely employed involves voice mail and help-desk support to reduce telephone noise.
• Light. There is a difficult problem cause by light distraction. Its impact can be reduced by blinds and artificial lighting. This cuts down the level of light in the room. A side-effect of this is that over-time there may be increased problems of fatigue and drowsiness amongst users. Many Japanese firms have invested in high-intensity lighting systems to avoid this problem. Lower cost solutions involve moving furniture or using polarising filters.

A number of regulatory initiatives are affecting the way in which large firms organise the use of computer equipment:

• British Standard 7179 part 4: On Legibility And Design Of Keyboards.
• European Directive: Work With Display Screen Equipment.
• Health And Safety (Display Screen Equipment) Regulations 1992.

• Eyesight. Computer use does not damage your eyes or eyesight. It may, however, make you aware of existing defects.
• Epilepsy. Computer use does not appear to induce epileptic attacks. Television can trigger some photosensitive epilepsy but VDUs do not seem to have the same effect. I do not know what the effect of multimedia video systems will be upon this illness.
• Radiation. The National Radiological Protection Board advises that VDU's do not `significantly' increase the risk of radiation related illnesses.

HCI and Software Development
The previous sections have introduced the differences between designers and users. They have also identified the cognitive, perceptual and physiological limitations that affect interaction with complex systems. In this talk we will discuss the role of HCI within the software engineering lifecycle. We will introduce a model of interface development and we will link that to the `classic' stages in project management.

We will then go on to discuss the difference between guidelines and principles. Finally, we will look at more process based models of HCI design. In other words, rather than forcing designers to look at a series of rules when designing an interface, as in the guideline approach, you get them to go through a series of activities or processes.

The Software Engineering Life Cycle

• Requirements elicitation. This involves the identification of the various priorities that different parties will have for new pieces of software. Engineers must also identify the wider constraints that affect the system. The first half of this talk will cover the key techniques of interviewing and questionnaires.
• Specification. This involves the high level representation of a design. Key techniques include systems analysis and design methodologies as well as formal methods. The second half of this talk will explore the semi-formal QOC notation.
• Design. This involves the more detailed selection of particular options from amongst a range of alternative techniques. The next set of talks will discuss a wide range of dialogue styles that might be used during interface design.
• Implementation. Building the system to the required standard.
• Testing. This centres upon the evaluation of a system. The course will end with practical exercises in evaluation techniques.
• Maintenance. It is, typically, not enough to deliver a system. The results of testing may force modifications to an initial system. This also will be covered in the final stages of the course.

It is critically important to decide where `HCI' activities lie in the project structure. If they are relegated to the end of the development process then they are first in the firing line when budgets are cut and deadlines shortened.

The HCI Lifecycle.

Williges and Williges have produced an alternative model of development to rectify the problems in the `classic' model of software engineering. Here, interface design drives the whole process. This is the current model being adopted by Apple. Software engineers are being laid off in favour of more interface consultants.

The argument is that by spotting user requirements early in the development cycle there will be less of a demand for code generation and modification. Only time will tell if this is a cost-effective strategy. In the meantime, it is important to understand the various techniques that can be used to support interface development early in the lifecycle of a project. The following pages describe techniques that can be used to gain requirements for an interactive system `straight from the horses mouth'.

The development of good user interface designs may boil down to an unattractive choice between sacking programmers to hire HCI specialists or investing in existing personnel to train them in interface design techniques.

Mechanisms for HCI in Software Development
It is important to identify the mechanisms or techniques that can be used to introduce HCI into the software development lifecycle. Since the early 1980's, most commercial organisations have introduced HCI through the use of guidelines. These are lists of rules about when and where to do things, or not to do things, in an interface. For instance, a guideline might be not to have more than ten items in a menu. Another guideline might be to avoid clutter on a graphical user interface.

The problem with guideline is that you need a large number of rules in order to cover all of the possible interface problems that might crop up. Also, it's difficult to know what to do when you have to break a guideline. For instance, what do you do if you have a menu of eleven items? An alternative approach is to develop generic principles. These provide a more abstract approach than guidelines. For example, the principle of predictability states that the user should always be able to work out the probable effects of their commands from the information on the screen. This is more abstract because it doesn't explicitly mention what the system is or what the screen looks like.

The problem with principles is that people often find them difficult to apply. How do I help the user to predict the effects of their commands? More recently, companies have been looking at the process of introducing HCI into software development. In particular, they are concerned to document the steps that they take to elicit the users requirements and to test the system. This has been largely brought about by the movement to conform with the International Standards Organisations ISO9000 standard. This sets out approved procedures for software development. Many software ourchasers now expect their suppliers to be 'ISO9000 conformant'.

Guidelines.

1.6.2 DATA ENTRY: Graphics - Drawing
When users must create symmetric graphic elements, provide a means for specifying a reflection (mirror image) of existing elements.

Guidelines and style guides help you to identify good and bad options for your interface. They also restrict the range of techniqus that you can use and still 'conform' to a particular style.

The Limitations of Guidelines.

``People rely on the standard Macintosh user interface for consistency.   
Don't copy other platforms' user interface elements or behaviours in the Macintosh because they may confuce users who aren't familliar with them.''

Apple recognise some of the problems in using guidelines whent they state that:

``There are times when the standard user interface doesn't cover the needs of your application.   
This is true in the following situations:
you are creating a new feature for which no element or behaviour exists.   In this case you can extend the Macintosh user interface in a prescribed way;
An existing element does almost everything you need it to, but a little modification that improves its function makes the difference to your application...''

Principles.

Principles can help to design many different interfaces. They establish goals for the development team. In other words, companies can specify that designers should implement predictable and observable systems without specifying the exact means of achieving these objectives. Principles, therefore, impose less constraints than guidelines.

The problem is that, although principles provide design objectives, they don't help with the details of interface development. Also, how can one test whether or not an interface is predictable and observable?

Standards.

BS EN 29241-1:1993 (ISO 9241) Part 1 General Introduction
The purpose of this standard is to introduce the multi-part standard for the ergonomic
requirements for the use of visual display terminals for office tasks and explain some of the basic
underlying principles. It describes the basis of the user performance approach and gives an
overview of all parts currently published and of the anticipated content of those in preparation. It
then provides some guidance on how to use the standard and describes how conformance to parts
of BS EN 29241 should be reported. 

As a result of this, a new set of standards are being produced by the International Standrads Organisation. The main thrust of this work is that companies must follow a set of procedures in order to be acredited. Requirements elicitation, which we will cover in the next session, is a necessary part of any interface development. So also is user testing, to be covered at the end of the course.

HCI and Requirements Elicitation

Gathering Information

Above all, it is important not to lose the support of your users during the early stages of interface development. For example, if you start off by asking questions that are simplistic or ill-informed then users may become antagonistic or irritated by someone from outside the organisation, with little knowledge of their tasks, being asked to design a system for them.

Many requirements elicitation techniques are, therefore, intended to gain maximum information about the context of the system without forcing the designer to ask stupid questions. For example, focus groups and questionnaires can be used to gather initial evidence. Once the designers has become more famillair with the general application domain, they may then use interviews and more direct techniques to gather detailed requirements.

Text Based Interfaces

Dialogues Styles.
The term `dialogue style' refers to the way in which users provide input and systems present output over time. Any particular interface is liable to exploit a number of dialogue styles. For example, menu-based interfaces use textual interaction to supply filename or device options. Conversely, many textual interfaces exploit graphical interaction techniques in order to support multi-tasking in different windows. Designers must determine which interaction style is most appropriate in any particular context. In order to do this, they must assess the users' task requirements (introduced in the second and third talks) using elicitation techniques (described in the fourth talk).

In many cases, designers are constrained in their choice of dialogue style. You may be specifically commissioned to implement a graphical user interface. Alternatively, the hardware and presentation facilities provided by a customer may only be capable of supporting text-based interaction. Within such constraints, however, there is still considerable scope for the use of different interaction techniques. For example, the predominantly graphical interaction style provided by the Windows program manager still supports command language short-cuts, similar to the Macintosh accelerators mentioned earlier. Given limited resources, it is important to target such additional support to the most `critical' areas within the interface. Otherwise, we might end up implementing both textual and graphical styles of interaction for each interfaces.

How To Select A Dialogue Style.

• the users' tasks. In the mid to late eighties there was a rush to develop graphical user interfaces to many different applications. This trend followed on the success of the Windows and Macintosh expansion. Unfortunately, many of these systems ignored the users' tasks and ended up gathering dust. There are many situations in which text-based interfaces are more appropriate than graphical or menu-based approaches. For instance, high-volume data-entry tasks can be especially frustrating if the operators hands have to leave the `home area' of their keyboard to retrieve the mouse. Conversely, complex data analysis can be extremely difficult without the graphical presentation facilities provided by spreadsheets etc. Stage 1 in deciding upon a dialogue style is, therefore, to identify the critical tasks that are to be supported.
• the users' characteristics. The second factor that must influence the choice of dialogue style is the users' level of expertise. It takes time to learn textual command languages. As we have seen, menu and graphical based user interfaces provide additional support to short and long term memory and so may be better suited to novice users. If you can build upon existing skills, principally by making your commands consistent with other applications then textual interfaces are better suited to experts. Remember, however, that novice become experts as general knowledge and rules become encoded as skills. Even if you pitch your user interface at a novice's `level' then be prepared for the growth of an expert population. However, be aware of issues such as staff turnover. If the flow of people through an office is high then you may still have to support a significant novice population.
• the systems' characteristics. Design is full of compromises. I was involved in a theatre booking system that illustrates this. The intention was to provide travel agents with direct booking facilities using graphical interaction techniques. They could book by clicking on menus and selecting rows of seats. The users' loved it until we moved it from our office into their sites. The slow communications band-width over telephone lines reduced the speed to an unacceptable level at peak times. They ended up using a text-based command language.
• the available input and output devices. It is difficult to support audio interaction without speaker and a microphone. It is often pointless using graphical interaction techniques without a high resolution display.

Textual Input?
In spite of the advancing application of menus and icons, text-based dialogues continue to be the main way in which people interact with computer systems. Typing speeds are on average must faster than the times that can be achieved for similar operations using click \& point operations. Direct comparisons are difficult to make. The main differences in time do not seem simply to arise from the different physiological demands. Proficient typists on QWERTY keyboards can manage approximately eighty to one hundred words per minute. The time to pick up a mouse and move it to a specific location depend upon the position of the cursor and the size of the target object. Instead, they stem from the different ways in which users remember textual command languages and menu based interfaces. Expert users of graphical systems rely upon the prompts provided by the system, expert command language users will have more of this information available in long term memory. This enables them to use techniques such as `typeahead', i.e., not waiting for the prompt before issuing additional commands.

Design Aims For Command Languages

• consistency - command languages should not be ambiguous. The meaning of CTRL-U should be the same in each context.
• compactness - the set of different symbols should be as small as possible.
• ease of reading and writing - although names should be meaningful they should not take forever to read and write, for instance copythefirstfileontothesecond.
• speed in learning - the shorter the command the more likely it is to be ambiguous and the longer it will take to learn. For example, d to delete a word or to move down a line?
• low error frequencies - if users experience high error rates when using the language then you may lose any speed improvements. The final section will talk about evaluation techniques that can be used to detect this problem.

Programming Textual Interfaces

If you get involved in the development of such applications it is worth while supporting scripting facilities whenever possible. These techniques provide a flexible way for users to progress from novice to expert levels of skill. This transition will only take place, however, if the individual components of your language are easily understood. For example, the following command at one installation was intended to get a printout on unlined paper from an IBM 3800 laser printer: CP TAG DEV E VTSO.LOCAL 2 OPTCD=J F=3871 X=CG12

Forming Command Languages

• simple commands In simple systems it is possible to associate a unique name with each action in the interface. For instance, displaying and printing a set of statistics on network loading. In more complex systems this leads to problems as the number of distinct commands may be very large. The UNIX vi editor is an example of this. To keep the number of keystrokes low, each command is associated with a single letter. In consequence, expert users are required to remember large numbers of letter to command mappings.
• simple command plus object. A command line consists of an operation followed by one or more objects that are affected by that operation: COPY FILE1 FILE2; PRINT FILE3. In some circumstances, it may be useful to allow tagged entries. Novices may find the following useful COPY FROM=FILE1 TO=FILE2. This cuts down the problems that can arise with order dependence in such commands.
• command plus option and object In this approach the number of distinct command names may be reduced by using special options to indicate subtle changes in the meaning of the operation. For instance, PRINT -C3 FILE1 could produce three copies of a file. This approach is useful because novices may only want the simple commands whilst experts can learn the more `advanced' options. A danger with this approach is the high number of errors that may occur for infrequently used options.
• hierarchical commands In this approach, users may type a command and then be presented with a list of further options. Microsoft`s MS-DOS 5.0 exploited this approach, CREATE would leas you to be prompted for the filename etc. The problem with this approach is that there are time overheads associated with traversing the hierarchy structure.

Consistency

Naming Rules

• fixed truncation shortens to a fixed number of letters DEL, INS, COP, MOV.
• minimum truncation shortens commands to a variable number of letters: DEL, INS, COPY, MOVE.
• vowel drop removes all vowels except leading letters DLT, INSRT, CPY, MV.
• phonetics makes abbreviations sound like the command: X to EXIT, DLT, IN, COP.
• user aliasing allows users to associate their own names with commands: lc is ls -Laf.

Textual Output?
All interface designers must be aware of how to develop textual interfaces. Even if they are primarily involved in the development of graphical systems, they will still have to present some textual information. Many of the observations about the development of command languages still stand for the presentation of textual information. It is clearly important that the interface uses terms that the user will recognise. My Macintosh continues to present error messages of the form Virtual memory error: -23322111f. This may be useful to me as an engineer but it is extremely irritating as a regular user of the system.

Design Aims For Textual Displays

• consistency of layout - users quickly learn where to focus their attention on a display. If the position of important text is moved then they will have to re-focus their concentration. This lead to distraction, frustration and error.
• minimal memory load on user - users should not have to remember information from one screen when they move to another. Again, this results in high error rates and can lead to frustration. Tasks should be arranged so that completion occurs as soon as possible after the command has been initiated. This leads to the `cup of tea' problem. Start doing something, takes so long that we leave for a coffee/tea. When we arrive back we forget what we were doing.
• input compatibility - users should not be expected to perform complex manipulations between the information presented and the commands that they have to enter into the system. This is particularly important when people can use cut and paste techniques in windowing systems.
• low error rates - ultimately, users must deploy their finite perceptual resources to read your displays. If you use bizarre colours and odd looking fonts this may increase the demands that are bing placed on those resources. This will lead to higher error rates as users miss critical information.

Font Selection

Here is a Java Applet that should enable you to select different fonts:

Fonts are stored in one of two ways. Thy can be stored as bitmap images. The characters are designed either on paper or by using a font design tool. They are then scanned or downloaded into a different bitmap for each character. This has the advantage that relatively little computation is involved in translating a document into the corresponding sequence of bitmaps. It has the disadvantage that quality is lost as the bitmaps are enlarged to different point sizes (see below). This occurs because bitmaps are formed from discrete pixel elements. Any curves will, therefore, appear to be jagged as their size is increased; they show the discontinuity between pixels. Alternatively, fonts can be stored as a number of mathematical functions. This has the advantage that quality is preserved as the scale of the character is increased. The continuous nature of the mathematical functions avoids the 'stair-case' effect that you get when scaling bitmap images. This has the disadvantage that there is a computational overhead associated with fonts that are transformed in this way. What this amounts to is that if you use an obscure font on your system, the user may not have the functions in place to provide a high-quality image. In these circumstances, the display device will typically default to scaling a bitmap with the resulting loss of quality. The moral is - just because it looks good on your display does not mean that it will on the users...

Point Size

effective

Tasteful Design...

emphasis

Layout

• Logical sequencing Users should meet items of text in the order that they have to process them. This implies that a subject's name must appear before their address if that is the convention used in a particular job. By using elicitation techniques, it may be possible to build up complete sequences for many activities. This information can be used to determine when sequences of information may bebroken between displays. Remember, however, that an aim of display design is to reduce the mental load on the user between screens.
• Grouping Similar items of information should be grouped together. This related to the previous point that users should not be required to perform prolonged visual searches in order to assemble necessary items of information.
• Spaciousness Try to avoid clustering information is small areas of the screen. As can be seen on the opposite slide, the more densely packed a display is, the harder it becomes for users to access the information that they want. People are relatively good at using spatial cues to index the information that they want. Packing the display reduces the opportunities to exploit this perceptual resource.
• Simplicity Above all, displays should be simple. If they are cluttered, full of bright colours and weird fonts then many users will interpret this complexity as reflecting the complexity of the system. Too often, designers use presentation resources to impress their colleagues or clients without considering the impact that their decisions will have for prolonged use of the system. One Scottish electrical distribution company bought an X wall (30 square feet of monitors) for its control room. The colours and layout were so complex that the users suffered headaches, eye strain etc. The system was switched off and moved to the visitors center.

Forms
Forms provide a structure for text-based interfaces. Labels are used to prompt users for appropriate input. Command line interfaces lack this structure. Users are often forced to make guesses about possible input sequences. A further advantage of forms is that they are less constraining than menus. Rather than selecting an item from a limited range of options, you are free to choose the text that you want to enter in each field. It would be difficult to provide a menu that lists all of the possible surnames that could be entered into a database. It is also possible to check for erroneous data in form based interfaces. In most cases, users will be warned if numeric data was entered in a name field.

It is important to note that forms dominate data entry applications. These are high-volume interfaces where the speed of data entry is critical. It is, therefore, extremely important that designers provide an optimal layout. Tabbing between different entries in a form can be very frustrating. As with any other dialogue style, optimal designs can only be achieved by closely considering the users' task and not simply by analysing application functionality.

Many companys offer tools that support the creation of form based interfaces. As a consequence, they are often used in situations where command languages or menus might be more appropriate. In order to make informed decisions about when and where to use forms, it is important that we understand their strengths and weaknesses. Here are some advantages of form-based interaction:

• unconstrained values - they are good when a wide range of responses may be provided for a particular field.
• related queries - they are good if many related questions have to be asked about a particular subject. Interaction progresses by gradually filling in the required information. This would take a long time in menu-based systems. Users might easily forget to supply vital input in a command-language interfaces.
• order independence - if users can supply information i a number of different orders then forms can be useful. People can fill in the values that they are sure about first and gradually fill the form as more information becomes available.

• keyboards dependent - if keyboards are not available then there is limited scope for the values to be entered.
• relatively few data values - if there are only a few data values then it may be better to use a menu;
• ordered data entry - if the data has to be entered in a particular order then it might be better to use a prompt with a command line to remind users of the sequence.

Design Aims For Form Filling

• easy navigation. It must be easy to move between forms and to move between the fields on those forms. Most systems use the tab or arrow keys to jump between fields. There must also be some means of moving back to correct earlier items.
• consistent labelling. As in text-based interfaces, the naming of fields must be clear to the user. Instead of different terms, Addr., Address, Employee Domicile stick to the one label throughout the system.
• clear format. There must be clear space between the fields so that users can distinguish between different items of information. It should also be clear that certain areas are for input whilst others will be filled in by the system.
• easy correction. If an unacceptable input is received, for instance a numeral in a name, then error messages should be presented. These should state as much information about the problem as possible. User testing is, typically, required to determine whether these warnings can be understood. Backspace keys and overtyping facilities should be provided to help `repair' any erroneous input. Some form of completion signal is usually required to indicate that all the data has been successfully processed by the system.

Appearance And Composition.

Space is likely to be limited on the display and so it may be necessary to provide additional sources of reference about the data to be entered in each field. If necessary, help facilities and paper documentation should be provided to reiterate the on-screen prompts. The form should provide information about the maximum size of input for each field. It is absolutely vital that you provide feedback if input has been truncated. Searching for user names on partial strings can be ``a risky business''. It can be extremely expensive to rebuild systems once a data set is corrupted and invalid entries have been stored. Such errors can be reduced if the same editing functions are provided throughout all of the forms in a system.

Data fields should be grouped either according to:

• task issues. For example, the most frequently edited fields might be grouped together at the top of the form. If they are spread around the display then the user assumes a navigational cost in moving between the various fields.
• common subjects. For example, address information should appear near to the subjects name and reference details. If this information is spread about the display then users will have to scan the screen to reassemble necessary details when reading the form.

The context panel provides users with information about the purpose of a particular form. It should enable them to identify what they were doing if they have to break their data entry task, for instance in order to answer a 'phone call. The most common way of doing this is to give each screen a name, reference number may be harder to remember unless they have some special significance. The title should always be placed in the same position. As mentioned in previous talks, consistent layout speeds searching tasks and may also help user to distinguish the context information from an ordinary field. This is an important point because some areas of a form will not be editable. If a form has been reached as part of a more elaborate dialogue, users must always be able to find out how they reached this point. One means of doing this is to concatenate the names of the screens that have been visited to reach this point: Account_Details:User_Record:User_Address.

The final component of a form based interface is known as the control panel. This includes information about how to navigate between and within a form. Between forms, users must be able to identify means of leaving the current screen. It is important that there should be some means for the user to exit without saving the information. This must be sufficiently different from the normal quit procedure that they will never get the two commands confused. Finally, it is important that users can correct the information that they have entered within particular fields.

Behaviour

• simple. This is the conventional form. Little error checking is performed on the field information. Users simply select the data item and enter as appropriate. The user presses a particular button to confirm completion or the system assumes completion when the last item has been entered (this last strategy is dangerous because it does not allow the user time to review the form). The advantage of this approach is its flexibility. The user is in control of the data that they enter;
• advanced. These forms are becoming increasingly common. Many fields have default values associated with them. For instance, the postcode of the city in which an office is located or the present date might be entered automatically and only changed as necessary. These systems also possess strong inference capabilities. They can use the information from previous fields to automatically calculate the values for other fields. For instance, the product name might be deduced from its reference number. These dependent fields can be automatically updated if the other fields change. The danger with such approaches is that the defaults might be incorrectly left in and that deduced values might be incorrect. The system has greater control over the form-filling process. This can provoke a negative reaction in many users.

Menus.
The basic difference between menus and forms is that menus offer the user a more constrained choice from a limited number of options. You cannot go into MacDonalds and order a Salad Nicoise, you have to pick something from the menu. This approach offers a number of advantages over command languages. The use of lists reminds users of their options. This can help them to direct their activities. Menus provide prompts that support short and long term memory. Users do not have to search through recollections of previous interaction to recall possible commands. Once they have remembered a command they do not have to continually remind themselves to ensure that it will not be forgotten again. Rather that trying to remember the command to print a file, users simply go to the file menu and browse its entries.

Menus have been widely used in a vast range of applications. The Prestel and Oracle systems have supported well over 300,000 screens. This approach is increasingly being used in embedded applications, ranging from televisions to data-line analysers. They provide good support for novice or intermittent users. The on-line representation of available commands helps users to view and explore their options during interaction. They can also be useful for experts if the command set is so large that additional support is required. In such circumstances, it may not be possible for any individual to remember all of the commands or objects that are available through their interface.

As with form based interfaces, menus have been widely applied and often in areas where text based interaction might have been more appropriate. For instance, I have frequently been forced to navigate through menus that offer between fifty and one hundred different options. In order to identify appropriate uses of this dialogue style it is important to review the strengths of menu based interaction:

• contexts where users are semi-skilled. If users are likely to be unfamiliar with an interace then menus provide a useful way of introducing available commands. This style of interaction is particularly useful in `walk-up and use' systems that are accessible to the general public. Similarly, they often provide a good choice for contexts that suffer from high rates of staff turn-over.
• contexts where the system constrains interaction. Menus are useful in situations of high stress where users are liable to make mistakes in the selection of commands. For example, input that would cause problems in the operation of an application can be greyed out to indicate that they are unavailable.
• contexts with high keystroke error rates. Menus provide quick access to commands through mouse selection or the input of abbreviated command sequences, such as numbers to indicate menu options. This approach is appropriate in cluttered or busy environments where users cannot easily operate a keyboard.
• educational systems. Menus do not force users to memorise complex rules of syntax and grammar in the same way that command languages do. Nor do they provide the `daunting' framework and structure that supports form based interaction. For these reasons, they have been successfully applied in educational software.

• time critical tasks. It can be difficult for users to navigate through several menus under time pressure. It can be extremely irritating if you cannot find the option that you are looking for. As the number of items grows it is possible to become `lost' within a menu.
• poor communications links. If users only have limited communications bandwidth or poor presentation hardware then there may efficiency constraints upon the use of menu based interaction. There are a number of solutions to this, for instance, handling graphical updates on a local machine. This necessarily implies that interface requirements are considered during the architectural planning of the application.
• unpredictable environments Finally, it can be dangerous to provide systems with too much control over the menu options that are available. It can be both dangerous and frustrating if critical items are `greyed out'. It must be possible for users to find out the reasons why a command is unavailable, otherwise the design decision may appear to be both arbitrary and unjustified.

Design Aims For Menus

• clear structure. In interfaces of any complexity it may be necessary to place menus within menus. For example, the file menu must be selected to print a file. This may produce another menu to select the destination printer and so on. It is important that users understand the relationship between these different structures.
• clear labelling of categories Menu items are grouped under categories or headings. If users cannot decode these headings then it will be impossible for them to access the appropriate information. The labelling of individual items should be organised according to the guidelines already presented for forms and command line interfaces.
• appropriate breadth and depth. Designers are faced with a trade-off. They can either make all menu options available from a top-level display. This increases the breadth of the structure and forces users to remember the location of each individual item within a category. If they cannot then there may be a significant increase in search times. Alternatively, items may be grouped within sub-menus that are, in turn accessed from the top level display. This increases the depth of the structure. Users can use category information to access these sub-menus and direct their search task. The problem here is that high navigation costs may be incurred if an entry is not found within a particular sub-sub-sub menu.
• simple selection procedure There is a heuristic in HCI that states frequent commands should be easily performed, less frequent commands may be correspondingly harder to perform. It is important that users can easily select the most common options. However, it should also be the case that potentially destructive options, such as delete or re-format, should involve some confirmation. Inadvertent selections are a continual problem in menu-driven interfaces.

Appearance And Composition.

The individual items have to be grouped under labels. If there is only one menu then this is a trivial task. In more complex systems, it must be possible for users to infer that a particular item is available from a particular menu. Typically, this is done by placing the operations on an object under a menu that is labelled by the name of that object. For example, most interfaces have options such as Print, Copy, Open under the FILE menu. Alternatively, items may be collected under labels that reflect common operations. Various forms of SEARCH may be found under the same menu.

Just as items may be grouped under common labels, they are also grouped within a menu. For instance, creation operations such as Open and New are placed together in the File menu. Again, this supports users' navigation tasks within the menu structure. Finally, any destructive options, such as Delete should not be placed at the top of a menu. In mouse driven systems it is relatively simple to `drop-off' the label and select this option by mistake.

As with form based interaction, menus require some context information if novice users are to understand their location in an interface. Typically, this is done by providing each menu with a name. In simple examples, this may remain visible throughout the interaction. In more complex examples, the label that is used to access a sub-menu may remain visible until the user makes their selection. This approach can be repeated for sub-sub menus Format/Page/Size or Edit/Accounts/Marketing/1996. As in form based interfaces, a consistent layout should be exploited. Users must know where to find the title of a menu in case any confusion occurs. This is likely if similar menu options appear in several different places within an interface. For instance, Open may refer to a File menu, an Application listing or a Directory.

The control panel provides guidance on operating the menu. This may simply consist of a prompt (eg $>$ or Enter number:). Prompts must be unambiguous. It must be obvious to the user that they do not form part of the menu structure. Alternatively, control information may be omitted if users have sufficient expertise to understand the selection process.

Behaviour

If menus have many potential entries then they may be provided with scrolling mechanisms. For example, my Macintosh contains many different fonts. It is impossible to display the list on a single screen but I can use a scroll bar to move through them. This creates significant navigational problems, it is an extremely broad structure. It is, however, the only option when there is no meaningful way to group the items into sub-menus. If designers were sufficiently concerned about access times they might have grouped the fonts under alphabetic labels Names A-D, Names E-G...

Finally, it is vital that designers consider the ways in which users can exit from menu structures. In mouse-driven interfaces this may be done by simply releasing the button when it is outside the menu region. In text-based interfaces it is usual to provide a Cancel option. Designers also need to consider how to recover previous menu accesses when users finish their current selection. Should they be returned to the previous menu? Should they be returned to a `home' menu?

Graphical & Direct Manipulation Interfaces
This area could be the subject of its own course. The last few years have seen the effective development of thousands of different styles of graphical user interfaces. There are also a number of innovative new styles being developed in Japan and the United States. We will only have time to review some of the major issues in this section but it should provide you with an overview of your design options.

The term graphical user interface refers to any interactive system that uses pictures or images to communicate information. This is an extremely wide definition. It includes keyboard-based systems that only use graphics to present data. It also includes walk-up and use systems where users only interact by selecting portions of a graphical image. In contrast, the term direct manipulation refers to interfaces with the following characteristics.

• both the objects and actions are visible to the user;
• the actions are rapid, reversible and incremental;
• actions are applied directly to the objects of concern rather than using the complex syntax of a command language interface.

The distinction between graphical and direct manipulation systems becomes important when we consider their uses. It is often claimed that graphical displays support novice users. However, if they are forced to operate the systems through complex command languages, as with CAD applications, then this need not be the case. In contrast, Shneiderman's previous definition of direct manipulation illustrates the benefits that this style of use is intended to offer for novice users. Actions are to be visible and hence may be easily accessed. They are rapid so feedback is quickly obtained about the success or failure of a command. They are reversible and so it is possible to undo previous mistakes. Finally, it is important to point out that some systems may be classed as direct manipulation without supporting the general use of graphical images. For instance, many spreadsheets enable users to directly interact with the objects of interest. Mice and other pointing devices can be used to select cell. Operations are visible and incremental. Values can be dragged and then dropped into their destination.

The following list reviews the strengths of graphical interaction:

• visibility. Graphical displays can be used to represent complex relationships in data sets that would not, otherwise, have been apparent. This use of graphics is illustrated by the bar charts and graphs that were introduced in the section on requirements elicitation.
• cross-cultural communication. It is important that designers exploit the greatest common denominators when developing interaction techniques. Text-based interfaces have severe limitations in a world market. Graphical interaction techniques are not so limited. In particular, ISO standards for common icons provide a graphical `lingua franca'. For this reason, interfaces are increasingly borrowing symbols and icons from road signs, industrial labelling etc.
• impact and animation. Graphical images have a greater intuitive appeal than text-based interfaces, especially if they are animated. The use of such techniques may be beneficial in terms of the quality and quantity of information conveyed. It may also be beneficial in improving user reaction's to the system itself.

• ``Can't see forest for the trees''. There is a tendency to clutter graphical displays with a vast array of symbols and colours. This creates perceptual problems and makes it difficult for users to extract necessary information. Graphical images should be used with care and discretion if people are to understand the meanings associated with the symbols and pictures, see next point.
• ambiguity Graphical user interfaces depend upon users being able to associate some semantic information with the image. In other words, they have to know the meaning of the image. From our earlier discussion, they have to bridge the gulf of evaluation. A users' ability to do this is affected by their expertise and the context in which they find the icon. For example, if you see a circle with two lines through it on a user interface then you would probably not understand it's meaning. If you saw it on the back of a shirt then you might rightly recognise it as a warning not to put it in a tumble-drier.
• imprecision There are some contexts in which graphical user interfaces simply cannot convey enough information without textual annotation. For instance, using the picture of an expanding and shriking bar to represent the changing speed of a car is probably not a good idea when there is an important difference between 60 and 61 miles per hour...
• slow speed Graphical presentation techniques may not be suitable if there are relatively low-bandwidth communications facilities or low quality presentation devices. The performance problems need not relate directly to the graphical processing. Network delays may delay the presentation of results and this violates the rapid criteria for direct manipulation.

Design Aims For Graphics & Direct Manipulation

• clear semantics. As mentioned in previous slides, it is vital that users are able to accurately interpret the meanings of graphical symbols. This does not mean that the images actually have to resemble the objects that the user interacts with. For instance, the icons used in road signs, the national speedlimit, clearway etc bear little resemblance to their actual purpose. Where such abstract images are used, users will have to learn to interpret the symbols correctly. This means that for infrequent users, it may be better to employ icons with a more direct mapping to the objects that they interact with or to sue an alternative dialogue style.
• unambiguous. If symbols have more than one meaning then it will be difficult for user to interpret them correctly. It is vital to check that the symbols which designers use do not have anther meaning for the users themselves. For example, the colour red is used to indicate that something has stopped. It is also used in electrical engineering to indicate that the circuit is live. There must be no confusion over the use of this colour, for obvious reasons. A related point is that designers must be careful not to intentionally overload symbols with many different meanings. For instance, it is common to see + and - on video recorders. These are used to move change channels, alter volume, change the time etc depending on the mode that the user is in. This, typically, leads to lots of confusion for both novice and experienced users.
• `task fit'. It is important that graphical user interfaces should `fit' with the overall task structure. In particular, animated images can distract users from other tasks. It is for this reason that highly interactive graphical displays are not, typically, found in military aircraft.
• natural interaction. This is similar to the previous point except that it relates more narrowly to input and output mechanisms that the users must exploit. For example, if the primary means of providing input to the system is textual and the most important information required by the user is textual then there may be few benefits to a graphical style of interaction. Similarly, it is much more `natural' to use a direct manipulation style to sweep the area of a rectangle rather than issuing a textual command create rectangle 100, 202, 330, 400.

Appearance And Composition.

It is worth noting that there are four different types of commonly used icons in interactive systems:

• those that exactly resemble the intended objects. These are rare but you do find the use of people's photographs in communications and conferencing systems.
• those that resemble typical objects. For instance, the Apple trashcan doesn't look like any bin that I've ever owned but I can still recognise it.
• those that symbolise an abstract property. The up and down arrows do not represent the arrows themselves but are used to indicate motion through a file.
• those that represent an arbitrary sign. I'm not sure why people designed the do not tumble dry sign to be the way it is...

One of the most important guidelines for the composition of graphical displays is that designers should always avoid clutter. There are a number of reasons for this:

• perceptual loading. It can be difficult for users to take in and understand the many different objects that are presented on the screen; some may be missed entirely.
• semantic loading. The more objects that you present on the screen at once, the more meanings users will have to disambiguate.
• searching. The more objects you present, the harder it is for users to find the ones that they really need.
• manipulation. The more objects there are on the screen, the smaller the average size of each object will be. This makes it harder to select and manipulate individual screen components. Fitt's law relates the time taken to select an object to its size and the distance from the cursor $time = log_{2(0.5+(Distance*2/Size)/10)$.

Graphical user interfaces perhaps present the greatest challenge to interface designers. The rage of possible options, even for simple objects, is absolutely vast. Previous pages have illustrated different approaches to a switch. Scroll bars present a similar range of options. There is the standard Macintosh version. Other types are used in the X window managers etc.

This variety makes graphical interface design a key area for user involvement in the development process. In many cases, the technical problems in implementing the various techniques are exactly the same. However, if users are accustomed to one style of interface there must be sound reasons if an alternative technique is to be implemented. Similarly, with direct manipulations systems it is vital that designers validate their choice of symbols. Interviewing techniques and questionnaires can be used to find out what the symbols mean for the end-users.

We have emphasised, however, that context plays an important role in determining the meaning of icons. Symbols in the context of a shirt collar may appear to be straight-forward and obvious. In the context of a user interface they may seem bizarre and confusing. The problem here is that in order to provide the necessary context, you may have to go ahead and develop an entirer graphical interface. Pencil and paper prototypes provide a low-cost alternative to this approach. As mentioned in previous exercises, this technique uses sketches of potential screen layouts. These are shown to users who can then provide feedback on the icon design and layout. If sufficient screens are drawn then designers can use `walk-throughs' by passing potential displays to the user as they select the various commands that are supported by the system. These techniques can be used in addition to structured interviews to provide a valuable focus for discussion. Always present alternative options so that users do not simply agree upon the first version that they see. Beware: there is a danger that users will become so focused upon the prototype that they prefer it to the implementation. Also, beware that you may not be able to implement the system that you prototype. Keep the software team `in the loop'.

Finally, it is important to remember that by implementing direct manipulation, graphical user interfaces you may restrict your user group. Blind users can exploit screen-readers to access textual interfaces. These systems do not currently work for full direct manipulation systems. If you use colour, you may make it difficult for users who are colour blind. As a rule of thumb, colour should be used sparingly and should provide redundant information. It should alway be possible for users to work out the information it represents from another source.

Behaviour Of Graphical User Interfaces

• selecting. This involves the picking of one object amongst many. It is important that selections can be passed through several layers of objects on the screen. As clutter increases, it becomes more difficult to perform unambiguous selections.
• positioning. This involves moving objects in relation to other objects or to a fixed point on the screen. The physical characteristics of input devices can effect this operation. It is easier to position with a mouse than a tracker ball because of the nature of the feedback received from the hand movements. It is also important to notice the feedback that the user receives during positioning operations. Is the object carried by the cursor during the move? Does a shadow of the object appear under the cursor while the original object remains in place until the selection is released etc?
• quantifying. Even in graphical interfaces it will be necessary to input exact quantities. For example, providing exact numeric values for the area of a bar in a graph.
• orienting. It must be possible to place objects in a variety of orientations to other objects or to arbitrary planes in the display. For example, placing two lines at right angles to each other.
• specifying. It must be possible to specify attributes of objects. For example, even graphical representations of files must have associated access privileges, creation dates etc.
• entering text. As mentioned, it is rare to have purely graphical user interfaces.
• stretching. It is possible for users to enter text to stretch the extent of existing objects. It is more natural, however, to perform this operation graphically
• sketching. Existing graphics systems can appear to be very poor when compared to free-hand drawing. Many systems use bitmaps to represent curved lines in terms of individual and unconnected pixels. The problems are similar to those with bitmapped fonts: images appear crude and curves suffer from the staircasing effect mentioned in the section on textual interfaces. The second alternative is to represent curves using splines; mathematical functions that describe points in a line. The problem here is that the functions rely upon control points to sections of the curve. These points constrain the angles in the line and are extremely unnatural when attempting to sketch an image. This is why it can be so irritating to draw curves in many of today drawing packages.

Evaluation

Why bother to evaluate?
There are a number of reasons that justify the use of evaluation techniques suring the development of interactive systems. They provide benefits for many of the parties involved in development:

• designers. Evaluation techniques enable designers to judge the adequacy of their designs. It provides evidence that can be used in the marketing of a product and can convince clients that a product meets their needs. It can also be used to inform the development process. For example, one means of deciding whether a graphical or a textual interface is best would be to run a trial evaluation on two prototypes.
• clients. They enable clients to make informed decisions about the software that they pay for, Evaluation tests can also be set as mile-stones in the development process. Practical implementations can be signed off as they pass the required stages.
• users. Evaluation techniques provide users with the opportunity to voice their opinions and preferences. The aim of the exercise is largely to elicit their views. A secondary objective is to make them feel part of the development process.

The evaluation of user interfaces is closely linked to requirements elicitation. Like the techniques introduced earlier in the course it is vital that designers have a clear set of objectives in mind before they start to evaluate an interactive system. For example, evaluation techniques might be used to find out about:

• the user and their tasks. For example, evaluation techniques can be used to determine whether systems actually support user tasks in the manner predicted. Does the interface provide the relevant information when the user needs it? IS the dialogue style appropriate for the level of expertise and confidence of the user population? Evaluation techniques can also be used to find out how long it will take users to learn how to operate the system and its interface. Evaluation techniques can also provide evidence about likely errors and their associated frequencies. Finally, they can be used in conjunction with questionnaires etc to establish levels of user satisfaction with potential interfaces.
• {the system and interaction devices. Evaluation techniques can be used to find out if users can successfully operate system hardware. This includes physical interaction devices but also incorporates processors and disks. Delays in the refresh rate for graphical systems can cause sever usability problems when moving between machines. It is for this reason that many interface development companies advocate the use of low end machines for user testing. Its a common phenomena to find that all is well on the designer's high spec. system but is completely unusable on the typical customer configuration.
• the working environment and supporting documentation. Finally, evaluations can be carried out in the eventual work-place to determine whether the users' environment will cause any problems. Often these final stages of analysis are high-cost. Any changes discovered at this point will be hard to fix. In many cases, it is easier to document the problem and provide support through training.

When To Evaluate

Formative Evaluation

If formative evaluation is to guide development then it must be conducted at regular intervals during the design cycle. This implies that low cost techniques should be used whenever possible. Pencil and paper prototypes provide a useful means of achieving this. Alternatively, there are a range of prototyping tools that can be used to provide feedback on potential screen layouts and dialogue structures.

Formative evaluation can be used to identify the difficulties that arise when users start to operate new systems. As mentioned, the introduction of new tools can change user tasks. This means that interface design is essentially an iterative task as designers get closer and closer to the final delivery of the full system.

Summative Evaluation

The bottom line for summative evaluation should be to demonstrate that people can actually use the system in their working setting. This necessarily involves acceptance testing. If sufficient formative evaluation has been performed then this may be a trivial task. If not then this becomes a critical stage in development. A friend of mine had to re-design an automated production system where the night-staff kept reverting to manual control. As a stop-gap the production manager had to move a camp-bed into the supervisors area to check that the system had not been switched off. Clearly, such problems indicate wider failings in the development process if they only emerge at the acceptance testing stage.

How To Evaluate
The following pages introduce the main approaches to evaluation.

Scenario-Based Evaluation

The benefit of scenarios is that different design options can be evaluated against a common test suite. Users are then in a good position to provide focussed feedback about the use of the system to perform critical tasks. Direct comparisons can be made between the alternatives designs. Scenarios also have the advantage that they help to identify and test hypotheses early in the development cycle. This technique can be used effectively with pencil and paper prototypes.

The problems with this approach are that it can focus designers' attention upon a small selection of tasks. Some application functionality may remain untested while users become all to familiar with a small set of examples. A further limitation is that it is difficult to derive hard empirical data from the use of scenario based techniques. In order to do this they must be used in conjunction with other approaches such as the more rigorous and formal experimental techniques.

Experimental Techniques

There are some notable examples that have demonstrated the success of this approach. For instance, the cockpit instrumentation on Boeing 727s were blamed for numerous crashes. One of Boeing's employees, Conrad Kraft, conducted a series of laboratory simulations to determine the causes of these problems. He couldn't do tests on real aircraft and so he used a mixture of low-fidelity cardboard rigs and higher quality prototypes. In the laboratory he was able to demonstrate that pilots over-estimated their altitude in particular attitudes when flying over dark terrain. This led to widespread changes in the way that all commercial aircraft support ground proximity warning systems. Similar approaches have been used to demonstrate that thumb-wheel device reduce error rates in patient monitoring systems when compared to standard input devices such as mice and keyboards.

There are a number of limitations with the experimental approach to evaluation. For instance, by excluding distractions it is extremely likely that designers will create a false environment. This means that the results obtained in a lab setting may not be useful during `real-world interaction'. A related point is that by testing limited hypotheses, it may not be cost effective to perform this `classic' form of interface evaluation. Designers may miss many more important problems that are not affected by the more constrained issues which they do examine. Finally, these techniques are not useful if designers only require formative evaluation for half-formed hypotheses. It is little use attempting to gain measurable results if you are uncertain what it is that you are looking for.

Cooperative evaluation techniques.

The approach is extremely simple. The experimenter sits with the user while they work their way through a series of tasks. This can occur in the working context or in a quiet room away from the `shop-floor'. Designers can either use pencil and paper prototyping techniques or may use partial implementations of the final interface. The experimenter is free to talk to the user as they work on the tasks but it is obviously important that they should not be too much of a distraction. If the users requires help then the designer should offer it and note down the context in which the problem arose, for further reference. The main point about this exercise is that the subject should vocalise their thoughts as they work with the system. This can seem strange at first but users quickly adapt. It is important that records are kept of these observations, either by keeping notes or by recording the sessions for later analysis.

This low cost technique is exceptionally good for providing rough and ready feedback. Users feel directly involved in the development process. This often contrasts with the more experimental approaches where users feel constrained by the rules of testing. Most designers will already be using elements of this approach in their working practices. It is important to note, however, that vocalisations are encouraged, recorded and analysed in a rigorous manner. Cooperative evaluation should not simply be an ad hoc walk-through.

The limitations of cooperative evaluation are that it provides qualitative feedback and not the measurable results of empirical science. In other words, the process produces opinions and not numbers. Cooperative evaluation is extremely bad if designers are unaware of the political and other presures that might bias a user's responses. This is why so much time discussing different attitudes towards development.

Observational techniques.

Ethnomethodology briefly requires that a neutral observer should enter the users' working lives in an unobtrusive manner. They should `go in' without any hypotheses and simply record what they see, although the recording process may itself bias results. The situation is similar to that of sociologists and ethnologists visiting remote tribes in order to observe their customs before they make contact with modern technology. The benefit of this approach is that it provides lots of useful feedback during an initial requirements analysis. In complex situations, it may be difficult to form hypotheses about users' tasks until designer shave a clear understanding of the working problems that face their users. This technique avoids the problems of alienation and irritation that can be created by the unthinking use of interviews and questionnaires.

The problems with this approach are that it requires a considerable amount of skill. To enter a working context, observe working practices and yet not affect users' tasks seems to be an impossible aim. At present, there seem to be no more pragmatic approaches to this work in the same way that cooperative evaluation developed from experimental evaluation. There have, however, been some well-documented successes for this approach. Lucy Suchman was able to produce important evidence about the design of photocopiers by simply recording the many problems that users had with them.

The Kitchen Sink Approach.