Try this small exercise: create a functional description for a doorbell. What functions should it have to support the requirements that the users of the doorbell have? To make it a bit more difficult, make it the sort of doorbell for a group of flats that share a front door, with an intercom so you can speak with the person at the door, and the ability to open the door at a distance.
Don’t read any further: it shouldn’t take long to do: what facilities does such a bell-intercom need to support?
Now, while you’re doing that, let me tell you about the programming language C. The designers of the standard definition of C had a bright idea: have a contest for the weirdest program that was still officially OK according to the standard. That should put creative minds to work and help find the dark unexplored corners of the standard. The prize was, if I remember rightly, getting your name in the standard.
OK, time’s up, so what were your requirements? That someone could push a button, and a bell or similar would ring in the house; that the person in the house could speak in the intercom and the two people could talk to each other; that the person in the house could press a button to open the front door. Anything else?
Now I want you to try and consider the weirdest implementation of a doorbell that satisfies your functional description. And while you’re doing that, let me tell you about the doorbell that has been installed where I live.
We used to have a perfectly acceptable doorbell-intercom in our building, but then some people wanted to have video as well, so it got changed. It was only then that I discovered that the doorbell gets used in lots of ways that the designers of the new system hadn’t thought of.
The worst is the parcel delivery person, who presses every bellpush there is, because as long as someone answers, the job’s done.
With our new system, only the owner of the last bell pushed can answer. It happens time and time again. I’m expecting a parcel to be delivered and then I hear the neighbour’s bell go, and then mine. And then another. And then I know that if I’m the only one at home, the only way I’m going to get that parcel is by running down the seven flights of stairs before the deliverer leaves. I usually don’t make it in time.
The next exciting thing that my new bell system doesn’t let me do, is talk to someone at the door, put the intercom phone down, and then think “Oh wait!” and pick the phone up again. However, once I’ve put that phone down the communication is ended, and there’s no way I’m going to get to talk to that person unless they ring the bell again, or I run down seven flights of stairs…
There are two things the old system let us do, that we used to do regularly. One was signal with the bell. “On your way out, will you see if the rubbish has been collected yet? Buzz once for no and twice for yes”. The new system rings the bell like a telephone for 20 seconds, regardless of how many times you press it. No more signalling for us.
The other thing we did was catching each other on the way out: one of us would leave, and the other would think of something important they had to say, so they picked up the intercom phone and waited until they heard sounds at the front door, and then they could yell to attract their attention. No more: unless someone has rung the bell, you can’t talk or listen on the intercom.
OK, time’s up. Did you manage to think up a weirder implementation of the functional specification than the one installed in my house? No I thought not.
I am full of wonderment at the designer of that bell-intercom system: clearly someone whose name should be in the bell-pushers standard.
It has also revealed to me how deceptive functional descriptions can be, and how our interactions with devices live in the fringes of unanticipated possibilities.
© Copyright Steven Pemberton, Amsterdam, 2000. All rights reserved.
First published in ACM/Interactions, May 2000