University was reactivated today, after a mid-semester break that stretched on a full week longer than I had thought plausible when I arrived on campus ready for lectures at the beginning of last week. But this is not the main point of this evening’s symposium.
Among the tidings of the resumed semester was a new lecturer for Human-Computer Interaction, who began his course on usability testing with the example of a program designed to allow architects to walk through a building plan designed by an apprentice and make notes about potential problems. Actually displaying the building was a problem that had already been solved by the people who write 3D computer games, so the main task confronting the designer was figuring out how to make it easy for the architect to move around the building, look at different parts of it, and draw circles around bits that might need some work.
A less enthusiastic designer might have thought at this point that the problems of moving around and looking at things have also had a lot of work done on them by the people who write 3D computer games, and focused their efforts on the drawing-circles bit. And then gone home before lunchtime. But this particular designer was clearly of a Different Breed.
Although I was not privy to the inner thoughts of this designer, the evidence presented suggests that they must have gone something like this:
Question: How can I make using a computer to look at models buildings easy for architects?
Observation: People find things easier if they’re similar to what they normally do anyway.
Theory: Architects would really like it if they could move around and look at buildings on a computer the same way they do it in real life.
Question: How do architects move around and look at buildings?
Observation: I don’t know any architects.
Thought: An architect is a person.
Observation: I am a person.
Theory: Architects would probably do whatever I do when I want to go to a building.
Question: What do I do when I want to go to a building?
Answer: I drive to the building. In a car.
Theory: An architect who wanted to look at a building would drive around it in a car.
Conclusion: The best way for architects to look at buildings on a computer would be to make it like driving around in a car.
Further Conclusion: And it should be as much like a real car as possible, only drawn on a screen.
The result of this presumed thought process was a user interface in which you were supposed to operate an onscreen steering wheel to manouever around a building. Because tablet computers are cool, you were supposed to operate the steering wheel with a pen. To go forward you clicked on the accelerator pedal with a pen. To stop you clicked on the brake. There was, believe it or not, a gear lever with Park, Drive and Reverse. Which you operated by clicking on it with a pen. The circle-drawing part was provided by a pencil on the dashboard.
The fact that this user interface required a major re-think should probably have occurred to the designer when they noticed that their mock-up had relegated the actual building to less than half the screen, and filled the rest of it with car parts. But it did not. There was also no soul-searching reappraisal when user testing revealed that nobody could tell which way the steering wheel was pointing, and everybody ended up driving round and round in circles, unable to effectively look at buildings. Instead, this problem was corrected by adding a little arrow to one side of the steering wheel.
The point at which it really should have become apparent that the whole car metaphor was fundamentally wrong-headed was when it became necessary to provide a way for the architect to move upwards to look at high parts of buildings, and downwards to look at low parts. Except in dangerous situations like driving off cliffs or leaping over shark-filled swimming pools - suituations in which the driver must in any case concentrate on things other than looking at buildings and drawing circles on them - cars are generally known for mostly going along on the ground. Here, surely, the designer must leave aside the car-based interface, thought I.
What actually happened was that the driver added another position to the on-screen gear lever. Park, Drive, Reverse, Fly. After shifting into the Fly gear, you could then operate a second lever with two positions for fly up and fly down. Because when an architect wants to check the guttering on a house, the first thing they do is fly there in their car.
If called upon to critique this user interface, my first thought as a beginner in the field of computer usability would be that its Achilles heel is probably the bit where you fly around in a car operated by pointing at bits of it with a pen. But our lecturer is clearly more sophisticated, and showed us how to apply systematic usability theory to draw our attention to the real weak point. And it was this:
The flying car had no speedometer.
How would the architect know how fast the flying architect car was going in the imaginary computer world? If they flew too fast past the building, they would have trouble drawing circles on it to show the apprentice where an extra window would be needed. Fortunately, saner heads prevailed, and in the final version, the flying pen-operated architect drawing car had a clear, easy-to-read speedometer. It was colour-coded. It went red if you flew too fast.
I learnt so many things today that it is hard to know whether to laugh or weep.
Hmm. Sounds like electric hand syndrome (the first form of car indicator was a cut out hand shape that popped out when you signalled - later it was realised that a flashing light would be a lot better!)
I’d nominate my new mid-range Sony telly for the worst user interface possible. Basically I could not work out, *with the manual* how to use the automatic tune to put the TV channels on the right numbers. Since I have a degree in computer science and 21 years experience using human/machine interfaces, I’d expect that if I can’t work it, no-one can. I suspect it may be cultural, since nearly all the Sony (or indeed other Japanese stuff) I’ve ever used has had an appalling UI.
Just like an electric hand. I suspect that “electric hand syndrome” is so common that the phrase could be used as an all-purpose metaphor in design, in much the same way that Plato’s parable of the people in the cave watching shadows on the wall can be used in philosophy as a metaphor for absolutely anything you want.
What I found surprising was the lack surprise on the part of my fellow students. I don’t drive a car myself, and when I have done I found it rather unpleasant, so perhaps I’m particularly averse to this kind of interface. On the other hand, I enjoy cycling, and I don’t think it would improve matters if the car interface were replaced with a bicycle.
I’ve never found channel-tuning very intuitive on any television I’ve used, but at least that’s a feature that’s seldom used in normal operations. If something has to be confusing, I’d rather it was that than something I use all the time.