I’m currently reading Walter Isaacson’s biography of Steve Jobs. There is a chapter in there which describes Apple’s visit to Xerox PARC where they discovered the marvellous new concept of the desktop metaphor for a graphical user interface (GUI). The general idea was if the computer screen could mimic a real, physical environment, it would be more intuitive to use.
Now while I’ve not seen a lot of buttons on real desks, they are nevertheless real objects. You find them on phones, on appliances, on remote controls and in lifts (elevators for you Americans). So the concept of pushing a button to the point at which it engages some function – a dial tone for instance – is fairly straight forward.
In recent years, however, I have discovered an annoying trait of some button hardware, principally in lifts. You see, when you push that button, two things happen. Your floor is selected so that the lift control system knows where to send the lift and a light comes on which hopefully signals you that the selection has been made. But not always.
In some lifts I have been repeatedly surprised by a button that lights up, but does not select the floor and indeed does not stay lit! My muscle memory for pushing a lift button is to stab at it with my finger and wait to see a light. I only need a few milliseconds of light before my attention falls away and my mind tells me the floor is selected. Sometimes I glance back at the button to discover it is not lit. Indeed sometimes this is prompted by the inaction of the lift itself.
I figure there are two electrical circuits involved. One to light up the button as simply as a light switch and one to signal the selection to the control software. The latter action then feeding back that the button should remain lit. By hitting the button too lightly or too momentarily, I believe I am only engaging the first function.
As a programmer, this behaviour annoys the hell out of me. It’s not deterministic from the user’s point of view and, well, why are these two functions disparate? It makes no sense at all. What is the point of lighting up a button merely to reflect that I pushed it? It sounds like a scene from The Hitchhiker’s Guide To The Galaxy. (It could at least admonish me to not push the button again.)
But at least when we return to the desktop metaphor, this kind of non-deterministic behaviour is not a problem, right? Wrong! Microsoft Windows XP, bless its little cotton socks, does exactly the same thing!
I don’t see it often, but I saw it again today. My mouse pointer movement was not as accurate as it could have been so the tip of the arrow rested on the very edge of the button in question. I clicked anyway and was rewarded with the “pressed” view of the button. But no action! My suspicion is that, much like the disparate circuits in the lift, there are multiple threads of code in the GUI handling the physical appearance of the button and the actioning of its related function. These two threads must be using different models of where the bounds of the buttons are. There is, after all, the bevel and the border to consider as “in” or “out” in each case.
PLEASE STOP IT!
That’s my message to programmers. Steve Jobs was a stickler for detail. He never settled for “good enough”. Sometimes he wouldn’t even settle for “great”, instead striving for “insanely great”. This is why Apple products are pleasant to use. The physical metaphors have been tuned to the point where they are intuitive.
There may be a sound reason to separate the functions in button processing – indeed the Model View Controller (MVC) paradigm may insist it is the best solution. But if you’re going to divide up a task, please ensure the resulting subtasks add up to the original concept.
When I push a button I expect the same result every time. It has two states – pushed or not. Any more – like I saw today – and it’s just sloppy.