January + February 2008

system should not be more complex than your present needs, and by allowing the system to increase its power incrementally, the dream of providing products that are truly simple initially can be achieved, without their being made to merely look simple, and without impairing their flexibility,” he wrote.

My father also discussed the conflict between seamless user tasks and divided applications: “Instead of a computer’s software being viewed as an operating system and a set of applications, then, the humane interface views the software as a set of commands.” That is, functionality should be learned on an as-needed basis, and be available anywhere in the system, regardless of the dividing lines between the individual applications. Applications interfere with the idea of as-needed functionality. The learning curve for each application can be overcome with use, but if we need to use any additional piece of functionality not provided in our main application, we must learn an entire other application that provides it. This makes a simple task such as editing a document with pictures unnecessarily difficult.

I’ve tried to follow through on these ideas in my own work and to design an interface system that works beyond the boundaries of an individual application. The challenge is that the current software economy is tied to the concept of applications. Disparate applications aren’t going to disappear. Providing services, however, allows us to granulate that software economy. If you don’t need all of the functionality of Photoshop, you can just buy the photo-editing features you need

as a service. Instead of arguing for the abolition of applications, we can champion services with a universal way of accessing them. That way, we can snap our fingers and have the functionality we need, regardless of the application we happen to be using. This shift also reframes the interface challenge, which then becomes this: If all functionality is available to us anywhere, at any time, how do we tell the computer which particular piece of functionality we want?

We’re going to need a universal way to access those thousands of possible services we might want to perform on our selected data— from calculating the sum of the values, to performing a Google search on the text, to changing the size at which it is displayed. Current paradigms for accessing this functionality don’t scale to how we really work—i.e., across applications, not within them.

Imagine grafting together the endless menus for PowerPoint, Mathematica, Firefox, and Photoshop. Certainly, there would be some overlap, but the result would still be a Medusa’s head of seething submenus. It would be laborious to find anything in such a monstrosity, and inefficient to manually select a menu even if we knew where to find it. We headed toward graphical menus initially because they made all options visible, by allowing recognition of an option instead of forcing the recollection of an option. Jef Raskin and the rest of the Macintosh team found that menus worked well. In hindsight, they worked well because of the limited number of available options.

With increasing scale, the menu metaphor falls short.

While the recognition solution can work in a single application with a restricted set of options, it fails when we look at real tasks that cross application boundaries. For example, the argument that menus provide visibility and findability breaks down when applied at a large scale because they become slow to learn and use. Similarly, keyboard shortcuts—patches meant to increase the speed of menus—also do not scale. The keyboard features a finite number of keys and even fewer mnemonic matchings of keys to functionality.

Icons fare worse than menus and keyboard shortcuts. The abstract concepts inherent to detailed functionality are difficult to represent visually. Microsoft Word attempts to use icons to represent some of the basic functionality of text processing, but this method doesn’t work out well. Can you figure out what each of these icons does?

Even if you can recognize a few of the examples, your recognition is learned. Those icons, no matter how self-evident Microsoft would like them to be, require language (in the form of tooltips) to actually explain what they do. If simple text-formatting operations fail so greatly, how can icons be designed to express the full range of functionality that services provide? And how would we page through that giant lexicon of icons to quickly to find the one we’re looking for?

The “window, icon, menu, pointing-device” or WIMP paradigm, has its limits, and these limits are now growing clearer as the complexity of modern computing unfolds.

The Linguistic Command