 |
case study |
|
 |
|
Car courtesy lights - designing incidental interaction |
|
|
|||||
|
||||||
|
||||||
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
see page 655. Design Focus: Designing a car courtesy lightDifferent car courtesy lights operate in different ways, but typically they turn on when you unlock or open the door and then off again after a short time or when you start the car. The design will typically bean ad hoc afair based on previous cars, but for more complex sensor-based interactions a more systematic approach is needed. This case study is not based on the design of any real car, but instead shows how a more principled approach to the design of sensor-based interaction could take place. Stage 1 - identify inputs and outputsFirst stage is to identify the sensor readings or other information available to us ansd also what we would like to control. In this case we have the following:
These lists are themselves points for discussion. We may be able to access more sensors to give us more information. For example, in a car with ABS there are wheel sensors to detect the speed of movement, this could be used to give a 'car moving' indication in addition to the ignition's 'engine running'. Many cars also have alarm systems and this might also be used to give an indication of whether people are in the car. We may even decide to add new sensors perhaps a weight sensor in the drivers seat to see if the driver is there. The rehetoric of usability of course would say that the desired output comes from an analysis of user needs. Often the reality is that there are certain things available and we are deciding what we can do with them! Stage 2 - understand the tasksNext we need to try to understand what the user is doing and what light is required or desired at each step. To do this we have taken a scenario of someone getting into a car and labelled each step with +'s if light is wanted and –'s if it isn't. More +'s mean it is more important that the ligfht is on, more –'s mean it is more important that the light is off. 0 means don't care!
Looking at a few of the steps ... Step 3 has been give one – as the internal light may make it slightly harder to feel for the keyhole on the outside. Step 5 has been give two +'s as the internal light helps stop you triping as you get in. Step 8 similarly is given two +'s as it helps, to have the light on to find the road map, and step 9 gets +++ as it is impossible to read the map without light! Step 2 always causes some discussion. I always think it makies it easier to find your car in a dark car park if the light comes on, but soem people think that having the light turn on makes it obvious to a mugger that you are about to get into a car. Most cars do turn on courtesy lights at this point, but perhaps they shouldn't? Step 15 has been given lots of –'s as it is absolutely essential to have the light off when you set off. I used to think this was illegal in the UK, but in fact it is just not recommended as it is hard to drive at nifght with an interior ligt on. Perhaps it is illegal elsewhere ... anyone know?? Note that with the exception of steps 9 and 15 all the ratings are of the 'it would be nice if' rather than 'it must be'. This is a big difference between design for sensor-based systems and 'normal' GUI deisgn. With a desktop product of you press a button you expect the right thing to happen. There is not doubt that you pressed the key and the assumption is that you knew why you did it and wanted something the happen. With a sensor-based system the sensor readings and the inferences you make from them are likely to be incomplete and often innacurate. A speciofication that labelled each step with an unambiguous On/Off for the lights would not be realisable and furthermore would mean we wouldn't have any sense of the relative costs of different errors. At this stage we caouild move on to another scenarion - perhaps someone arriving home form shopping and unloading the car. We can nthen either take these labelled scenarios forward to the next stage, or make a more complete task description using a HTA or something similar and usen the scenarios as a guide to label the lowest level tasks in the task hierarchy. Stage 3 - model the systemOf course the system can't know exactly what people are doing, but can make some guess at to the current state of the car+people system. This state transition network shows oem of the main states of the car_people system (a fuller description might distinguish passengers and driver in the car, or people approaching the car, but then it wouldn't fit easily in the web page!).
Given this picture we can label the transitions with times and transition probabilities. We can use the scenarios and task descriptions to guide us here e.g. there is greater likelihood that if you have just opened and closed the car door yuou got into it rather than just did it an went away again. Note to do this we may want to distinguish the states when people are in the car after finishing a joutney from the ones before the journey starts, or have transitions whose probabilities depend on history. Stage 4 - design the effectsTaking this probabilistic STN we can then:
Note both (1) and (2) may make us re-evaluate the STN and perhaps add extra states to clarify it. We can now put these together to work out what the light should do in each detectable satte of the car. The combination of the different tasks corresponding to a single state noted above and also the uncertainty about what the actual state of the car+people system is means that for any detectable state we have a probabilty of each car+people state and potentially several labellings of those states. Where there are many +'s or –'s for a state we need to ensure that the light is definitely as required (e.g. 80% +, 20% ––––– would still mean we would keep the light off). If there is a clear 'winner' for a detectable state then we know what to do (e.g. if we have +++ 20%, – 40%, ++ 40% then clearly the +'s win). If we cannot be sure enough because of uncertainties then we may have to introduce additional explicit controls. This is also the case if a single state has strong conflicting requirements (both ++++ and ––––), for example, if lost your passenger may explicitly turn on the light to read the map (+++) whilst driving (–––––).
Alan Dix © 2004/2006 |
|
