• Article

This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

Improve Your UI Design Process with Object-Oriented Techniques

Gordana Lamb

I suspect that most of us tune out articles about user interface design. "Been there, done that," right? Well, with the advent of mobile devices and Web Services—not to speak of today's imperative to design both applications and Web sites that are accessible by people with disabilities—I think it behooves us all to take a few minutes to ponder UI afresh. And Gordana Lamb's article provides you with an excellent vehicle for doing just that.

With the proliferation of personal computers and Internet use among the general population, the importance of easy-to-learn and interactive user interfaces has risen dramatically in the past few years. Yet, despite the promise of user-friendly and intuitive software, we still have a way to go.

Personally, I think one of the largest obstacles to user-friendly software is the fact that too many project managers and programmers simply underestimate the importance of good user interface (UI) design. And it seems to me that products like VB actually contribute to the problem because they make UI layout so easy that it's easy to omit the design phase altogether. Even when the issue of UI comes up, developers tend to focus mostly on the visual presentation of the interface—things like the screen layout and types of controls—instead of addressing usability and functionality from a user's point of view. Granted, good visual design is part of the equation, but there's more to it than that.

The key to successful computer-human interface is providing an environment that allows users to focus directly on business tasks and processes rather than computer-oriented aspects such as running applications or finding and saving files. Applying object-oriented principles and methodologies to UI design can help us achieve this goal because object orientation usually reflects how users perceive and think about the business world around them.

In most graphical computer environments today, users still work with a number of separate applications—for example, Word for memos, Excel for budgets. And if we want to change this, we need to start moving away from a traditional application-oriented UI design to a more object-oriented model that allows us to focus on our memos and budgets, not the tools we need to create them—nor, for that matter, on details associated with file locations and so on. Table 1 outlines some of the differences between the traditional application-oriented and object-oriented approaches to UI design.

Table 1. Differences between the traditional application-oriented and object-oriented approaches to UI design.

Application-oriented UI Object-oriented UI
Icons represent applications or minimized windows. Icons represent business objects.
Work environment consists of applications with primary and secondary windows. Work environment consists of a collection of related objects and object views.
Users must start an application and follow its structure before they can work on their tasks. Users interact with software representations of business objects to perform their tasks.
Each application has a complex menu bar that's shared among application components and represents all possible actions. Each object view has its own menu bar or context-sensitive menu containing actions that only apply to the selected object.
Application title bar shows the filename and the application name. Object title bar shows the object instance name and the view name.
Any changes to window properties need to be saved explicitly. Any changes to object properties are saved automatically. All changes are immediately reflected in all object views.

Object-oriented UI design is based on an iterative process of decomposing a business domain by objects rather than by functions through multiple design cycles. In each iteration, you'll perform the following steps:

  1. Identify main business objects that describe entities and processes in the company environment.
  2. Define views that will be used to present those objects to users.
  3. Determine interactions between business objects required to accomplish specific tasks.

Step 1: Identify the object model

A business object is a software representation of a real-world item, either physical or conceptual. Business objects may represent places, roles of people, transactions, events, physical items, business processes, or abstract concepts. Good requirements analysis will provide you with important clues to what your initial set of business objects and their properties should be. One of the methods commonly used for identifying business objects is to underline all of the nouns and noun phrases in your requirements or use cases and then create a list of possible business object candidates. In the first iteration, you should focus on a small set of main objects—adding supporting objects only as you "drill down" into the details and refine your design. As you go through this process, always keep in mind that you're working on the interface design and not programming objects required for software implementation.

Step 2: Define views

Once objects and their properties have been defined, you'll need to determine what types of views will be required for each object. Views are simply different ways of displaying the content and properties of objects to users. Views are presented in windows and allow users to interact with each object. You can start with five basic view types (although complex business applications might have many others): icon, property, container, composed, and information (see Figure 1).

Icon views are used to represent instances of an object. Property views are usually the primary views associated with each business object. They display object properties and allow users to make changes to those properties. In object-oriented interface design, menus are object-specific and always start with a name of the object represented in the view. Many commercial and custom applications tend to put a File item on the menu bar even though they never use any files. (Contrary to a popular belief among developers, the File item does not always have to be the first item on your window's menu. Even the classic Microsoft Windows Interface Guidelines—now out of print, see the sidebar "UI Resources"—states that some of the menus like File, Edit, View, and Help are not required in all applications.)

Notice that our container and property windows in Figure 1 don't include any OK, Cancel, or Save buttons that are common in many Windows applications. They're not required here because any changes to the object properties are saved automatically when you close the window. (Even today, it's my experience that most non-technical users are confused by the idea that you have to explicitly save changes made on the screen and that trying to explain the difference between internal memory and hard drive to them makes things even worse. There's really no reason why we have to impose the internal workings of a computer on our users. We should have our software adjust to the way users think, not the other way around.) Because most users intend to save their changes 95 percent of the time when they close the window, saving all of the changes should be a default action. For those few times when they need to cancel their changes, we can provide an "Undo Changes" menu item that will restore all object properties to their previous values.

Container views allow users to work with collections of business objects, arrange individual objects in a particular order, or move and copy objects between containers. There are many standard containers in Windows environments such as folders, Recycling bin, Outlook inbox, and so on. The Car List container shown in Figure 1 allows users to filter the entire car inventory by location, category, and make, display individual car properties, create new car object instances, and perform other business functions specific to this application.

Composed views present information from multiple objects by combining their properties into a single presentation (see Figure 2). For example, a car rental agreement can combine customer and car properties in a single view. Information views provide Help, tutorials, and other information that can assist users as they work with objects. Help should be available both for each object as a whole and for individual object properties where appropriate.

When designing business applications, we frequently need to provide users with multiple views of the same object. Different views make it easier for users to accomplish their tasks because they're tailored for a specific purpose. Multiple views also allow users to work with multiple instances of the same object at the same time. Both views in Figure 2 are displaying the properties of the Car Lot object—one as a table and the other as a graph. The important thing about creating multiple views of the same object is to make sure that they're dynamic and well-integrated. When a user makes changes to a Car Lot table, those changes need to be immediately reflected in the graph view.

Determine object interactions

The final step in your interface design is to determine what actions can modify or manipulate the properties for objects and what interactions between business objects are required to accomplish specific tasks. Again, requirements analysis and use case scenarios will provide us with information on how business objects will interact.

Both object-oriented interfaces and standard Windows applications rely on the object-action style of user interaction where users first select an object and then decide on an action to perform. However, Windows applications also implement the action-object interaction via indirect methods such as application menus or typing commands. When designing object-oriented UIs, our goal is to enable users to directly interact with business objects and other interface elements on the screen. As we migrate our apps toward object-oriented components, indirect methods will be replaced by more dynamic pop-up menus and direct object manipulation. (Pop-up menus are more appropriate in object-oriented design than application menus are because they only display actions that are specific for each object or view, reducing user confusion. They eliminate unnecessary mouse movements across the screen and don't take up any screen space, as they're displayed only when requested by users.)

Direct manipulation is an important aspect of object-oriented UI design and includes techniques like property inspection and drag and drop. As part of our design process, we need to determine what business objects will participate in drag-and-drop operations and what the default actions are for each object. It's common to have different meanings associated with the same drag-and-drop operation based on the target destination.

One of the most important things when implementing direct manipulation is to provide visual clues and dynamic feedback about the relationships between actions and results. Attaching a transparent image or an outline of the object to the pointer while the object is dragged provides feedback about the object movements, and you should change the mouse pointer to reflect whether the target object accepts the dragged object.

Call to action

With all of the changes in technology, it can only be expected that we'll be able to extend direct manipulation techniques in the future to make users' work more productive and enjoyable. As desktop and mobile computing technologies continue to evolve, using an object-oriented approach can help us face new challenges in the design and development of flexible and effective UIs.

—Karen Watterson

To find out more about Visual Basic Developer and Pinnacle Publishing, visit their website at http://www.pinpub.com/

Note: This is not a Microsoft Corporation website. Microsoft is not responsible for its content.

This article is reproduced from the April 2001 issue of Visual Basic Developer. Copyright 2001, by Pinnacle Publishing, Inc., unless otherwise noted. All rights are reserved. Visual Basic Developer is an independently produced publication of Pinnacle Publishing, Inc. No part of this article may be used or reproduced in any fashion (except in brief quotations used in critical articles and reviews) without prior consent of Pinnacle Publishing, Inc. To contact Pinnacle Publishing, Inc., please call 1-800-788-1900.