1135 words on Books
I had heard about Donald Norman’s book The design of everyday things many times before. But I never bothered to look at it as the title alone suggested that it’ll mainly contain vapid or self-congratulatory remarks by some designer / blogger and would thus be a waste of time.
I couldn’t have been more wrong. The fact that the book was written in 1988 - before bloggers even knew they’d go by that name - should have been a hint. And, according to the foreword added to the 2002 edition, the book was originally published with the title The psychology of everyday things. A title which reflects the book’s content more correctly but also led to it be shelved wrongly and thus selling poorly. Even though the new title put me off, I can see the point of that title change. As it is concerned with design, the book shouldn’t be waiting for buyers in the psychology section of a bookstore.
And Mr Norman presses all the right keys for me. He stresses that many mistakes are caused by the design not just permitting but encourageing them and he manages to illustrate that with (a few) surprisingly simple examples. Everybody knows that telephone systems or VCRs are proverbially hard to use…
in my experience that’s only semi-true, btw, but I only used 1990s VCRs with on screen displays, something that probably didn’t exist when the book was written. The VCRs I know aren’t wondrously simple to use and things like daylight savings time can be a real problem with them but they are reasonably easy to program and my own will even automatically tune into stations and set its clock - a fact which my flatmates amusingly still haven’t discovered although the button for the auto-tuning is one of the few buttons on the machine’s front.
… but what about door handles and doors, water taps or running into a set of light switches with no clue about which one is connected to which lights? A few of them are well designed while others aren’t. And the latter one are quite common and frustrating to use.
The book discusses the actions people take and how those work. It highlights how a user’s memory plays a role in performing tasks and how a good design can aid people using it. It is stressed many times that prettiness isn’t the objective of this exercise. A huge smooth wall may look great. But if it’s actually a wardrobe and you can’t tell that it has openable doors, it’s a usability failure.
The examples given in the book are good - particularly as they are traditional ‘hardware’ examples rather than the software examples we see so many of these days. I did find, however, that many of them were very simple. On the one hand that drives home the point that even very simple tools can end up being very poorly designed. On the other hand it makes you wonder what examples for well executed designs of very complex things are. Do they even exist?
Being the destructive person that I am I rather enjoyed the bits given on destructive testing around page 141. I tend to run into many problems when using software. And usually I don’t even need to try hard to do that. Perhaps that’s just because I’m more observant than other people or because I find it easier to blame the software for things going wrong where others blame themselves or perhaps it’s just bad luck (I should really try to capitalise on that and rent myself out as a tester…). And just occasionally, when too many failures have happened, I enjoy abusing things.
For example it has always been agonising to accidentally drag a huge text file on Cocoa applications on the Mac. Endless stalls and unreasonable memory consumption usually followed that, with cursing at the computer following a little later. Guess how delighted I was when my Pavlovian bitching reflexes were already triggering in a similar situation in Mac OS X.5 but I realised that TextEdit had been improved to behave much better in such situations. Of course I had to stress test other Cocoa editors after this (the results of which were a bit disappointing).
Something everybody programming computers should read is the section on page 178f. With a good sense of irony it recommends to
Make things invisible […] Be arbitrary […] Be inconsistent […] Make options unintelligible […] Be impolite […] Make operations dangerous […] - and I’m pretty sure that even today’s computer users may find those approaches in software shockingly familiar.
One thing in the book I really couldn’t agree with, though, is the discussion of a stove on pages 75ff. Perhaps American homes are just that huge or Mr Norman is just that rich that these things don’t matter for him, but the discussion in the book suggests that the arrangement of controls for the burners on a stove in a row is downright stupid. While the examples he gives as improvements certainly illustrate a point, they conveniently ignore many practical limitations of setting up a stove. The first is space. Usually 60cm by 60cm will have to do. On that area you can just fit four burners in a way that lets you use two large pans and two small pots at the same time. There won’t be any space left to put the controls on top.
Particularly so, if you take into account that you want the controls to be large enough to be handled easily while cooking, possibly with wet or greasy fingers. They should also give haptic feedback at the same time. I don’t think you’d want to have you stove controls too close to the burners or the hot pots on them - that’d be an accident waiting to happen. And if you can’t arrange the controls horizontally, you’ll have to go vertical. I have seen a stove where they were they put the controls on a vertical thing they raised at the back of the stove - which seemed immensely stupid as you always had to reach through the hot steam and whatever else might be coming from your pots and pans to reach them. What remains is putting the controls at the front of the stove. And there you simply want them to be as high as possible, so people can still reach them while standing upright. Making the design more ‘natural’ by putting some of the controls further down would spoil that (and quite likely collide with the door of the oven beneath the stove). It would have been interesting to see a solution for that stove problem in the realistic situation with space constraints. A solution that would work in practice.
He’s great. I mentioned him the other day; If you haven’t heard yet, you should probably follow this: http://www.objectifiedfilm.com/blog/lets-get-objectified/
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.