Previous Table of Contents Next


Global optimization of the GUI to suit the users’ entire job rather than any subset of the job is an important property of OO GUI style and an important consequence of our design methodology. The tradeoff is occasional local suboptimization — the GUI’s usability for some narrow task may not be as good as in some alternative designs. The reason for global optimization is that the users’ entire job is more important than any individual task. That is not to say that all tasks are given equal weight. The OO style is flexible enough to accommodate differences in task frequency, difficulty, and importance, and our methodology actively seeks out and accommodates such differences. In contrast, many procedural interfaces and the methods to design them optimize locally at the expense of the entire job.

OO GUIs differ from procedural GUIs. Procedural GUIs are oriented around particular procedures for doing tasks, with the users’ data elements shown only as support for the procedures. Typically, procedural interfaces have one window for each step in a procedure, with all the data elements relevant to that procedure being in that window. If a data element is needed in several procedures, a procedural interface represents the datum equivalently in each of those several windows. Consequently, related data elements such as a customer’s name and address will not be in the same window, unless those elements must be dealt with in the same step of the particular procedure that the GUI designers have chosen. A consequence of such procedural organization is difficulty in doing the task any other way.2 Doing the task in a different way often requires using the data elements in a different order than how they are organized in the current procedural interface. Users must move among many windows to get at the scattered individual data elements they need, but users get few clues to guide their search; for example, they cannot just look for the single window that contains all the attributes of a “customer”. In contrast to such a problematic procedural GUI, a well-designed OO GUI matches the users’ mental model of the data elements’ relations to each other; therefore, users can be guided by their mental model of the data elements, regardless of the procedure they are trying to execute.


2Occasionally, law or safety requires that the task be done in only one way, making a procedural interface more appropriate than an OO interface. A procedural interface may also be appropriate if there is only one way to do the task and if speed of task execution is critical. Except in those circumstances, guiding novices should be done with training and on-line procedural help for an OO interface, rather than with a procedural interface. If automated procedural hand-holding is provided, it should be in the form of a wizard layered on top of an OO GUI, with users given the power to escape from the wizard’s clutches at any time.

OO GUIs also differ from application-oriented GUIs. Application-oriented GUIs may or may not be purely procedural, but they all focus on the application being used to handle the users’ interactions with the data. For example, to open a word processing document object, a user of an application-oriented GUI must start up the word processing application, then open the document from within that application. The “application” is an extra layer between the user and the data that are the user’s true objects of desire. In contrast, pure OO GUIs hide the application from the user; users see no representations of the applications, they see just the data objects. Only the computer should have to deal with whatever code must be run to let users see and manipulate those data objects. To reflect the secondary role of the code, OO GUI designers often call the code the “handler” of the data object. There are necessary deviations from that pure object model, such as users needing to be aware of the existence of handlers in order to be able to choose which handler they want to use for a data object at a given time. However, the basic difference between OO and application-centric GUIs remains profound.

The “OO” in “OO GUI” is relevant only to the user interface, not to the underlying computer programming code. An OO GUI need not be coded in OO style — you can program an OO GUI in COBOL if you want (though we have heard rumor of an object-oriented COBOL). Nor do all the concepts of OO programming or analysis apply to OO GUIs; for example, inheritance has little to do with OO GUI containment.

We agree with the great many people in the usability engineering community who contend that OO GUI style is the most natural and easy to learn user interface style for the majority of computer users, tasks, and task situations. Some of the places to read those contentions, along with principles and rationales of OO GUI style, are Collins (1995), the CUA™3 style guide (IBM™4, 1992), the Windows®5 style guide (Microsoft®6, 1995), and McFarland and Dayton (1995). The industry’s degree and extent of conviction in the superiority of the OO GUI style is evidenced by the reliance on OO GUI style by most major GUI platform vendors (e.g., CUA and Windows styles). Partly for that reason, the OO style allows for multiplatform GUI design, as the next section explains.


3CUA is a trademark of IBM Corp.
4IBM is a trademark of IBM Corp.
5Windows is a registered trademark of Microsoft Corp.
6Microsoft is a registered trademark of Microsoft Corp.


Previous Table of Contents Next