Monday, August 15, 2005
Today's The Daily WTF shows somebody's implementation of an onscreen pushbutton that does something different depending upon whether the user single-clicks it or double-clicks it. It reminds me of one of the more frustrating programming assignments I've had.
With a desire to leap-frog the competition, my employer had hired a user-interface designer (or human-factors expert or user-psychologist or something like that) to design our next-generation applications. This guy spent a few months observing users of our existing systems, and generated over a thousand pages of observations and theories about how the applications would best serve the users. After generating this monstrous stack of data, he designed a user interface that he felt would be very efficient and easy-to-use.
This was in 1994, when most people, even those in the computer industry, had never used Mac OS, Windows, OS/2, the X Window System, or any other graphical mouse-driven user interface. This guy had seen them, but did not try to follow their standard conventions. I never knew if this was due to arrogance or ignorance; I suspect both were at play.
His design called for us to use the standard UI button widgets provided by the operating system (OS/2), but they would react as follows:
- single left click: Display a dialog box prompting the user for information about the "thing" associated with the button
- double left click: change the state of the "thing" associated with the button. The button would change color to indicate the new state. It would start gray, then turn yellow, then red, then green, then back to gray as the user double-clicked.
- single right click: Display a menu of states, so that the user could, for example, go right from gray to red, or green to yellow.
- double right click: Display a different menu, containing various commands.
I had a couple of big problems with this. First, I'd been a Mac user since the 80's, and knew the importance of simplicity and consistency. When I argued that this arrangement was inconsistent with the way that users expected buttons to work, I was told that the users had never seen any graphical user interfaces before, so they wouldn't have any expectations and thus would not be confused by this behavior. It would be a simple matter of training, I was told. This was an enlightening experience—it was the first time I ever suspected that I might know a lot more about software design than my bosses did.
The second big problem was that the UI library we were using to implement the application weren't designed to handle double clicks and right clicks on buttons. (After all, what kind of idiot would need to do that?) So it took all sorts of hacking to implement this functionality on top of that library. Today this wouldn't bother me as much, but back then, as a junior programmer, hacking around the limitations of a library made me very nervous that the whole thing would come crashing down some day.
We finished the application. The results were disappointing. This was the first major GUI application our company had developed, and users hated it. They were confused. It made no sense. So the company curtailed its development of GUIs for a while, deciding that the world wasn't ready for graphical user interfaces yet. It was only when Windows NT 4.0 appeared a few years later that we were able to write any new GUI applications.
The lesson is simple: a button should work like a button. If you want something that doesn't work like a button, don't use a button.
Management eventually listened to the programmers, and the UI designer was let go. That was another first for me: the first time I was glad to see somebody get fired. There hasn't been a second time.
[UPDATE (2005/8/31): There is another related Daily WTF, this time about changing button colors. At least I was smart enough to base my button's color on the internal program state, rather than the other way around.]