June 2010 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material June 2010 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
In the first unit we aimed to have persuaded you that there is a problem with interactive systems, namely that they are difficult to use. In this unit we have described arguments that this problem is substantive, that systems that are difficult to use are unproductive, unethical, and maybe even illegal. In the next unit we will start to lay out procedures for designing systems that are easy to use, to alleviate the problem that exists. One question remains in this section: if lack of usability is a problem and procedures exist to improve usability, why are they not already used?
There is not a single answer to this, but a single, simple factor pervades the arguments that follow: software engineering produces products that need to sold on the open market, so if products generally are not usable then there is a lack of demand in the market place for usability. Free market economics dictate that if there is a need that can be fulfilled profitably then someone, somewhere will be fulfilling that need. I could present a detailed, careful argument as to why the word processor on which I am typing this unit is much less than usable, but I, like millions of others, have purchased the word processor as a product over other word processors. I have therefore sent an economic signal to the word processor's developers that I approve of their product. I do not, and neither do any of my colleagues, but we still bought it. Simple economic models do not seem to apply in the purchase of computer software.
We look at several reasons for the failure of the market to produce usable software. None are conclusive, or have a great amount of evidence behind them, but they go some way to explaining the phenomenon.
Alan Cooper describes a lot of high tech equipment as being like watching a dancing bear. Dancing bears were a popular recreation in the past, a sort of circus attraction. The owner of a trained bear travelled from town to town showing the bear to the inhabitants who would come and stare in fascination at the bear who cavorted and stumbled about in time to music. Everyone was so dazzled by the fact that a bear was dancing, no-one particularly bothered about the fact that the bear did not dance very well.
Technology is analogous; it can perform such amazing feats that we tend not to notice that the way it performs those feats is not very good. On the market there are (quite expensive) 3D modelling package that can produce some quite incredible, beautiful images. However the procedures that the user has to go through to get the package to produce those images are arduous and it is likely that they could be made much easier. But the images it produces are so good users are willing to suspend their displeasure at the interface and interaction problems in order to get to those images. But they have paid money for the system, and by the laws of free market economics, they have sent a signal to the developers of the package that they approve of their package.
It is important to be able to see through what Cooper describes as ‘dancing bearware', to not be so dazzled by the output of interactive system that we do not notice that the process of getting to that output is sub-standard.
Many people enjoy jigsaw puzzles: large pictures chopped up into little pieces which need to be reassembled. If a Martian were to conduct a usability analysis of a jigsaw puzzle then they would most likely conclude that jigsaw puzzles were utterly bizarre. The process (reassembling the pieces) of getting to the product (the complete picture) is ridiculously difficult. If people want big pictures why cut them up in the first place? The thing is, people like challenges; to be offered a task that is difficult, but with some effort is possible to complete. Jigsaw puzzles show this quality, they are difficult, but not impossible and the sense of satisfaction of completing a jigsaw puzzle is considerable.
A lot of computer software shows the same qualities as jigsaw puzzles; it is possible to achieve your goals with certain pieces of software, but it just may be very difficult. There is something in human nature that quite enjoys this challenge. Video recorders are notoriously difficult to program to record programs in advance, but the sense of satisfaction in getting them programmed and the right TV shows recorded can be considerable.
A lot of computer software shows the same qualities as jigsaw puzzles; it is possible to achieve your goals with certain pieces of software, but it just may be very difficult. There is something in human nature that quite enjoys this challenge. Video recorders are notoriously difficult to program to record programs in advance, but the sense of satisfaction in getting them programmed and the right TV shows recorded can be considerable.
Improving usability would reduce the jigsaw puzzle factor in technology and disenfranchise the office guru.
Programmers produce software. What is important to programmers is designing algorithms that deal with tricky technological issues. This sort of problem solving is highly skilled and crucial to building software. But what programmers are not necessarily skilled in is designing solutions to users' problems. This is a different, crucial, but neglected skill in system development. Much software shows signs of not being designed to solve the problems of users, but being designed to solve programmers' problems, and what is important to programmers is not necessarily important to users. Users do not care what language their word processor is developed in so long as it works, just as they do not care about the mortar that holds the walls of their house together so long as they do not fall down. This is not to decry the necessity of building word processors in an appropriate language, or the necessity of making decisions about the composition of mortar in walls, but a user and house holder should not need to know or care about them.
We do not expect brick layers to design houses, that is not their expertise, we expect architects to design and brick layers to build. Architects and brick layers have different, complementary and crucial skills.
Possibly because of the immaturity of software engineering as a discipline (it is at most forty years old, architecture is several millennia old) so far the brick layers have run the show, without bringing in the skills of architects. There are several more reasons for why there is inertia to change this way of producing software detailed in Cooper (1995).
Technology based system support is strangely arrogant and critical of its users. Many Usenet groups are set up to discuss certain pieces of technology. Many times novice users post questions to such groups only to receive curt responses telling them to go and read the manual. Such an attitude to users is a disgrace, but very prevalent. It belittles users and makes them feel stupid, they are therefore less likely to complain about bad software because they are more likely to attribute failure to their own imagined stupidity than to the software.
There is a maxim that there is no such thing as a bad child, only bad parents. In the same way there should be a maxim that there is no such thing as stupid users, only stupid software. However an arrogant culture is very resistant to such a maxim and will act to ensure that users still feel inadequate and blame themselves for failure, rather than blaming the software developers.
The correct response to told to read the manual to tell the developers to write the software so that users do not have to read the manual.
There exists an interesting psychological phenomenon known as ‘cognitive dissonance', which pops up in many areas of human behaviour. An interesting aspect of cognitive dissonance theory states that if someone does something illogical once then they are likely to repeat this action. This is because we do not like to think of ourselves as irrational people, so if we do something irrational we will try to convince ourselves that doing it is actually not all that illogical. Therefore we may repeat the action to keep convincing ourselves of its rationality.
Purchasing computer software shows many of the characteristics of cognitive dissonance. We buy badly designed systems once (because we have little choice not to), realise that we have bought a dud but try to convince ourselves otherwise by buying more bad software. Buying software is a strange process; it can be very expensive, but has little physical presence. If you spend a thousand pounds on books you will get a satisfying large stack of books to put on your bookshelf. If you spend a thousand pounds on software you may get a single CD-ROM or even just a password so that you can download the software off the Internet. This unreality and lack of tangibility in buying software may add to the cognitive dissonance effect.
Explain why ‘buyer beware' is not an adequate or appropriate maxim for computer software products.
Answer to this question can be found at the end of the chapter.
Now we look in detail at the web browsers you are using to accomplish the tasks you set yourself activity 6. Web browser software has many functions associated with it. Accessing these functions may be a case of pressing the buttons along the top of the browser or selecting options from the menus. Write down each of these functions on a piece of paper, systematically going through each of the menu options and buttons on the browser. Spend a couple of minutes on each function, writing down the name of the function and what it does. Try to explain what each function does carefully and clearly. For example, do not just say that the ‘Save' function saves things to disk, try to explain what it saves, in what format and to where. If you do not understand what a function does investigate it for a couple of minutes and see if you can get a better idea. If not, write down ‘Not understood' next to that function. Do not use the help facility to find out what a function does.
Now let us just stand back for a moment and look at what we have done. We are, if you have not guessed already conducting a user centred analysis on web surfing. Activities 2, 4, 6 and 7 are the data collection steps. We have collected opinions about what the web is, what it is or is not good for, what sort of behaviours users employ when looking around the web and we have made some explicit recordings of those sort of behaviours. We have done all the from the user's point of view. We have not concerned ourselves with technical issues like TCP/IP or operating systems. From the user's point of view these issues should be irrelevant.
In the next unit we are going to analyse the data we have collected and suggest some redesigns to web browsers so that they match better what users actually want to do.
At this stage it is a good idea to reflect on what you have done so far, and think about the browser you have been using. Does it allow you to do everything you wanted to do? Or did you find that it got in the way sometimes? Did you feel that you were interacting with the web or with the browser? This distinction is crucial: a good web browser should not make its presence felt. Think of a television; a usable television allows you to watch programs without particularly worrying about the technology in the set which brings the pictures to you. You should be watching television programs not the televisions themselves. In the same way you should feel that you are interacting with the web, not with the web browser. Have a think about this and make notes about your interactions so far; describe the good interactions where you found what you wanted quickly and easily, and he bad interactions where you felt that you were chasing your tail. Try and explain why you felt this.