Visual Editing of Embedded Objects

Design Specifications and Guidelines - Working with OLE Embedded and Linked Objects

One of the most common uses for activating an object is editing its content in its current location. Supporting this type of in-place interaction is called visual editing, because the user can edit the object within the visual context of its container.

Unless the container and the object both support inside-out activation, the user activates an embedded object for visual editing by selecting the object and choosing its Edit command from either a drop-down menu or a shortcut menu. You can also support shortcut techniques. For example, by making Edit the object's default operation, the user can double-click to activate the object for editing. Similarly, you can support pressing the ENTER key as a shortcut for activating the object.

When the user activates an embedded object for visual editing, the user interface for its content becomes available and is blended into its container application's interface. The object can display its frame adornments, such as row or column headers, handles, or scroll bars, outside the object boundaries, temporarily covering neighboring material. The object's application can also change the menu interface, which can range from adding items to existing drop-down menus to replacing entire drop-down menus. The object can also add toolbars, status bars, and supplemental palette windows, and can display shortcut menus for selected content.

The container application always determines the degree to which an embedded object's interface can be blended with its own, regardless of the capability or preference of the embedded object. A container application that provides its own interface for an embedded object can suppress an embedded object's own interface. Figure 12.16 shows how the interface might appear when its embedded worksheet is active.

When the user activates an embedded object, avoid changing the view and position of the rest of the content in the window. Although it may seem reasonable to scroll the window and thereby preserve the content's position, doing so can disturb the user's focus, because the active object shifts down to accommodate a new toolbar and shifts back up when it is deactivated. Activation does not affect the title bar. Always display the top-level container's name. For example, when the worksheet shown in Figure 12.16 is activated, the title bar continues to display the name of the document in which the worksheet is embedded and not the name of the worksheet. You can provide access to the name of the worksheet by supporting property sheets for your embedded objects.

A container can contain multiply-nested embedded objects. However, only a single level is active at any one time. Figure 12.17 shows a document containing an active embedded worksheet with an embedded graph of its own. Clicking the graph merely selects it as an object within the worksheet.

If the user activates the embedded graph by choosing, for example, the graph's Edit command, the object is activated for visual editing, and the graph's menus are displayed in the document's menu bar. This is shown in Figure 12.18. At any given time, only the interface for the currently active object and the topmost container are displayed; intervening parent objects do not remain visibly active.

An embedded object should support visual editing at any view magnification level because the user can scale its container's view arbitrarily. If an object cannot accommodate visual editing in its container's current view scale, or if its container does not support visual editing, open the object in a separate window for editing.

For more information about opening embedded objects, see "Opening Embedded Objects" later in this chapter.

If the user selects or activates another object in the container, deactivate the current object and give the focus to the new object. This is also true for an object that is nested in the currently active object. You should also deactivate the object when the user presses the ESC key; the object will remain selected. If the object already uses the ESC key for an internal operation, support SHIFT+ESC to deactivate the object.

When a user edits an active object, the edits become part of the container immediately and automatically, just like edits made to native data. Consequently, do not display an "Update changes?" message box when the object is deactivated. Remember that the user can abandon changes to the entire container, embedded or otherwise, if the topmost container includes an explicit command that prompts the user to save or discard changes to the container's file.

While Edit is the most common command for activating an embedded object for visual editing, other commands can also activate the object. For example, when the user clicks the Play command for a video clip, you can display a set of commands that allow the user to control the clip (Rewind, Stop, and Fast Forward). In this case, the Play command provides a form of visual editing.

The Active Hatched Border

If the container allows an embedded object to change the container's user interface, then the application that supports editing of the embedded object displays a hatched border around the object's boundary (as shown in Figure 12.19). For example, if an active object places its menus in the topmost container's menu bar, you would surround the object with the active hatched border. The hatched pattern is made up of 45-degree diagonal lines.

The active object takes on the appearance that is best suited for its own editing; for example, the object may display frame adornments, table gridlines, handles, and other editing aids. Because the hatched border is part of the object's territory, the active object defines the pointer that appears when the user moves the mouse pointer over the border.

When the user clicks within the hatched pattern (and not on the handles) of an active object, the object should respond as if it were clicked just inside the edge of the border. The hatched area is effectively a hot zone that prevents inadvertent deactivations and makes it easier for the user to select the content of the embedded object.

Menu Integration

When the user activates different objects, different commands must be available in the window's user interface. Menus can be grouped into the following broad classifications:

Primary Container Menus

The topmost or primary container viewed in a primary window controls the work area of that window. If the primary container includes a menu bar, it should provide at least one menu whose commands apply to the primary container as a whole. For example, for document file objects, use a File menu for this purpose, as shown in Figure 12.20. This menu includes document and file level commands such as Open, Save, and Print. Display the primary container menu in the menu bar at all times, regardless of which object is active.

Object Menus

When an object is active, it can add new menus to the primary container's menu bar. These menus contain commands for working directly with the active object's content. Place commands for moving, deleting, searching and replacing, creating new items, applying tools, styles, and Help on these menus. If no embedded objects are active, but the window is active, the primary container should be considered the active object.

An active object's menus typically occupy the majority of the menu bar. Organize these menus the same way they would appear when the user opens the object in its own window. Avoid naming your active object menus File or Window, because primary containers often use those titles. If an object uses direct manipulation as its sole interface, you do not need to provide an active object menu for it.

If an active object provides a View menu, it should include only commands that apply to that object. If the object's container application requires that its own document or window-level "viewing" commands be available while an object is active, place them on the container window's shortcut menu and on the Window menu, if one is present.

When you design how selected objects interact within an active object, display the commands of the selected object (as registered in the registry) either as submenus or as separate menus. The active object should also provide a shortcut menu for any selected content within it, containing the common commands needed for working with that selection. Figure 12.21 shows an example of a shortcut menu for a selection within an active bitmap image.

Keyboard Interface Integration

In addition to integrating the menus, you must also integrate the access keys and shortcut keys used in these menus.

Access Keys

The access keys assigned to the primary container's menu and an active object's menus should be unique. Following are guidelines for defining access keys for integrating these menu names:

Use the first letter of the menu of the primary container as its access key character. Typically, this is "F" for File. Use "W" for a workspace's Window menu. Use the appropriate equivalent for localized versions.
Use characters other than those assigned to the primary container and workspace menus for the menu titles of active embedded objects. (If an embedded object existed previously as a stand-alone document, its corresponding application already avoids these characters.)
Define unique access keys for an object's registered commands, and avoid using characters that could already be access keys for common container-supplied commands, such as Cut, Copy, Paste, Delete, and Properties.

Despite these guidelines, if the same access character is used more than once, pressing an ALT+letter combination cycles through each command, selecting the next match each time it is pressed. To carry out the command, the user must press the ENTER key when it is selected. This is standard system behavior for menus.

Shortcut Keys

For primary containers and active objects, follow the shortcut key guidelines covered in this book. In addition, when you define shortcut keys for active objects, avoid using keys that could already be assigned to the container. For example, include the standard editing and transfer (Cut, Copy, and Paste) shortcut keys, but avoid File menu or system-assigned shortcut keys. There is no provision for registering shortcut keys for a selected object's commands.

If a container and an active object both use the same shortcut key, the shortcut key for the active object is processed first. That is, if the user activates an embedded object, then presses a shortcut key, the active object's application processes the shortcut key. If the active object does not process the shortcut key, the shortcut key becomes available to the container application. This applies to any level of nested embedded objects. If the user wants to use the shortcut key in the container application, the user must first click outside of or otherwise deactivate the embedded object.

Toolbars, Frame Adornments, and Palette Windows

Integrating drop-down and shortcut menus is straightforward because they are confined within a particular area and follow standard conventions. Toolbars, frame adornments (as shown in Figure 12.22), and palette windows can be constructed less predictably, so it is best to follow a replacement strategy when integrating these elements for active objects. That is, toolbars, frame adornments, and palette windows are displayed and removed as entire sets rather than integrated at the individual control level — just like menu titles on the menu bar.

When the user activates an object, the object's application requests a specific area in the container application in which to post its tools. The container application determines whether to:

Replace its tool with the tools needed by the object, if the requested space is already occupied by a container application tool.
Add the tools needed by the object if a container application tool does not already occupy the requested space.
Refuse to display the tools needed by the object. This is the least desirable method.

Toolbars, frame adornments, and palette windows are all basically the same interfaces — they differ primarily in their location and the degree of shared control between container and object. These types of controls reside in four locations in the interface, as shown in the following table.

You determine their location by their scope. Figure 12.23 shows possible positions for interface controls.

When determining where to locate a tool area, avoid situations that cause the view to shift up and down as different-sized tool areas are displayed or removed when the user activates different objects. This can be disruptive to the user's task.

Locations for Controls
Location	Description

Object frame	Place object-specific controls, such as a table header or a local coordinate ruler, directly adjacent to the object itself for tightly coupled interaction between the object and its interface. An object (such as a spreadsheet) can include scroll bars if its content extends beyond the boundaries of its frame.
Pane frame	Locate view-specific controls at the pane level. Rulers and viewing tools are common examples.
Document (primary container) window frame	Attach tools that apply to the entire document just inside any edge of its primary window frame. Popular examples include ribbons, drawing tools, and status lines.
Windowed	Display tools in a palette window; this allows the user to place them as desired. A palette window typically floats above the primary window and any other windows of which it is part.

Because container tool areas can remain visible while an object is active, they are available to the user simply by interacting with them — this can reactivate the container application. The container determines whether to activate or leave the object active. If the toolbar buttons of an active object represent primary container or workspace commands — such as Save, Print, or Open — disable them.

For more information about the negotiation protocols used for activation, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.

As the user resizes or scrolls a container's area, an active object and its toolbar or frame adornments placed on the object frame are clipped, as is all container content. These interface control areas lie in the same plane as the object. Even when the object is clipped, the user can still edit the visible part of the object in place and while the visible frame adornments are operational.

Some container applications scroll at certain increments that may prevent portions of an embedded object from being visually edited. For example, consider a large picture embedded in a worksheet cell. The worksheet scrolls vertically in complete row increments; the top of the pane is always aligned with the top edge of a row. If the embedded picture is too large to fit within the pane at one time, its bottom portion is clipped and consequently never viewed or edited in place. In cases like this, the user can open the picture in its own window for editing.

When a window is split into panes, the frame of a pane should clip the frame adornments of nested embedded objects, but not by the extent of any parent object. Objects at the very edge of their container's extent or boundary can display adornments that extend beyond the bounds of the container's defined area. In this case, if the container displays items that extend beyond the edge, display all the adornments; otherwise, clip the adornments at the edge of the container. Do not temporarily move the object within its container just to accommodate the appearance of an active embedded object's adornments. A pane-level control can potentially be clipped by the primary window frame, and a primary window adornment or control is clipped by other primary windows.

Opening Embedded Objects

The previous sections have focused on visual editing — editing an embedded object in its current location within its container. Alternatively, the user can open an embedded object into its own window. This gives the user the opportunity of seeing more of the object or seeing the object in a different view state. To support this operation, register an Open command for the object. When the user clicks the object's Open command, the object opens in a separate window for editing, as shown in Figure 12.24.

When the user opens an object in its own window, the container application should display the object masked with an "open" hatched pattern (lines at a 45-degree angle), as shown in Figure 12.25.

Format the title text for the open object's window as "Object Name in Container Name" (for example, "Sales Worksheet in Classical CD Review"). Including the container's name emphasizes that the object in the container and the object in the open window are considered the same object.

This convention for the title bar text applies only when the user opens an embedded object. When the user activates an embedded object for visual editing, do not change the title bar text.

An embedded object that is opened in another window is considered to be a different view of the same object that is in the container application. Therefore, when a user edits the embedded object, the edits should appear immediately and automatically in both the object window and in the container application. You do not need to display an update confirmation message when the user closes the open window. Nevertheless, you can still include an Update Container File Name command in the window of the open object to allow the user to request an update explicitly. This is useful if you cannot support frequent "real-time" image updates because of operational performance. In addition, when the user closes an open object's window, automatically update its presentation in the container's window. Provide commands to Close & Return to Container File Name or Exit & Return to Container File Name on the File menu to replace the Close and Exit commands.

If the object's application normally contains file operations, such as New or Open, remove these in the resulting window or replace them with commands, such as Import, to avoid severing the object's connection with its container. The objective is to present a consistent conceptual model; the object in the opened window is always the same as the one in the container. You can replace the Save As command with a Save Copy As command that displays the Save As dialog box, but unlike Save As, Save Copy As does not make the copied file the active file.

When the user opens an object, it is the selected object in the container; however, the user can change the selection in the container afterwards. Like any selected embedded object, the container supplies the appropriate selection appearance together with the open appearance, as shown in Figure 12.26.

The selected and open appearances apply only to the object's appearance on the display. If the user chooses to print the container while an embedded object is open or active, use the presentation form of objects; neither the open nor active hatched pattern should appear in the printed document because neither pattern is part of the content.

While an embedded object is open, it is still a functioning component of its container. It can still be selected or unselected, and can respond to appropriate container commands. At any time, the user can open any number of embedded objects. When the user closes its container window, deactivate and close the windows for any open embedded objects.