Creation Operations

Creating new objects is a common user action in the interface. Although applications can provide the context for object creation, avoid considering an application's interface as the exclusive means of creating new objects. Creation is typically based on some predefined object or specification and can be supported in the interface in a number of ways.

Copy Command

Making a copy of an existing object is the fundamental paradigm for creating new objects. Copied objects can be modified and serve as prototypes for the creation of other new objects. The transfer model conventions define the basic interaction techniques for copying objects. Copy and Paste commands and drag-and-drop manipulation provide this interface.

New Command

The New command facilitates the creation of new objects. New is a command applied to a specific object, automatically creating a new instance of the object type. The New command differs from the Copy and Paste commands in that it is a single command that generates a new object.

Insert Command

The Insert command works similarly to the New command, except that it is applied to a container to create a new object, usually of a specified type, in that container. In addition to inserting native types of data, use the Insert command to insert objects of different types. By supporting the Microsoft Component Object Model (COM) technology, you can support the creation of a wide range of objects. In addition, objects supported by your application can be inserted into data files created by other applications that support the COM OLE technology.

Using Controls

You can use controls to support the automatic creation of new objects. For example, in a drawing application, buttons are often used to specify tools or modes for the creation of new objects, such as drawing particular shapes or controls. Buttons can also be used to insert COM objects.

Using Templates

A template is an object that automates the creation of a new object. To distinguish its purpose, display a template icon as a pad that displays a small icon of the type of the object to be created, as shown in Figure 6.11.

Define the New command as the default operation for a template object; this starts the creation process, which can either be automatic or can request specific input from the user. Place the newly created object in the same location as the container of the template. If circumstances make that impractical, place the object in a common location, such as on the desktop, or, during the creation process, include a prompt that allows the user to specify some other destination. In the former situation, display a message box informing the user where the object will appear.

Operations on Linked Objects

A link is a connection between two objects that represents or provides access to another object that is in another location in the same container or in a different, separate container. The components of this relationship include the link source (sometimes referred to as the referent) and the link or linked object (sometimes referred to as the reference). A linked object often has operations and properties independent of its source. For example, a linked object's properties can include attributes like update frequency, the path description of its link source, and the appearance of the linked object. The containers in which they reside provide access to and presentation of commands and properties of linked objects.

Links can be presented in various ways in the interface. For example, a data link propagates a value between two objects, such as between two cells in a worksheet or a series of data in a table and a chart. Hyperlinks (also referred to as jumps) provide navigational access to another location. A Web link (also known as a URL, or uniform resource locator) is an example of a hyperlink. An OLE linked object provides access to any operation available for its link source and also supplies a presentation of the link source. A shortcut icon is a link displayed as an icon.

When the user transfers a linked object, store both the absolute and relative path to its link source. The absolute path is the precise description of its location, beginning at the root of its hierarchy. The relative path is the description of its location relative to its current container.

The destination of a transfer determines whether to use the absolute or relative path when the user accesses the link source through the linked object. The relative path is the most common default path. However, regardless of which path you use, if it fails, use the alternative path. For example, if the user copies a linked object and its link source to another location, the result is a duplicate of the linked object and the link source. The relative path for the duplicate linked object is the location of the duplicate of the link source. The absolute path for the duplicate linked object is the description of the location of the initial link source. Therefore, when the user accesses the duplicate of the linked object, its inferred connection should be with the duplicate of the link source. If that connection fails — for example, because the user DEL etes the duplicate of the linked source — use the absolute path, the connection to the original link source.

Optionally, you can make the preferred path for a linked object a field in the property sheet for the linked object. This allows the user to choose whether to have a linked object make use of the absolute or relative path to its link source.

When the user applies an operation to a linked object, apply the operation to the linked object rather than to its linked source. That is, linking a linked object results in a linked object linked to a linked object. If such an operation is not valid or appropriate — for example, because the linked object provides no meaningful context — then disable any link commands or options when the user selects a linked object.

Activation of a linked object depends on the kind of link. For example, a single click navigates a hyperlink. However, a single click results in only selecting a data link or a linked object. If you use a single click to do anything other than select the linked object, distinguish the object by presenting it as a button control, displaying the hand pointer (as shown in Figure 6.12) when the user moves the pointer over the linked object, or both. These techniques provide feedback to the user that the clicking involves more than selection.

Record Processing

Record processing, or transaction-based applications, may require somewhat different structuring than the typical productivity application. For example, rather than opening and saving discrete files, the interface for such applications focuses on accessing and presenting data as records through multiple views, forms, and reports. One of the distinguishing and most important design aspects of record-processing applications is the definition of how the data records are structured. This dictates what information can be stored and in what format.

However, you can apply much of the information in this guide to record-oriented applications. For example, the basic principles of design and methodology are just as applicable as they are to individual file-oriented applications. You can also apply the guide's conventions for input, navigation, and layout when designing forms and report designs. Similarly, you can apply other secondary window conventions for data-entry design, including the following:

Provide reasonable default values for fields.
Use the appropriate controls. For example, use drop-down list boxes instead of long lists of option buttons.
Distinguish text entry fields from read-only text fields.
Design for logical and smooth user navigation. Order fields as the user needs to move through them. Auto-exit text boxes are often good for input of predefined data formats, such as time or currency inputs.
Provide data validation as close to the site of data entry as possible. You can use input masks to restrict data to specific types or use list box controls to restrict the range of input choices.