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 later units we will deal in considerable detail with modeling techniques, but we shall give an overview and introduction here. Generally models are approximations of real world artefacts which can be analysed. A good model is one which fairly accurately predicts the behaviour of the real world artefact it represents while doing away with a lot of the confusing complexity. Models are therefore tools for ‘abstraction’. What is important for an analyst using a modeling technique is that it abstracts away the irrelevancies and keeps the important facts. A model that does so it called ‘well scoped’, it is up to the analyst to chose a modeling techniques that is well scoped for the questions they want to ask of it.
A task analysis technique makes a model of the job that a user is expected to perform. Analysis techniques can be applied to those models in order to determine such facts as how long it may take users to perform given tasks, or how much ‘cognitive load’ is placed on the user (where ‘cognitive load’ is broadly a measure of much information the user needs to remember).
The most researched task analysis technique is GOMS (Goals, Operations, Methods and Selection) developed by Card et al (1983). The analysts describes:
the user’s goals, or the things that user wants to achieve,
the operations, or the things the user can do, perhaps such things as thinking or looking, or maybe selecting items from computer menus, typing or pointing with the mouse,
the methods, which are sequences of operations that achieve a goal, and
selections, which describe how the user may choose between different methods for achieving the same goal.
Once this model of the user’s task has been compiled then measurements of the time it takes to perform the operations can be added (these measurements are taken from empirical observations of users) and a prediction of the time it will take the user to perform a task can be calculated.
GOMS only really deals with expert behaviour though and takes no account of the user making errors. It has been argued that a surprisingly large amount of user time is spent making, or recovering from, errors, even for expert users. Therefore the accuracy of GOMS models have been questioned.
GOMS analysts scored a notable victory however when they accurately predicted that users of a new computerised telephone system would take longer to perform their tasks than users using an older, apparently slower system (Gray, John and Atwood. 1993).
Whereas task analysis aims to model the jobs that users do, user modelling aims to capture the properties of users. User models can capture and predict properties such as the way the user constructs goals, how users make plans to carry out those goals, the users’ ability to do several tasks at once, how the user manages perception, etc. Such models are based to a large extent on psychological theory, which in turn is based on empirical evidence.
Typically the analyst builds a model of the interactive device that is intended to be built and then integrates this device model with an existing user model. This integrated model will be able to predict certain behaviours, and the analyst can therefore gain an idea as to whether the user will be able to reasonable perform the tasks that the analyst wants them to.
Several techniques have taken existing software specifications and analysed them ‘from the users’ point of view’. In other words the analyst takes a model of the interactive device, which is typically produced as part of the design process, and analyses it for ‘usability properties’. A lot of work went into proposing usability properties and then formalising mathematical equivalents of them. In this way software specifications could be mathematically analysed for usability in much the same way as they can be analysed for functional correctness.
Dix’s PIE model (Dix 1991) is a classic example of interactive device modelling. The device is modelled as a collection of states with allowable transitions between them. This model can then analysed mathematically for such properties as ‘reachability’; the ability of the user to get from such state to any other allowable device state. Dix also formalised what it means for a system to be so called ‘WYSIWYG’ (what you see is what you get) by separating the displayed output from the printed output in his model and mathematically showing correspondences between the two.
As we explained above, models must be used with care. Because they abstract details away the analyst must understand what is being abstracted away and be able to argue why those details are not important. Furthermore modeling is seen as a highly skilled and time consuming activity. The idea of modeling is to be able to predict usability issues before a system is built, but many developers have the impression that modeling can be so complicated and highly skilled that it is cheaper to just build the system and then test it on users. Refutations to this are rare, but compelling (e.g. the GOMS analysis of the phone system we alluded to above). We will return to these issues in much more depth in subsequent units.
Activity 5 winds up the web browser analysis and redesign process by discussing what we have done. Consider my redesign for the web browser, along with your redesign, and the original design of the browser and compare all three. When there are differences between the three try to argue which is the best' and, most importantly, why it is the best. Use the evidence you gathered in unit 2.
If the original design of the web browser is not good, try and think of why this may be. The designers working at Netscape and Microsoft are not stupid and do not inflict bad designs on their users wilfully, but if something has gone wrong with their design then there must be a reason for this. Hopefully we have developed designs for web browsers that are user centred, if Netscape and Microsoft come up with different designs then this means that they may be working with different priorities we are in this tutorial. What are those priorities, and why do they take precedence over usability. Consider the arguments about feature accretion we discussed in the Contents notes. Do Netscape's and Microsoft's products show signs of feature accretion? If so, why? And do you consider this to be a bad thing? Why?
You will be invited to discuss your analysis in the discussion section.
A discussion on this activity can be found at the end of the chapter.