
We design and create interfaces with the user in mind. How does the user complete the task of composing an email? How does the user save a webpage to her bookmarks? In particularly complex systems, sometimes the solution involves examining more than just how a user can complete a single task, but how the system as a whole supports (or doesn't support) certain actions. In this way, you're creating a user interface that allows the user to complete their task in potentially myriad ways, not only what you intended. This is truly difficult, as predicting user behaviour is nigh impossible.

Borrowing concepts from the HCI masters and treat the system of user, device, and environment as a whole is one way of side-stepping the issue of not being capable of mind-reading. [Edward Hutchins](http://hci.ucsd.edu/hutchins/) of UCSD has presented many different ways of examining these kinds of systems, but perhaps his best known example is that of an airplane cockpit. When treating the entire cockpit—it's dials, pilots, controls and pedals—as a whole system flying through the air, how might it operate? It is difficult for an outside observer to understand the complex thought processes inside another person's head, but it is straight-forward to understand what a cockpit is _doing_ at any given moment. Hutchins, in [How a Cockpit Remembers Its Speeds](http://scholar.google.com/scholar?hl=en&q=How+a+Cockpit+Remembers+Its+Speeds), applies the normal cognitive science analytical approach to the entire cockpit, rather than the mind of a single pilot. In particular, Hutchins examined how the system recorded and memorized the necessary speed limits on approach of a runway, as well as the wing configurations necessary for landing. It is a fantastic read.

The part I want to highlight here is the concept of _speed bugs_. Pilots had devised a system for when the flaps and slats on the wings needed to be adjusted and extended in order to gradually reduce speed and altitude for landing. The airspeed indicator works similarly to the car speedometer, and so the pilot-not-flying affixed mere paper clips to the frame of the indicator, denoting the points at which the flaps and slats needed to be changed. The benefit here is that the pilot-not-flying was able to project his internal working memory onto the shared memory of the cockpit. The pilot-flying can then access this information far more quickly than asking the co-pilot. The added benefit of attaching clips to the airspeed indicator is that the pilots can infer how close to the next wing configuration they may be—translating math into a visually inferred distance. These speed bugs were later adapted to become sliding clips pre-installed to the airspeed indicator, and now are part of the graphical UI now used in the latest commercial aircraft indicators.

In the end, the airspeed indicator _happened_ to be created in a way that was extensible by users. It followed the general design of speedometers and other radial dials, so it was familiar to any who've seen them in other domains. The design of the speed bugs capitalizes on the social context between two professionals, and that humans are better at reading dials than lookup tables in a book. We can perceive the tendency of the speed from the direction and speed the needle is moving, and how soon the next wing configuration is required based on the proximity of the needle to the next speed bug.

![Fast application switching on WebOS](/media/2012-06-04-webos.jpg "Fast application switching on WebOS")

A side-effect of the card-like switching between applications on WebOS and Windows Phone 7 has the added benefit of viewing more than one application's UI simultaneously. A user can swipe instant messaging to the side to see what time-slots are free on her calendar. This extended use-case is implied by the interface, but isn't the direct purpose.

A related issue exists when analogue interfaces are brought to digital ones in the extreme: bringing more than just the experience of the original, but all of its limitations too. A great re-implementation that we all use is Google (or Bing or Yahoo) maps: the limitations of scale, detail and annotations of paper maps are all removed, leaving only the core experience to be built upon by digital enhancements.


We design and create interfaces with the user in mind. How does the user complete the task of composing an email? How does the user save a webpage to her bookmarks? In particularly complex systems, sometimes the solution involves examining more than just how a user can complete a single task, but how the system as a whole supports (or doesn't support) certain actions.

Posts about social context