This tale – told to me when I was an undergraduate computer-science student – has really stuck with me over the years, and provides significant guidance on how to build applications that optimize user productivity.
I got involved in technology really quite by accident (an interesting story all by itself; maybe later), but, as that accidental undergraduate computer-science student, I had the great pleasure of having Andries (Andy) van Dam as my teacher and advisor. I owe this man more than he will ever know (many more interesting story possibilities here), but suffice it to say for the moment that his insights and unique style of education had a very powerful impact on me, and I would never have the privilege of doing what I do today without him.
Anyway, while lecturing on the emerging (this was around 1973) field of graphical user interfaces, Andy once told the story of a Mexican airplane pilot who had a rather unusual approach to flight-deck instrumentation. Basically, he loosened the mounting rings of all of the dial indicators in the cockpit and “normalized” them so that all of the needles would be pointing straight up when everything was, well, normal. That way he could tell with a mere glance whether anything might be of concern. Andy also noted that the pilot simply removed any indicators that didn’t conform to this model, although I find that point, while humorous, likely apocryphal. And, interestingly, almost every real-time control system I’ve seen in the past 20 years or so uses exactly this model – simplify the user interface to the point that a mere glance will do, at least in most cases.
But apart from a good laugh or two, there was a powerful lesson here: user interfaces are not really part of an application. An application is really an API with appropriate security and integrity management that executes all of the required transactions against a database so as to do what the user of the application wants done. How the user gets data into and out of the application, and how the application is otherwise controlled, however, has potentially so much variability that this part of the executable should be separate and distinct from the rest. With the exception of a few batch applications from the late ’70s, every system and application I’ve specified or designed since then has followed this model.
When someone says they don’t like a particular piece of technology, ask them why. Nine times out of ten it won’t be about basic functionality or bugs (Microsoft products the exception here; sorry, couldn’t resist) – it will be about interface. UNIX in its early days was universally disliked outside of the programmer community (its natural constituency, after all) because the Shell, its UI, was, well, obtuse at best to non-computer-science types. Today, just for example, I personally find even the iPad to be confounding at times. A related story involves BMW’s iDrive system, which has been roundly criticized as being to hard to use. As the anecdote goes, what’s the point of building a car that only a senior executive can afford, but only a teenage boy can figure out how to use?
Sticking with this point, I rent a lot of cars, and often find elements of a given user interface complex – a little standardization here would be nice, if for no other reason that trying to find the headlight switch in the dark can be a distraction, and we all know what that can lead to while driving. Give me simple analog controls. I’ve yet to drive a car with automatic climate control that really was such. Those teenage boys (actually, all young people) are a bit like children acquiring natural spoken language – their brains are just wired in such a way to adapt to new technologies with ease. More experienced users have expectations that often prevent them from readily adapting; frustration and mistakes often ensue. Bottom line: no single UI is likely to work for everyone, and customization represents a huge opportunity to improve both productivity and customer satisfaction.
Anyway – ease-of-use, as I’ve said before, will ultimately be the differentiator between successful products and those that had, um potential. And, as I alluded earlier this week, being able to customize the UI to a specific user’s needs will be one of the key elements in successful systems in the future.
