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 | |
Previously we discussed legal requirements for usability. Prior to legislating the requirements stated in law are usually tried and tested as ‘standards'. A standard is a collection of guidelines which suggest features which should be designed in or out of a system. They may also suggest performance criteria against which a system can be tested . Once a system has been shown to meet all the requirements placed down in a set of standards then it can be certified as having reached that set of standards.
Standards are set by a wide collaborative process, where many researchers and developers discuss what the goal of a set of standards is, and which guidelines, if met, would actually mean that the system in question met that goal.
Industry has an especial interest in standards. If their products can be shown to met a certain standard then this is a positive selling point for their products. Also if a standard does progress into law then it is imperative for an industry that their products fulfil that standard, and it is best to develop a product keeping a standard in mind that has the potential to pass into law. If the standard becomes law then the product should require little or no work to make it legal.
Because industry has such an interest in standards then it is common industry practice to try and influence standards as they emerge. Industry practitioners sit on standards panels and will attempt to steer standards towards their own products. While this practice may seem a bit unethical it ensures a lively debate about what should be put in standards and also means that industry has to come up with good, explicit reasons as why they develop their products in the way they do. Rather than trying to make up good justifications for a bad product, it is easier in the long run to develop a good product. Also it is important to ensure that the standards procedure is not entirely lead by ‘big players' in industry and that small developers and businesses also have their say.
‘Non-partisan' people from academia and government will also be part of standards panels in order to ensure that the standards set actually challenge industry to improve their products, not just rubber stamp what they do already. But it is also the job of industry to argue that the guidelines and goals suggested by academics are actually practicable.
The development of standards can sometimes require considerable negotiation. Such negotiation is a good thing, because it opens up current design procedures to scrutiny and sets developers goals which may be more than just to develop a product to make as much money as possible.
For a standard to work, however, it must be taken up by developers. The ultimate aim of a standard is to become recognised by consumers, so that they explicitly ask for products which conform to that standard, and also for there to be lively competition between developers to produce products which meet a given set of standards. Standards fall in to disuse, or never get used in the first place, if they are felt to be irrelevant or impossible to implement.
ISO standard 9241 describes in part specifying systems for usability. It gives the following definitions:
Usability: the effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.
Effectiveness: The accuracy and completeness with which specified users can achieve specified goals in particular environments.
Efficiency: The resources expended in relation to the accuracy and completeness of goals achieved.
Satisfaction: The comfort and acceptability of the work system to its users and other people affected by the system.
This is a rare example of a usability standard. It describes what ‘usability' is: a combination of factors, effectiveness, efficiency and satisfaction. Each of these are then sub-defined. This process of breaking a definition down into smaller more quantifiable units is popular, but contentious. This reductionist principle means that there is a possibility that an analyst can see and thoroughly measure the trees, but completely miss the wood itself.
Standards for usability are rare, vague and not well developed. The need for such standards is acute however. Many high tech products make claims to be ‘user-friendly', and try to gain a market advantage on the strength of such claims. But in many cases it is not clear where the rationale for such claims comes from. As we discussed earlier implementing ‘user friendly' features is not enough. To be genuinely user friendly there should be arguments and evidence as to why features are user friendly.
The above figures show two controls for in-car stereos. The first is an old fashioned system, with separate dials to control the volume, tone and tuning. The second is a more modern design. It has a menu selection controlled by the two ‘up' and ‘down' buttons and a single dial to set a value. So, to set the volume the user should press ‘up' or ‘down' until Volume is highlighted and then turn the dial to set the appropriate value. A graphic representation of the volume setting is shown on the LCD display.
Draw up two columns, one for each stereo design and write down as many pros and cons for each design as possible. When you have done this weigh up which is the better design from the user's view point. Which one is likely to sell more? Why?
There are several standards set for hardware both by the BSI (British Standards Institute) and the ISO (International Organisation for Standardisation), but few for software. This is because standards for hardware are based on physiology and ergonomics; fields which are more developed and mature than psychology and HCI. Hence specific guidelines can be set that will improve the quality of hardware designs.
Because of the less well formed basis of HCI it is more difficult to set specific guidelines and be assured that such guidelines will result in improved usability. Also hardware is less flexible than software and therefore it is easier to set stable guidelines for the design of hardware.
Standards for usability will emerge as HCI becomes more mature, just as standards for more ergonomic hardware emerged with the maturation of ergonomics. In the mean time experimental guidelines will emerge in the form of draft standards, which may be vague and unspecific, but at least point in the right direction. Standards are important; in their absence developers will be able to ‘get away' with vague and untested claims about their products.
So far we have purposely not touched a computer, instead we have tried to think about and explain web surfing independent of the nuts and bolts of mouse clicks and web browsers. Now we will start to look at actual behaviour.
Given the descriptions of behaviour we produced in activity 4 we now want to generate actual examples of that sort of behaviour. Set yourself a task that will involve you performing in the ways set out in activity 4.
But we need to record how you actually do this. Ideally you should record yourself doing this, if you have a video camera, excellent, if not try a tape recorder and describe out loud what you are doing as you do it. Other ways of recording yourself is to get a friend to watch you and write down what you do as you do it. If all these procedures are impossible then you must try to remember exactly what you did and write it down immediately after you have completed the task. (Question: why do think it is a bad idea to write down what you do as you do it?) It is important that you have a fairly accurate record of how you surfed the web to analyse later. Try to use either Mozilla Firefox or Microsoft Internet Explorer for your tasks. They can be downloaded freely from the Mozilla or Microsoft web-sites.
I described searching and browsing in activity 2, so set yourself two tasks that will get you to behave in those ways. For example in order to get yourself to search for a page, if you have not already done so, search out and read the recommended paper ‘Beyond the productivity paradox' from the ACM digital library web site. Alternatively, if you have already done this see if you can find and read Gary Marsden's curriculum vitae from his web pages (he is a member of staff in the University of Cape Town's Computer Science Department. Start off at the University of Cape Town's Computer Science Department.
Now set yourself a browsing task. Try and find a web site dedicated to something or someone you are interested in that you have not looked at before. The web is rife with fan sites for film and pop stars; try to find fan sites for your favourites. Do not stop when you have found one site, most famous people have several sites in their honour, try and find three or four. Again make sure that you are accurately recording how you do this while you do it.
These tasks relate to the behaviours I outlined in activity 4. You should have outlined your own behaviours too. Think up tasks related to your described behaviours and record yourself performing them. Try and be creative, for example I sometimes find that I search and browse simultaneously. A task that conforms to this would be to get several curriculum vitae of UCT staff on screen at once. You will need to launch several browser windows or tabs at once to do this. Also not all members of staff have their curriculum vitae on-line, or indeed have web pages. While you know what you are looking for you will need to browse around the Computer Science web pages looking for what you want.
Set yourself about four tasks and spend a maximum of quarter of an hour on each one, do not worry if you fail to complete a task, in fact failure to complete a task is interesting for analysis. Write out the description of what you did during each task and keep it together with the descriptions from activity 4 that it relates to.