Use OO to build a better UI

Here’s a set of proven design methods for developing OO GUIs your users will love
By Dave Roberts, Dick Berry, Scott Isensee, and John Mullaly

Recently, a group of application architects at IBM developed a way to build object-oriented user interfaces (OOUIs), called the Object, View, and Interaction Design (OVID) methodology. This article is adapted from their book Designing for the User with OVID.

UI design is usually done ad hoc, with no consistent technique for documenting and communicating the interface design. As a result, the application often ends up with an interface different from what the UI designer intended.

Object-oriented program design, on the other hand, generally uses proven methodologies, such as Booch, Schlaer-Mellor, Rumbaugh, and OMT. But these methodologies don’t adequately address UI design.

OVID combines the notation and modeling techniques of successful code design methodologies with popular UI design processes, such as user requirements gathering, prototyping, and usability testing.

An object-oriented UI (OOUI) focuses on objects—the “things” people use to accomplish their work. Users see and manipulate object representations of their information. Each kind of object supports actions appropriate for the information it represents. Users of OOUIs need not be aware of underlying computer technology.

Although many of their concepts are similar, object-oriented programming (OOP) and OOUI aren’t the same thing. The two disciplines are, however, complementary: OOUI design concentrates on objects perceived by users, while OO programming focuses on implementation details that often need to be hidden from users.

Create UI classes, subclasses, portfolios, and views
In OOUI design, different kinds of objects belong to different classes. Class distinctions are based on common behaviors within a group of objects that differ between groups of objects (for example, a folder is a class of object that can be used to contain other objects). Memos, reports, and graphs are examples of kinds of objects that might be grouped together in a folder. Folders differ from other kinds of objects, but all folders share appearance and behavioral characteristics.

The folder is a general-purpose container that can hold objects of many different classes. To use a folder, users learn its properties and behaviors. These properties and behaviors are designed to support the addition of new objects to the folder, arranging objects in the folder, and viewing the folder’s contents (the folder’s primary tasks).

You can achieve specialization by defining subclasses; for example, a portfolio that automatically arranges specific kinds of objects into actions could be designed as a subclass of the folder class. A subclass inherits the properties and behaviors of its parent class. Developers add new properties and behaviors to subclasses to create desired specializations. Because the portfolio inherits the folder’s properties and behaviors, users can transfer their knowledge of the folder to the portfolio. They need only learn the distinguishing features of the portfolio to take advantage of its benefits.

Object classes and subclasses seen by users should be derived directly from analysis of users’ tasks and understanding users’ goals, motivations, and current techniques. In this way objects presented through the computer interface will be more easily recognized and their rules more readily understood.

In general, objects are composed of other objects, which in turn are composed of yet other objects—all the way down to elemental objects, which cannot be further decomposed by users. An object’s composition contributes to its class membership and therefore to establishing its properties and behaviors. Many kinds of objects are also containers of other objects.

Users interact with objects through views. Views present information and support interaction through the computer’s input/output devices. Typical user tasks involve working with a variety of object properties, using various object behaviors, and working with several objects at once. In practice it’s difficult to support all necessary tasks using a single view of an object. Objects typically must provide multiple views, each specialized for a specific set of tasks. Views span all presentation forms, including nonvisual forms such as audio.

The basis of OVID is a methodical analysis and design approach to identifying objects, defining views for sets of desired tasks, and specifying the interaction techniques used within each view to accomplish tasks. With OVID, an interface designer can identify objects that make users’ tasks most efficient.

An OOUI enables a user to focus on objects and work with them directly, reflecting the user’s real-world way of doing work. This contrasts with the traditional application-oriented interface, in which users must find a program appropriate for both the task they need to do and the type of information they want to use. Then they must start the program and use a mechanism such as an Open dialog box to locate the information and use it.

Compared to OOP, OOUI’s major distinction is user orientation. OOUI design is concerned with users’ perceptions—the concepts and techniques that users employ to complete their tasks. OOUI design seeks to hide those implementation aspects that are not relevant to users’ tasks. Construct a designer’s model

In OVID, a key goal is to construct a designer’s model representing the application from the user’s perspective. There are four phases in this process:

• Describe the objects the user will deal with. These include concrete objects, people, forms, and abstract objects.
• Suggest views of these objects that will let users interact with the objects needed to perform each task. All user interaction is accomplished through views. When looking for views, examine the most frequent or important tasks first.
• Create new task descriptions that document the details of how these interactions will occur.
• Document the details of specific interactions with individual views and related objects. Where the actions allowed for objects vary at different times, construct state diagrams.

	How you build an OOUI. Click here.

These process elements are sequential phases to some extent, but OVID is an iterative process. No single phase will produce final results. Task analysis feeds first to object definitions, but is also used when defining views, (new) tasks, and interactions. Note that transfer goes both forward and backward in cases such as between view and task definition. When the system is complete, the newly defined tasks should map to the ones found during analysis (see Figure).

The initial information for constructing a designer’s model comes from task analysis, which reveals information about what users do and which objects they employ. To start developing your model, examine the text of the task analysis and mark the objects (nouns) in the text. This will probably produce a long list of objects, so you’ll need to boil down this list to just the key objects.

You’ll often find that you could model some objects in several ways. Remember, you’re trying to record how users will think about the system. Drawing the model from each user’s perspective and showing only the objects and relationships that he or she experiences can be a powerful tool. Most modeling tools let you create copies and subsets of diagrams in order to do this.

As with objects, you’ll find views by referencing tasks users must perform. Examine the most frequent or important tasks first. Look at the information users need to read or supply in order to complete each task. You’ll see that this information is recorded in the designer’s model as relationships between objects and attributes of objects. You record information about each view in the model as another object, augmented with a note (shown as a box with a dog-eared corner) containing the task-related detail. This also helps distinguish views from other objects. Note that in any UI system, a view may comprise several more specific views. For example, a hotel’s views may combine views of rooms and guests.

All user interaction is accomplished through views. Whenever users deal with an object, you must present them a view suited to the tasks they want to perform. Next you’ll add objects to the system to represent the users of the system, showing how they employ each view to perform their tasks. In early iterations, you can usually show only the interactions between users and views. However, in later iterations you should also show details of interactions between views and the objects they represent.

From designer’s model to implementation
The designer’s model lies at the core of OVID. But before it can be of any benefit, that designer’s model must be converted to a programmer’s model, and then to an implementation that can be deployed. This process has three parts:

• Create a programmer’s model of the environment into which the system will be placed. You must decide in which environment, operating system, programming tools, and system services your application is to be used.
• Decompose the designer’s model to the level of detail needed to provide direct mapping between elements in the two models. Then transform the designer’s model into the programmer’s model.
• Translate the elements of both models to an executable form, creating a UI design.

The designer’s model should be entirely user-driven. Data from and about the users should control each decision. But implementing the designer’s model as a programmer’s model varies from case to case. It’s driven by implementation requirements, such as the platform of choice and the style that the customers require. Up to development of the programmer’s model, OVID can be used with any operating system and GUI style.

This segregation of concerns can aid the design team. Knowing which of the two models an element belongs to can give you the discipline to make each decision from the best perspective. If an element is in the designer’s model, then the question is always “What’s best for the user?” If an element belongs to the programmer’s model, the question becomes “What’s the best way to make this work?”

Our methodology lets development flow smoothly from interface design to implementation. It eliminates the traditional “throw it over the wall” disconnect between phases.


Dave Roberts is a senior software designer working in IBM’s Ease of Use Strategy and Design group in Warwick, UK. Dick Berry is a senior technical staff member in the Ease of Use Architecture and Design Group at IBM’s Austin, Texas development lab. Scott Isensee is a UI architect with IBM, also in Austin. John Mullaly is a UI architect and designer with IBM’s advanced human-computer interaction group, also in Austin. This article is adapted from pp. 72–90 of their book Designing for the User with OVID. Copyright 1998, by Macmillan Technical Publishing. Reproduced by permission. All rights reserved.

---

© 1999 FAWCETTE TECHNICAL PUBLICATIONS, all rights reserved.