USER INTERFACE DESIGN 2.pdf Document added correctly, Exams of Network Design

Download USER INTERFACE DESIGN 2.pdf Document added correctly and more Exams Network Design in PDF only on Docsity!

Introducing

User Interface Design

example, computer-based mi- crochip technology can be found embedded in personal goods such as digital watches and mobile phones, in do- mestic appliances such as microwave ovens, washing machines, and video re- corders, and in the instru- ment panels of cars. Again, but less directly, computers are used when we shop; many stores use laser scan- ners that “swipe” the bar codes on goods to record both the goods we purchase and total the amounts we spend. Behind the scenes, the scanning of goods assists with automated stock control and stock reordering. When we take money from our bank accounts using an auto- mated teller machine (ATM) or when we use ATM debit cards to buy goods elec- tronically, our bank details are accessed via the bank’s computer system. The list of everyday ways in which we use computer-based systems seems endless.

Whether we are aware of it or not, computers pervade our life. Computer applica- tions are used either by us, or for us, in some way almost every day. The user inter- face (or just interface ) is that part of the computer system with which a user interacts in order to undertake his or her tasks and achieve his or her goals.

The user interface and the ways of interacting with computer-based systems are dif- ferent for each system. For example, digital watches generally have buttons that users press to set the time or use the stopwatch facility. Microwave ovens might have dials to turn or a digital display and a touchpad of buttons to set the cooking time. PCs have a screen, a keyboard, and a mouse (or sometimes a trackball or a joystick) that enable interaction to take place. So each user interface is different. Depending on the design of the interface, each of these systems will either be usable — that is, easy to learn and easy to use — or problematic for users.

Earlier we described a computer system as the combination of hardware and soft- ware components that receive input from, and communicate output to, a user to support his or her performance of a task. Although the user interface is simply the part of the computer system that enables interaction and serves as a bridge between users and the system, to users the interface often is the system (Constantine and Lockwood, 1999). The user’s view of a computer system is often limited to and based solely on his or her experience of the user interface (see Figure 1.2).

CHAPTER 1 | Introduction

4 Part 1

Figure 1.1 The interface is the part of the computer system with which the user interacts in order to use the system and achieve his or her goal.

For example, when you use the controls on the panel of a washing machine, the con- trols form the interface between you and the machine — you are not concerned with the underlying technology or the software of the washing machine itself. What is important to you is that the controls and their settings are intuitive and easy to under- stand and use so that you will achieve your goal of laundering clothes. Similarly, when you surf the Internet, the pages of a web site displayed on your PC’s monitor form the interface between you and the site. The web page UI may contain controls like scroll bars, clickable hot spots, or links in the form of text or images. These items are all part of the interface.

3 The Importance of Good User Interface Design Good user interface design is important because, as we have discussed, computer use permeates everyday life. Early computer systems were expensive and were devel- oped mainly for particular tasks, like advanced number-crunching; as such, these systems were employed only by specialist computer users. Often the systems had command-line interfaces, with obscure commands known only by these specialist users. Thus, the user had to adapt to the system, and learning how to use the system required much effort. Computing systems, however, are no longer the province of the specialist user. As the price of PCs and computer-based technologies has fallen, the ownership of these types of goods by nonspecialists has widened. In August 2000, 51% of households in the United States had access to one or more home computers, and 42% of house- holds had access to the Internet (U.S. Census Bureau, 2001). In 2002, 54% of house- holds in the United Kingdom had access to some form of home computer, and 44% had access to the Internet (National Statistics, 2004). Therefore, the need for the design and development of user interfaces that support the tasks people want to do and that can be used easily by a variety of people with varying abilities has become

3. The Importance of Good User Interface Design

5 Part 1

User interface

User input

System output

Underlying hardware, software, interaction devices

Figure 1.2 To the user, the interface is the computer system. (From Constantine and Lockwood, 1999.)

You will learn more about command-line interfaces and other interaction styles in Chapter 11.

The design of controls, and the selection of interaction devices for input and output, will be discussed further in Chapters 12 through 14.

the interface is extended by looking beyond the users’ immediate work environment and looking at the wider context or situation within which the system is expected to operate (i.e., the domain, tasks, and the environment that make up an organization). Thus, usability is concerned with the extent to which users of an application are able to work effectively, efficiently, and with satisfaction in their particular contexts. A computer system that is usable in one context may be unusable in another. As a user interface designer, it is important to consider the context in which the system will be used. A UI that users find pleasurable is likely to be more acceptable than one that annoys them. Users are more likely to use a computer system that they enjoy than one that irritates them. Contented users are likely to be more productive, so usability is clearly related to user satisfaction (Constantine and Lockwood, 1999).

3.2 The Problems of Poor or Bad User Interfaces

 User Frustration and Dissatisfaction Problems for users and the public in general arise as a result of poorly designed user interfaces. The term “computer rage” was coined in 1999 following a Market & Opinion Research International (MORI) poll conducted on behalf of Compaq Com- puter Limited, UK and Ireland. The study, Rage against the Machine (Compaq, 1999) , (www.mori.com/polls/2002/bthomecomputing.shtml) found that, for one reason or another, stress and frustration levels with workplace technology are rising. Workers, it reports, have started to become both verbally and physically abusive toward the information technology (IT) in use (see Figure 1.3 and Box 1.1). Concerning mone- tary matters, the study indicates that [t]he cost to business of this increase in stress levels of employees is not only based on sick days or under-performance, but also the working time lost through waiting for IT problems to be solved. Confederation of British Industry (CBI) statistics cur- rently evaluate this at a staggering £25,000 ($40,000) per person in lost business each year (based on one hour a day being spent sorting out IT problems). (p. 4) In October 2002, research for British Telecom (BT) Home Computing, (www.mori.com/ polls /2002/bthome-topline. shtml) again conducted by MORI, found that 70% of per- sonal computer users suffered from “PC rage” — that is, the users surveyed admitted to shouting, swearing, or being violent to their computers when problems like crashing or virus infections arise.

You will learn more about domains, tasks, and environ- ments in Chapter 4.

3. The Importance of Good User Interface Design

7 Part 1

Figure 1.3 Computer rage: Workers have started to become physically (and verbally) abusive toward IT.

CHAPTER 1 | Introduction

8 Part 1

Box 1.1 Man Shoots Laptop A 48-year-old man, George Doughty, was allegedly so frustrated by his laptop crashing that he took a handgun and shot it four times. According to police he apparently hung the destroyed laptop on a wall as if it were a “hunting trophy.” Lafayette police officer Rick Bashor told local newspapers, “It’s sort of funny, because everybody always threatens their computers, [but] it’s the first time someone shot a computer because he was upset with it.” The man admitted to police that he should not have shot his laptop, but that it seemed appropriate to at the time. From http://news.bbc.co.uk/1/hi/world/americas/2826587.stm, reported March 6, 2003, downloaded June 1, 2004

Box 1.2 Survey Highlights Computer Rage One in five Scots suffers from “Internet rage” and some feel like hurling their computers through a window, according to a survey undertaken in February

2004. Around 1000 Scots were asked to tick a box with several options about their pet hates in everyday life for the survey this month. Some 45% of those polled blamed sluggish Internet connections for making their blood boil. This was more than twice the number of people (20%) who said watching their favourite soccer team get beaten drove them mad.... One in 10 surfers con- fessed they sometimes felt like punching their keyboard, whacking the monitor with a hammer and even throwing their PCs out the window. A third of people quizzed said they had to walk away to cool down. Additionally, one fifth of Scots feel that slow Internet connections at work make them lose up to an hour a day. From Jude Sheerin, PA News , as reported at news.scotland.com, http://news.scotsman.com/latest.cfm?id=2522311, February 12, 2004.

Despite more than two decades of HCI research, it remains an unfortunate fact that many computer systems do not do what users want them to do. Users often describe their difficulties in system use as “computer problems,” which is nonspecific as to the source of the problems. There could be several explanations. For example, the prob- lems could be related to buggy software or to the use of older, less efficient hardware or technology that slows the processing of information. Or maybe there was no clear understanding about the work environments in which the new computer systems were expected to operate. Box 1.3 looks at problems that occurred when the UK Passport Agency introduced a new computer system. Equally, a poorly designed user interface could have contributed to the problems. While there is no direct evidence in any of the news reports to suggest that poor user

(£12.6 million), which included nine million dollars (six million pounds) on staff overtime and at least $242,000 (£161,000) in compensation to the hundreds of people who missed their vacations as a result of not receiving their passports on time. The Passport Agency also spent $24,000 (£16,000) on umbrellas for people who had to wait outside of passport offices in the rain to get their passports over the counter. Subsequently the price of a passport was increased. The supplier of the computer system had agreed to pay $3.7 million (£2.45 million) of the costs, leaving the remain- der to be paid by the taxpayer. In these days of payment for productivity and effi- ciency, wages may have been lost if agency workers’ earnings were linked to a level of productivity they were unable to meet because the computer system was unfit for its purpose.

3.3 Safety and the User Interface

So far we have considered the problems of poor user interfaces in terms of user frus- tration and dissatisfaction, and the loss of productivity and efficiency to business. There is another important aspect to consider: the issue of safety, both for computer systems users and the general public. Systems in which human or environmental safety is of paramount concern are referred to as safety-critical systems. These systems include aircraft, aircraft flight decks, air traffic control consoles, nuclear power plants, control systems, and medical devices. The Three Mile Island nuclear power plant disaster (see Figure 1.4 and Box 1.4) illustrated that safety can be severely compromised by poor user interface design, with potentially serious consequences.

CHAPTER 1 | Introduction

10 Part 1

Box 1.4 The Three Mile Island Nuclear Power Plant Disaster One of the most discussed issues during the early 1980s was the Three Mile Island nuclear power plant disaster. The incident nearly resulted in a meltdown of the nuclear reactor. The cause of the incident was never conclusively deter- mined, but experts, official bodies, and the media all blamed a combination of operator error and bad interface design. In particular, much media attention and several official reports focused on the design of the control panels in the process plant. The incident could have been prevented if the control panels had been designed to provide the operators with the necessary information to enable them to perform their tasks efficiently and correctly. The following are just some of the interface problems that were identified:

• A light indicated that a valve had been closed when in fact it had not.
• The light indicator was obscured by a caution tag attached to another valve controller.

3. The Importance of Good User Interface Design

11 Part 1

Figure 1.4 The Three Mile Island nuclear power plant.

• The control room alarm system provided audible and visual indication for more than 1500 alarm conditions. Evidently this number of alarms was intended to facilitate control of the entire plant during normal operating conditions. However, the layout and grouping of controls on the control panel had not been well thought out and so enhanced, rather than mini- mized, operator error (Brookes, 1982; cited in Leveson, 1995).
• A single “acknowledge” button silenced all the alarms at the same time, but it was not used because the operators knew they would lose information if they silenced some of the alarms. There was simply no way for the operators to cancel the less important signals so that they could attend to the impor- tant ones. The root of the problem, therefore, seemed to be that the control panels did not support the task of serious error and incident recovery. The control panels misinformed the operators. They did not indicate to the operators the true state of affairs in the reactor plant, and they did not provide the necessary informa- tion in a form that the operators could understand and use to rectify the situation.

for Gore (which required them to punch the third hole) but they mistakenly punched the second hole down because Gore was listed second on the left.  Small Irritations Are Also a Problem If you have found it difficult to relate to the “catastrophic” examples we have dis- cussed so far, there are many less disastrous but still problematic examples that may be more familiar to you. Take, for instance, the process of shutting down your com- puter from Microsoft Windows. To do this, you have to press the Start button on the task bar, and find the command Shut Down on the menu. Intuitively, is that where you would expect the Shut Down command to be? What other domestic appliance, or any other type of device, is stopped by starting it? Although the Start button may not have been the obvious place to look for the Shut Down command when you first used Windows, once you have used Windows for some time you adapt to what it makes you do to shut down your computer and you just do it.

EXERCISE 1.2 (Allow five minutes) Think about your use of the different software applications provided in the Microsoft Office Suite or in another suite of office applications that you use (e.g., StarOffice from Sun). Choose one application, and think about a particular feature that you find confusing when you use it.

DISCUSSION

Debbie writes: The application I use most often from the Microsoft Office Suite is Word. For me, a confusing feature in more recent versions of Word is tabbed

3. The Importance of Good User Interface Design

13 Part 1

Box 1.5 A Palm Beach Voter Comments on the Disputed Ballot

Tuesday at the polls, the ballot information was very confusing if one was voting for the Democrat. It was hard to know whom I was voting for, the way the ballot was printed. I did not know whether I was voting for my choice, Al Gore, or for Pat Buchanan. That was very scary and upsetting. I had to take the ballot out a couple of times and place it back again to be sure that the arrows pointed to the right hole; even after the third try, I was not sure whom I was voting for, and that makes me very mad. Many other citizens have complained regarding this situation. I am sure this was extremely confusing for senior citizens especially. Delia Pinto-Houbrick From the Palm Beach Post , letters to the editor, November 10, 2000, www.palmbeachpost.com, visited July 8, 2003.

dialogs. Specifying document settings is done via the Options tabbed dialog box, which is accessed from the Tools menu.

Before my work computer was upgraded, I had been using Word 97 for a number of years. In Word 97, there are only two rows of tabs for setting document options. As there are more tabs in one row than in the other, it is easier to see and under- stand how the tabs move when a tab is clicked on.

With greater word processing functionality, the Options dialog box became more complex in Word 2002; there are eleven tabs in the Options dialog box arranged in three rows of tabs. Clicking on any tab causes a puzzling rearrangement of the tabs. In fact, each row of tabs moves as a whole; only the row positions are changed rather than the positions of the tabs themselves, so there is some reason to it (see Figure 1.7).

CHAPTER 1 | Introduction

14 Part 1

The “Options” dialogue box from the “Tools” menu in Word 97

The “Options” dialogue box from the “Tools’ menu in Word 2002

Choosing the “File Locations” tab only makes the two rows of tabs swap positions. The ordering of the tabs from left to right does not change.

Choosing the “Spelling & Grammar” tab makes the three rows of tabs rotate their positions. When this is done in real time the tabs seem to scramble, and it is hard to see that the ordering of the tabs from left to right does not actually change. Thus it is far easier to see and follow the movement of the tabs in Word ‘97 than in Word 2002, the more current version.

Options Track Changes User Information Compatibility File Locations View General Edit Print Save Spelling & Grammar Show Draft font Bookmarks

Normal view options

File types: Location:

Track changes User Information Compatibility File Locations

View General Edit Print Save Spelling & Grammar

?

Options Track Changes User Information Compatibility File Locations

Security Spelling & Grammar View General Edit Print Save

?

Documents C:\Debs_tmp\Dks\files\WORD_FLZ Clipart pictures C:__\Microsoft_Office\Clipart

Show Startup Task Pane Smart tags Windows in Taskbar Options User Information Compatibility File Locations View General Edit Print Save

?

Spelling Check spelling as you type

Security Spelling & Grammar Track Changes

Figure 1.7 A comparison of tabbed dialog boxes for Word 97 / Word 2002.

4.2 The Classic Life Cycle

User-centered design and traditional software engineering take very different approaches to computer system design. Traditionally, software developers have treated each phase of the software design life cycle as an independent part of soft- ware development, which must be completely satisfied before moving on to the next phase. This is particularly so in relation to the classic life cycle (also known as the waterfall model, so named because of the cascade from one phase to another; see Figure 1.8). It prescribes a predominantly sequential transition between the succes- sive software life cycle phases, where each phase is completely satisfied before the next begins (this is represented in Figure 1.8 by the red arrows). This view is, of course, simplistic. Software engineers readily accept that although the design is guided and regulated by this top-down somewhat linear model, in practice there are many iterations up and down between stages. Sommerville (1992), for example, has the following to say on the matter: In practice, however, the development stages overlap and feed information to each other. During design, problems with requirements are identified; during coding, design problems are found; and so on. The software process is not a simple linear model but involves a sequence of iterations of the development activities. (p. 7) Therefore, within the software design life cycle there is a need for the phases to feed information to each other, and for iteration, rather than the development proceed- ing from start to finish in a simple linear fashion. This iteration is represented in Figure 1.8 by the blue arrows. The essential difference between the classic life cycle

CHAPTER 1 | Introduction

16 Part 1

System and software design

Requirements definition

Operation and maintenance

Integration and system testing

Implementation and unit testing

Figure 1.8 The classic life cycle. (From Sommerville, 1995.)

and user-centered interface design is that user interface design and development is based on the premise that users should be involved throughout the design life cycle. Additionally, the process should be highly iterative, so that the design can be tested (or evaluated) with users to make sure it meets the users’ requirements. Unlike this iterative design process, the waterfall life cycle generally leaves evaluation to the end. Let us look at these aspects further. Figure 1.9 illustrates the iterative user interface design and development process.

4.3 Involving Users

The way to be user-centered is to involve users and to pay attention to their views. This can include a variety of approaches, from simply observing users’ working prac- tices as part of collecting system requirements, to using psychologically based user- modeling techniques, to including user representatives on the design team. More important, users should be involved in the testing and evaluation of the system during its design and development. But who are the users?  Who Are the Users? In a user interface design project, developers generally refer to several types of people as users:

• Customers, who pay for and perhaps specify the computer system under development
• Other people within the users’ organizations who have an interest in the development of the system
• Users or end users — the people who actually use the system directly to undertake tasks and achieve goals 4. Designing for Users

17 Part 1

The user interface design and development process

Design

User testing and evaluation Prototyping

Figure 1.9 The iterative user interface design and evaluation process. (From Greenberg, 1996.)

It has sometimes been challenging to work as a team as we are scattered across different time zones and some people have moved on to other work since they made their original contributions.

4.4 Making the Design Process Iterative

Making the user interface design and development process iterative is a way of ensur- ing that users can get involved in design and that different kinds of knowledge and expertise related to the computer system can be brought into play as needed. We shall use an approach adapted from a model proposed by Hix and Hartson (1993). It is known as the star life cycle for obvious reasons, as you can see from its appearance in Figure 1.10. The star life cycle encourages iteration. First, you will notice that the central point of the star is evaluation , which is viewed as being relevant at all stages in the life cycle and not just at the end of product development as the classic life cycle tends to suggest. Evaluation is concerned with gathering data about the usability of a design or product by a specified group of users for a particular activity within a specified environment or work context. Not surprisingly, a host of different evaluation tech- niques are needed to support the different stages of design and to reflect the design needs of different kinds of products. These include interviews with users and others, observing users in their workplace, and getting users’ opinions from questionnaires or other types of surveys. Second, the star life cycle is “intended to be equally sup- portive of both top-down and bottom-up development, plus inside-out and outside- in development” (Hix and Hartson, 1993, p. 101). Thus, a design can start with any process in the star life cycle.

4. Designing for Users

19 Part 1

Implementation

Prototyping Requirements specification

Task analysis/ functional analysis

Evaluation

Conceptual design/ formal design

Figure 1.10 The star life cycle. (From Hix and Hartson, 1993.)

You will learn more about evaluation in Part 4.

 When and How to Involve Users Users should be involved in every part of the user interface design and development life cycle.

• Early in the design process when the requirements are being specified. Users could help in defining the requirements for the system by contributing a specification or by testing early mockups. Users can get involved by allowing themselves to be observed and giving feedback about the problems of the current system.
• During prototyping, to test designs and options. Users could test versions of the interface to provide feedback and make suggestions to the designers.
• Just before delivery of the product. Users again could test the product by using it or completing surveys about the various features. At this point, however, only minimal changes would be allowable.
• During training/after delivery of the system. Again, users would use the product and give their opinions and detail any problems. Revisions at this stage would be included in the next version.

EXERCISE 1.4 (Allow 10 minutes) Think about the approach you take to software development at work. If this is not applicable to you, think about how you might approach a task like prepar- ing a meal for friends. Think about where you would involve users and where you might work iteratively (that is, where you might repeat steps).

DISCUSSION If I were to prepare a meal for friends, I would certainly involve them by first asking when they could come — there’s no point in cooking a great meal and then asking them whether they are available! I would also consult them in advance over particular food likes and dislikes or perhaps what they would want on the menu. In cooking, there are dozens of things you do repeatedly (or itera- tively): lots of tasting goes on, and we tinker with ingredients until the taste is how we want it. My grandmother owned a restaurant and my father was a chef, so when I make, for example, a sauce for spaghetti or lasagne, it’s an all-day affair. I start with tomatoes and vegetable stock, I add some spices, and then let it simmer (stirring occasionally) before tasting it. Usually it will need more salt or more stock, and once this is added I let it simmer a while longer. Somewhere along the way I add vegetables and meat (if there are no vegetarians dining with us). The sauce is usually just right about five hours later, after lots of iterations to the cooking sauce! Essentially, my approach is no different to that in Figure 1.10 — I design the sauce from my recipe, I test prototypes of the sauce as it simmers, and then I evaluate how good (or not!) it is.

CHAPTER 1 | Introduction

20 Part 1