Editoral: Rise of the Machines

I’ve not been having a good run of luck with machines. I almost feel like they’re out to get me, but that is taking anthropomorphisation too far and they’d hate that.

First the oven broke. Fortunately it was just the heating element that needed replacing, but it still took the engineer three tries over a week or so to get the right part as there were several possible ones, all with subtly different attaching holes and all incompatible.

Then I was awoken at 3:30am by water dripping through the ceiling. Turns out the water tank was leaking, and after a few goes trying to fix, I was told that the whole cold water system needed replacing – apparently the ex-councellor who’d owned the house in the 1970s had used it to showcase local businesses, and all the piping was made by a local company ... but only for a year or so. It had never caught on as the acrylic pipes needed gluing together, which meant you couldn’t test them for 24 hours, and were pretty much impossible to repair piecemeal. Plus, since then standard sizes have changed and you can’t get compatible parts. Given the size of the job I’m getting the bathroom redone at the same time, and so am looking at options, in particular which shower to have put in.

Then this weekend I came home to find a washing machine full of undrained dirty water, with a couple of arbitary lights flashing.

What do these have in common? Well, I’ve got around to reading Donald A. Norman’s classic book The Design Of Everyday Things [ Norman ] so have been thinking about how bad much of design is, including physical objects, electrical devices, and user interfaces. And I realised that my rebellious machines showed various aspects of his ideas, good and bad, and that many of them have lessons that can be applied to software.

So let’s look at my examples in more depth.

An oven heating element is remarkably simple. It’s just a heavy spiral of metal that attaches to the electrics, and which, due to its high resistance, heats up. It connect to a circuit controlled via a thermostat and the user’s controls on the face panel, and is held in place with a central screw. Unfortunately the usual element for that make has two screw holes on either side, and so couldn’t be attached. A note was made of the model, and after some searching online a new one was ordered – to find that it wasn’t quite the right one, which didn’t fit either. Finally the correct one was found, and installed in minutes.

What can be learnt here? First is to ask why on earth are there different fittings? It is surely simple to standardise on a single connector, or have a ‘universal’ bracket that has the right holes for any oven’s need, perhaps with two outer holes as well as a central. Having said that, there could be a safety aspect – you wouldn’t want to install an element that couldn’t cope with the current the oven would deliver. A good solution to that is actually to have different connection types for the different power ratings so that you cannot possibly install the wrong type. But why did the wrong one get ordered? Well the types only differed in subtle ways that were missed when searching. So here is another lesson: make the differences obvious , perhaps via the number of rings, or the connection orientation, or even colour coding of the insulation. As it was they all looked the same.

As for the water system, one problem I found was knowing which bits were what, what each valve did, and where did all these pipes go as they usually disappeared under insulation or through the floor. What would have made things easier would be to have put simple labels on the pipes detailing their purpose, and perhaps even their measurements. When I get the system replaced I’ll be adding them. Another idea I got from Stewart Brand’s How Buildings Learn [ Brand ] is, before you hide the utilities behind walls, plaster etc, take photos and put them in a book. The book stays with the house, and forms a record of the hidden anatomy of the place, and will become invaluable to yourself and any future owners and maintainers. And of course, as the pipes and shower are going to be boxed in, I’ll make sure there’s some way of access for maintenence.

In contrast the washing machine is a bit more of a success story, but there are still lessons to be learnt. In contrast to most models with their enormous number of controls, dials and displays, which are so complicated that you tend to learn one or two common settings and never use the rest, this one has gone for a very simple but useful set. See Figure 1. It comprises an outer ring of five buttons – one power with embedded red ‘locked’ LED , and four wash types, all of which have simple logos and temperature, and are back illuminated; an inner ring of LEDs; and a central logo. To start a wash, press the power button and the LEDs will light up one by one and a short tune indicates it booting quickly. What next? It prompts by having the wash buttons’ lights gently fading on and off. Then press your chosen wash button, and that’s it! Two presses – that’s all that’s needed to start one of the six wash types. Ooops, yes you spotted it....four buttons, six types. Why did they spoil the simplicity of the single buttons? How can I remember how to do the others? They do redeem themselves partly by having an aide memoire of the types and the button presses needed on a little panel when you open the door to put the washing in. And one of the types – rinse only – is detected automatically by sensing detergent on the clothes at the start. But a mark lost for overloading the buttons for the last two.

Figure 1

As the cycle progresses, the LEDs light up one by one giving a simple indicator of how long is left, spoilt only by the possibility of multiple rinses making the last few significantly longer than the others – thankfully it’s not as wildly inaccurate as the Windows progress dialog. Completion is indicated by a long beep, and in case you miss that the LEDs fade on and off to show it’s finished, which really stands out in a dark room.

What if you want to cancel it? Just hold the power button till it beeps and starts to flash. Notice you have to hold it, otherwise you could cancel by accident. Would have been even better if it gave some feedback while you held it to show you were doing something correct, perhaps beeping repeatedly (but not rapidly – that might make you think it was an incorrect action), but holding a power button to turn off is a pretty common convention.

The only other thing that’s wrong I spotted when the engineer came to look at it. If you noticed, the logo of the make is a play on the standard symbol for a power button, and as it’s also curved to stand out, quite sensibly that was the first button he pressed to switch it on. An improvement might have been to actually make that the power button.

So here we have a fairly clean, simple user interface, with obvious options for the day-to-day things, a reminder of the less obvious, and useful feedback without information overload. Why can’t more devices be made this useable?

And not just physical devices – these examples have their counterparts in the world of software. For example, the popular distributed source control system, git, seems to cause new users some confusion. The example, as I understand it, involves some of the defaults – when you do the basic git pull to get code, it gets only your current branch. But when you git push , it pushes all your changes, including ones on other branches, to the repository. Why the unexpected difference? It gets worse – if there is a conflict on a different branch, it prevents you pushing, in a hard to fathom way. Sure you can get used to these, but choosing good defaults would be better. What sort of defaults? Well, ones that do the most obvious thing given the rest of the context, and causes least damage if invoked unexpectedly. In this case I’d say the best is to push/pull only the current, and provide explicit options to provide a list, or all. This is a bit like having sockets compatible only for safe things – make it obvious to do the right, safe thing, but hard work (or impossible) to do anything stupid or unsafe.

This principle applies to tools, but also to API design. For example, consider a function that returns a raw pointer. What is its lifetime? Do you own it? How do you release it? You could document this, but that’s the equivalent of those thick appliance manuals that you never read. Instead (or on top of the harder to use API), encapsulate the ownership rules in a smart pointer. Perhaps allow a ‘checked’ mode to detect incorrect usage, so long as performance doesn’t suffer unduly. If there is an order of calls required, make the orders obvious, perhaps by passing a token or object back from one that needs to be passed to the next.

Similar ideas also apply to user interface design – make the obvious things easy, and provide ways to recover from unexpected things, perhaps with an undo facility. Also avoid mistakes in the first place by providing clear feedback and indicators of what can be done next.

And, topically, security can learn from some of these principles. For example, if you provide a voicemail facility, it could be a good idea to have it disabled by default. If it’s on, by default only allow access from the phone itself. Or allow only from known authorised numbers. And if from anywhere, do not have a default password/pin, but force one, perhaps with checks to discourage obvious ones such as 1234 or part of the phone’s own number. If such simple measures were in place, we might be a rather different world...

References

[Brand] http://en.wikipedia.org/wiki/How_Buildings_Learn

[Norman] http://www.jnd.org/books.html#33