While teaching at the University of Technology in Sydney, Australia, I analyzed some of the most popular and successful texts on object-oriented analysis and design. It was a very scientific sample: I checked every book on the subject in my office, then walked down the hall and went through Professor Brian Henderson-Sellers's bookshelves. Not surprisingly, we owned a lot of the same books, but between us we had 15 different recent texts on object-oriented development, including nearly all of the most widely used and referenced. Out of nearly 6,000 pages in total, a mere 161 pages discussed any aspect of users, user requirements, usability, or user interfaces, and nearly three-quarters of these were in just three books. More than half of the books devoted three or fewer pages to any subject connected with users and use. A full third did not even have any relevant index citations, and one book, while devoting a whole page to the topic of software usefulness, did not bother to index it. Perhaps the situation is changing, as several books attest, including Designing Object-Oriented User Interfaces (Collins 1995) and Object Modeling and User Interface Design (van Harmelen 2000). Not a moment too soon or a page too many, we might conclude.

To many who use objects in their development work, it is still unclear just what it is that object technology might bring to the user interface and offer to users. After all, object technology is really the technology under the hood, the technology of implementation, not the technology of interaction. Like the rest of software engineering, the evolution of object orientation has been largely directed toward improving this machinery under the hood, with barely a nod to the niceties of whether the hood release might be located somewhere that the driver can reach.

In this oversight, we need not feel too much shame. We have mirrored the histories of many new technologies, which are often dominated in the beginning by daunting challenges of implementation and performance, only later affording the luxury of close attention to external detail. Such was the case in early automobile design, where building reliable engines and solving the problems of power transmission took legitimate precedence over comfortable seats or easy controls. That changed, of course, and perhaps it is time that object technology consider the comfort and convenience of users.

For the most part, users don't care what is under the hood of the systems they use. Don Norman, usability guru and champion for a human perspective on the use of technology, says simply that, to the user, the user interface is the system (Norman 1988). There are exceptions. The technology under the hood becomes important to the user under special circumstances. It becomes important if the car can't accelerate enough to pass a truck safely or the compiler can't churn out efficient code. It matters if the engine has to be repaired or retuned every 5,000 kilometers or if Windows has to be rebooted every few hours because of memory leaks in the office presentation package.

User interfaces are about behavior as well as about appearance. If a particular object-oriented visual development tool imposes a big enough performance hit, then the technology under the hood can protrude through the dashboard. Slow responses to queries and snail-paced scrolling through data can become as much features of the user interface as are the icons on the tool bar.

As the literature and rhetoric of object technology has grown, many have spoken or written in passing about object-oriented user interfaces. Few have tackled the more tantalizing task of saying just what such interfaces might be and how they might be useful.

What is an OOUI besides another double-oh acronym? Is there such a thing as a truly object-oriented user interface and would any self-respecting person want to use one? If it is nothing more than a GUI with direct manipulation of visual objects, OO adds nothing to the UI mix.

One of the persistent problems in the OO world becomes particularly vexing when it comes to talking about user interfaces. This problem is the distinction, or more often the lack thereof, between objects in software or in software models and objects in the quotidian sense, that is, in the external physical world, the world so often cavalierly called “the real world.” Many an object-technology novice has been seduced into thinking that all you have to do for object success is find the objects in the real world, stitch up some code for the classes to which they belong, and ship your software. What could be more seamless? As Ivar Jacobson and other methodologists have persuasively pointed out, many of the most important objects in well-designed software systems do not correspond in any simple fashion to real-world or domain objects.

The quotidian and technical meanings of “object” continue to be casually conflated and confused. In everyday terms, all user interfaces incorporate objects for users to manipulate. That some objects are monochrome characters manipulated through keyboard commands does not make them less worthy of the name.

In his book on the subject, Dave Collins (1995) offered a “definition” of OOUI based on three characteristics: (1) users perceive and act on objects, (2) users classify objects based on how they behave, and (3) all the interface objects fit together into a coherent overall conceptual model. Sounds good, but the first part is about users, not user interfaces. It can be argued that object perception is hard-coded in the human brain if we are speaking of ordinary objects and is a phenomenon true only of software developers if we are speaking of software objects. The second part, concerning classification, is also about users and not interfaces. It is almost certainly not true of everybody or even of any one person in all circumstances. People classify ordinary objects in terms of many features and factors other than behavior. You might note that all politicians act pretty much alike but that a friend of yours looks like Bill Clinton, for example. As to the third putative property of an OOUI, a coherent model is merely a characteristic of well-organized user interfaces of any stripe: good interfaces hang together and make sense as a whole.

Another view of OOUIs might be that they are interfaces that surface the constructs and structure of the object-oriented paradigm, presenting users with objects and class hierarchies, methods and messages as a medium of exchange for interaction with systems. This view holds some potential but also hides some pitfalls. In the most rigorous and naïvely reactionary interpretation, users would interact with an object-oriented interface by moving messages from object to object, but this is not likely to be particularly natural or highly usable.

No user whose sanity has not been eroded through years of small-talk with object-oriented compilers would ever describe what they do with a graphical user interface as “sending messages to objects.” Users do not send messages to objects. They do things with and to those objects. Even the idiom of so-called direct manipulation is a kind of digital misdirection. Users do not directly manipulate anything when they move a mouse on the desk to cause a pointer to move and a picture to change on the display. That we can learn to do such things and accept them as reasonable is even more a tribute to the human brain than that we can program a computer to play some part in this pantomime of pointers and pixels.

Does it ever make sense to expose any of the machinery of object technology at the interface with end users? For the most part, when the logic and structure of the program show at the screen, something is wrong. It reflects inside-out design, where the interface ends up as little more than a thin and blotchy skin over a lumpy interior. Outside-in design, by contrast, means that internal components and their external manifestations reflect user needs rather than partisan programming.

So-called “factory objects” placed on the interface might be an example of a useful exception. Visual components that when clicked or swiped create new instances of a class are an interesting and under-utilized form of object-oriented user interface technology. A “pad” of “fax cover sheets” could be used to open a blank form ready for completion and eventual transmission. Not everyone would find such a “document-centric” scheme the most felicitous, so it is probably worthwhile thinking through how best to provide appropriate alternatives.

Collins contrasts OOUIs with other UIs that are not object-oriented, but the straw screen he erects is the ancient command line interface. Command line interfaces put the verb (command) before the object (parameters). Sometimes it has been argued that the object-verb grammar of OOUIs is more natural and more flexible: select the picture and click the recolor tool or drag the document to the printer.

If what you want are usable user interfaces, forcing this syntax on the user in the name of object-oriented purity is not necessarily a good idea. The carpenter may start with a nail but then brings the hammer to the nail, not vice versa. In real-world tasks, objects as objects and objects as operators are not typically interchangeable. Hitting the nail with the hammer makes sense, while the reverse is absurd.

If one of the claimed strengths of object-orientation is that it maintains consistency with the language of an application domain, then surely this should apply to OOUI design. Indeed, good UI design is always consistent not only with the language of users and the domain of their work, but also consistent with the tasks within that domain that are of interest to users. This consistency is only possible if we take the time to understand what users are trying to do and how they are trying to do it.

Coming down from the abstract heights, consider a particular but representative problem: the design of interaction with a “stapling” feature in a document management system. Just as physical sheets of paper or documents can be stapled together to be handled as a unit, a stapling feature on the UI allows collections of documents to be grouped on a semipermanent basis so that they can be manipulated as a unit by the user.

In the real world, the office worker may take a stack of documents to the stapler to staple them. This corresponds to the “object-oriented” drag-and-drop idiom: click the document stack icon, drag to the stapler icon, and then release. Note that this is operationally almost identical to selecting the object by clicking, then moving the pointer to the stapler and clicking on it, with one important difference. For many users, drag-and-drop is one of the more difficult idioms to master, and they will prefer clicking on two targets in series, which is generally easier, slightly faster, and more reliable. Yet other users, contaminated by experience with command line interfaces or corrupted by years of doing real work instead of working with computers, may prefer to select or pick up the stapling tool, then click on the document stack to be stapled.

Any claim that the drag-and-drop idiom is the most natural and lifelike is further weakened by the fact that a reasonable implementation does not leave the document stack in the jaws of the stapler object any more than the printed document remains on top of the printer icon. Even MacMetaphor purists recognize opportunities for the computer to do some of the manipulation, and will happily allow dragged objects to unrealistically spring back to their original locations.

In the real world, workers have no problem mixing object-primacy and function-primacy metaphors. They take the paper to the stapler or pick up the stapler and apply it to the paper without confusion. A good user interface affords similar flexibility or goes it one better. Without ambiguity, the interface could allow all the major variants in interaction: (1) drag stack to stapler; (2) click stack, then click stapler; (3) click stapler, then click stack; or even (4) drag the stapler to the stack. A good implementation communicates these possibilities to the user. The stapler should have the right affordance, by its appearance suggesting that it can have things dropped or dragged onto it and that it will respond like a push-button to clicking. When clicked, it should appear to push in. When approached by a dragged stack, it should highlight to indicate its readiness. If you drag a printer to it, it should burp. An appropriate animation, with or without an audible crunch through the speaker, tells the user when the stapler does its job. Pick up the stapler as a tool with nothing selected and the pointer turns into an iconic “hand-held” stapler.

Is this UI approach object-oriented? The object purists would probably say no, the object evangelists would probably claim it along with anything else they think is cool and might work. You could certainly implement it in an object-oriented language or go retro and piece it together from procedures. What will matter most to your users is whether it fits with the work they are trying to do.

The choice of implementation technology may become of interest to users when it comes time to incorporate new features or to accommodate changing requirements. A robust technology that permits rapid and reliable integration of new capabilities yields more utility in the long run than one that resists changes. If by object-oriented user interfaces we simply mean ones built from communicating software objects, here may be the big payoff. Of course, to deliver on this promise, we will need to get the message, too, living up to our street rep of constructing flexible and reusable components.

Revised from Object Magazine, September 1996.