The concept of basing an interface on objects is a step toward the goal of a user-centered design. Object-oriented interface design employs real-world metaphors to help users understand and use the functions in your application. The types of objects and the interactions required depend on the tasks to be performed. For example, a highway construction worker may need a map object with a topographical view; a secretary is more likely to need a telephone directory.
While some objects are specific to an application or task, other objects have a wider range. For example, the construction worker and the secretary may both need a calendar object. In an object-oriented environment, various objects can work together. Users can choose the objects they need and group those that are customized for the tasks they want to perform.
You can classify objects according to the functions they perform. The Motif user interface classifies objects as follows:
Many objects are capable of containing other objects. Before classifying an object as a container, take the user's perspective and determine what its primary use will be. A wastebasket object can contain other objects. Its containment behavior, however, is both temporary and secondary to its main purpose of disposing unwanted objects and data. The user is more likely to regard it as a device than a container.
A folder, on the other hand, does little to its contents other than contain them. A folder may have views that allow a user to see the contents, but the folder does not transform the contents. Therefore, a folder is generally a container.
When an object is dragged to a container that can hold it, the default result of the drop operation should be to move the source object into the container, removing it from its former location.
You can think of most objects as containing data. A data object is one that exists to allow direct access to information, either to be displayed or edited. A folder usually contains data in the form of its objects but its main purpose is containment. A note object, however, is meant to convey information and would therefore be a data object.
Device objects provide an interaction path between a user's objects (or data) and the functions that the user may want to perform on those elements. For example, a printer object can allow the user to print without menus, using only direct manipulation techniques such as dragging and dropping an object to the printer.
The default behavior for a device object should usually be to place a copy of the source object into the device or into a queue for the device, prompt the user for additional information, perform the specified operation on the copy of the source, and, unless the device is a drive, delete the copy. Exceptions include devices such as wastebaskets and shredders, which are intended to allow the user to discard data or objects, and which should allow the source to be moved instead of copied.
A composite object is an object that is made up of other objects. It can easily be decomposed; that is, its control objects can be moved, copied, or deleted. It is distinguished from a simple object, which cannot be decomposed and is not made up of other objects. A composite object is composed of simple objects.
Use the following suggestions and your understanding of objects along with the user's tasks, expectations, and needs to decide when to use a simple or composite object:
Use a simple object when:
Use a composite or container object when:
The following principles address the differences between application-oriented and object-oriented interface design.
The main element of an application-oriented interface is the application itself. The user first starts the application, then calls files into the application to accomplish a task. The user must be aware of which application is running at any given time, which type of files the application supports, and how the operating system organizes data into files, directories, and storage media.
The tasks performed in an application-oriented environment generally have a rigid stricture; the user must complete steps in a predefined order from start to finish before going to another task. An application-oriented environment is best suited for users who do a small number of tasks repetitively. The application-oriented menu structure supports this type of interface.
The application-oriented menu structure uses a standard set of menu-bar
items that contain predefined pull-down menus. Choices in the pull-down menus
are categorized by the type of action they represent as shown in Table 8.
Table 8. Application-Oriented Pull-Down Menus
| Menu | Description |
|---|---|
| File | Contains choices that let the user call a file into the application or perform a set of actions on the file (or parts of it). |
| Selected | Contains choices that are determined by the scope of the actions they represent. Place choices that apply to selected objects or data in the view, but are not typical editing choices, in this menu. |
| Edit | Contains choices typically used when editing, such as Cut and Paste. |
| View | Contains choices that affect the arrangement and presentation of the view in the window, such as Sort and Change View. |
| Help | Contains choices that let the user refer to online help available for the various parts of the application. |
Object-oriented interfaces focus on the user's objects. The user decides what object to work with, then chooses actions to apply to the object, either by using menus or by direct manipulation. The user is not required to know what application is being used to work with the objects at any given time.
In an object-oriented environment, the user can decide how to structure tasks. In most cases, the user can choose the steps to be performed. The objects that need to be supplied should work together and with objects supplied by other applications. The object-oriented menu structure supports this type of interface.
The object-oriented menu structure sorts choices into various menus,
based on the objects or elements to which the choices apply. To satisfy the
user's expectations and to make choices easy to find, be aware of the
scope of each choice and place the choice in the appropriate menu. Table 9 describes standard object-oriented menu choices.
Table 9. Object-Oriented Pull-Down Menus
| Menu | Description |
|---|---|
| Object | Contains choices that affect the object whose view is in the window in which the menu appears. The Object menu also lets the user open additional windows that contain other views of the object. The same set of choices should also be available from the object's pop-up menu. |
| View | Contains choices that affect the way the object is presented in the current view and that let the user switch to a different view of the object within the same window. This menu allows the user to customize the view by sorting, filtering, or changing the format of its contents, or by changing the presentation of the menu-bar item. |
| Selected | Contains choices that affect the objects or data that are currently selected in the window or that affect the selection state of the contained objects. The contents of the Selected menu must change dynamically to reflect those choices that are appropriate to all members of the selected set. |
| Help | Contains choices that let the user refer to online help for various parts of the application. |
In an object-oriented user interface, applications no longer become the primary interface to the user. Instead, users work directly with objects, organizing and classifying them to suit their tasks. Views replace applications as the means of accessing or modifying information. For example, a newly installed spreadsheet processor would be accessible as a new view for every existing spreadsheet object.
There are three types of views: composed view, contents view, and properties view.
A composed view shows an object's data in presentation (or final output) form. For example, a composed view for a word-processor document shows the formatted output as seen on a printer or previewer. Composed views usually apply to data objects.
A contents view shows the contents of an object. For example, a contents view for a word-processor document shows the list of files that make it up. Contents views usually apply to container objects, such as in folders.
You can display contents views with various interpretations, including iconified views and detailed views. Do not be overly concerned about which category a particular view falls into. Instead, create views that convey information in a form that is meaningful to users.
A properties view displays information about the characteristics or attributes of an object and optionally provides a way for the user to change them. For example, in a properties view for an object such as a document, the user could change the font, type size, or color of the document. A properties view should be provided for every type of object.