The OpenDoc User Experience

Dave Curbow and Elizabeth Dkstra-Erickson

OpenDoc, Apple's compound-document architecture, offers a new experience to users. This article gives developers a guided tour of OpenDoc's human interface and describes its conceptual model. We provide the necessary background for helping you fit your application into the OpenDoc world, and present some of the decisions you'll have to make that represent a departure from today's applications.

OpenDoc provides a new user paradigm: the user focuses on creating a document or performing a task, rather than on using a particular application. Understanding the OpenDoc user experience is a prerequisite to developing OpenDoc part editors that are consistent with and supportive of the OpenDoc design model. We've talked with developers at OpenDoc training classes who had written code without realizing what user features they had implemented; this article will provide a context for the OpenDoc code you write. The article describes the OpenDoc user experience on the Macintosh, but most of it also applies to Microsoft Windows and IBM OS/2.

Developer releases of OpenDoc are available through a number of different sources. The documentation provided in these releases, which includes the OpenDoc Programmer's Guide, OpenDoc Human Interface Guidelines, and the Drag and Drop Human Interface Guidelines, can give you much more detail on what's covered here (we concentrate on the basics, so a lot of exceptions aren't covered). Some of the technical basics of OpenDoc are also covered in the develop articles "Building an OpenDoc Part Handler" in Issue 19 and "Getting Started With OpenDoc Graphics" in Issue 21.

ALL ABOUT PARTS

OpenDoc provides an object-oriented user model, where documents are objects that contain other objects, and where each object may have distinct behaviors. However, object isn't a term that typical users understand in a document context, so we use part instead (for "part of the document"). Parts enable all kinds of content to be combined into a single document. The user sees each part as a self-contained entity with its own content, behavior, and set of properties. Each part contains one kind of data that's intrinsic to it, and may contain other parts as well.

PARTS AND DOCUMENTS

Every document consists of one or more parts: a single part at its top level, called the root part, and other parts that are embedded in the root part. Documents always reside on the desktop or in a folder -- that is, they appear in the Finder. (Parts embedded inside other parts aren't considered to be documents.) Users assemble a document by embedding parts as needed, with drag and drop or with the Paste and Insert commands, as we'll see later. Parts can be dragged between documents or onto the desktop (where they become documents); documents can be dragged from the desktop into other documents (where they become embedded parts).

The root part of a document determines the document's overall characteristics such as its basic editing metaphor (for instance, text, drawing, or spreadsheet), the size of its work area (its "page"), its printing options, and whether saving is manual or automatic.

PART CONTENT: INTRINSIC AND EMBEDDED

Every part has some kind of intrinsic content, as defined by the part developer. This is the content that's natural to the part, such as characters and paragraphs in a text part, or lines, circles, rectangles, and so on in a graphics part. In addition to its intrinsic content, a part may contain embedded parts that have their own intrinsic content, as shown in Figure 1.

Figure 1. A text part with an embedded graphics part

There's no requirement that a part be able to contain embedded parts, although it's usually desirable. Some parts have content models in which embedding doesn't make sense -- for example, sound parts or parts that display information, such as clocks or stock tickers. As a developer, you must decide whether it's desirable for parts you create to allow other parts to be embedded. But, a key characteristic of OpenDoc is that if a part can contain one kind of part, it can contain all kinds of parts. (Contrast this with traditional documents, which can contain only certain standard data types, such as text, PICT, and TIFF, in addition to their intrinsic content.) To a part, any parts embedded within it are "black boxes" -- parts need know nothing about the internal structure or semantics of embedded parts.

PART BEHAVIOR: EDITORS AND VIEWERS

There's little difference between the appearance of the OpenDoc window in Figure 1 and that of a similar window in a page-layout application of today; manipulation of the window contents, however, can be very different. When users interact with OpenDoc parts, the resulting behavior is determined by part editors and part viewers.

A part editor is a full-featured OpenDoc software component that allows the creation, editing, and viewing of parts of a particular kind, just as a conventional application allows manipulation of documents now. Like applications, part editors are sold or licensed and are legally protected from unauthorized copying and distribution. You supply users with the part editor (which the user installs in the Editors folder in the System Folder) and also a stationery pad (which the user will double-click or drag to create an OpenDoc document or part).

A part viewer is a special, limited type of part editor that can display and print a particular kind of part but can't be used to create or edit such a part. Often a part viewer will just be a part editor with its editing and part-creation capabilities removed. It's important that part viewers be widely available, to allow portability of OpenDoc compound documents across machines and platforms. We encourage you to create and freely distribute part viewers without restriction for all the kinds of parts that you support. Wide availability of a particular part viewer encourages purchase and use of its equivalent part editor, because users will know that other users will be able to view parts created with that editor.

Note that it may be possible to view a part even when neither its editor nor its viewer is present; translation may occur that substitutes a different, compatible editor. For example, suppose a user creates a document with a text editor named SurfWriter and sends it to someone who doesn't have the SurfWriter editor; the document is translated to a similar format supported by a text editor that the receiving user does have.

Users don't work with icons for part editors and part viewers the way they work with application icons today: editors and viewers aren't launched by double-clicking. So, as a distinct break from application icons, the icons for editors and viewers have a unique shape. This shape provides maximum customizable space for your identifying elements, with no required badges or identifiers such as hands and pencils (see Figure 2).

Figure 2 . The default part editor and part viewer icons

As a step toward becoming fully OpenDoc compliant (that is, becoming part editors themselves), some applications will be converted to container applications -- applications that allow parts to be embedded in their documents, much as some documents today allow the embedding of QuickTime movies.

Many of today's applications have plug-in or extension APIs that may be used to add functionality to the application. These will continue to be important to extending the capabilities of part editors.

PROPERTIES OF PARTS

All parts have a basic set of properties; these include the part kind, the part category, the view type (icon or frame, as we'll see in a moment), which editor to use, who last modified the contents of the part, and when the part was last modified. You may decide to support additional properties for parts that you develop -- for example, whether to keep a paragraph of text with the next paragraph. Some part properties, such as the view type, may be modified by users; other properties may be set only by developers or by the system.

Part kind and part category. Two critical part properties that you need to assign (in your part editor's 'nmap' resources) are part kind and part category.

• Part kind refers to the data format of a part's intrinsic content; it's analogous to a file's type. This property often has a name similar to the editor name. If the user changes a part's kind (with the Part Info command in the Edit menu), the part's content is translated to the new kind.

• Part category refers to a set of part kinds that are conceptually similar. OpenDoc uses categories to determine the set of part editors or viewers that are applicable to a given part, and to decide whether it's appropriate to translate data during inter-part editing (for example, when content is copied from one document into another). If a single part editor supports many kinds of data, these kinds are usually in the same category.

The list of categories is maintained by CI Labs, a consortium that coordinates cross-platform OpenDoc development; Styled Text and Video are two examples of part categories. If SurfWriter is a MacWrite-like text editor, its part kind might be SurfWriter Text and would be in the Styled Text category. The SurfWriter editor would most likely allow translation from other part kinds in the same category.

View type. Your part editor needs to assign the default view type for its embedded parts, which determines how each part is initially displayed: as an icon or in a frame.

• The icon for a part can be not only the standard 32-by-32- and 16-by-16-pixel sizes, but also a thumbnail icon (64-by-64 pixels). The thumbnail shows a miniature representation (a "poster page") of the part's contents to help users identify the part. Figure 3 shows the standard icons for a graphics part, and the thumbnail icon for a text part consisting of a one-page memo.

Figure 3. Icons for OpenDoc parts

• A part can be displayed with its contents in a bounded area called a frame, which allows editing in place (rather than requiring the part to be opened into a separate window). Frames are usually, but not necessarily, rectangular. A part's content may be displayed in more than one frame at a time and may have multiple representations; for example, a tabular part may be seen as a chart in one frame and as a text table in another.

In the Finder, documents are displayed only as 32-by-32- or 16-by-16-pixel icons in the initial OpenDoc release; eventually thumbnail icons and frames will also be supported at the Finder level.

Internally, all parts have frames, even when they're displayed as icons, but this implementation detail is hidden from the user and so is ignored in this discussion; here we use frame to mean only the view that displays the part's contents.

Users can change the view type with the Part Info command in the Edit menu (and possibly with "accelerator" commands, such as View as Icon, that are provided by the part editor). In Figure 1 above, frame view is desirable because it allows the user to see the graphic laid out in the document and to edit it in place. An icon view might be preferable for, say, a spreadsheet part that gives supporting data on a subject covered broadly in the text. Any frame may be reduced to an icon at any time, or any icon opened into a frame, without affecting the view type of any other part; however, the containing part may reflow content when an embedded part's view type is changed.

Except that a part may be edited only when its content is viewed in a frame, icons and frames are functionally equivalent. Operations such as drag and drop that may be applied to one may be applied to the other. Whether viewed as icons or in frames, embedded parts can be opened into separate windows if desired (although they're still embedded parts and not documents).

WORKING WITH PARTS

Now that you know some of the basics about parts, let's look at what it's like to work with them. We'll start with what the desktop might look like after the user opens the document shown earlier in Figure 1 (see Figure 4). Document icons on the desktop look the same as today, even though some of them, like the Text Document icon, represent OpenDoc documents. From the user's point of view, there's no apparent distinction between an OpenDoc document and a "regular" application document. The menus are those of the text part editor (because the root part -- a text part -- is active). The menu names are those you'd expect when editing text, except that the File menu is named Document, and the Application menu icon (to the far right) is a document icon rather than an application icon. Finally, notice the Stationery folder; this contains the stationery pads that the user double-clicks or drags to create documents or parts.

Figure 4. A Macintosh desktop in the world of OpenDoc

Now suppose the user wants to edit the content of this document's embedded graphics part. The first step would be to select the content to be edited, just as in applications today. To select the triangle, the user simply clicks it. As shown in Figure 5, a number of things happen: The graphics part editor highlights the selected graphics object by displaying handles. The graphics part becomes active (a border appears around its frame, its menus replace those of the text editor, and its tool palette appears). The text part is now inactive. Note that OpenDoc follows an "inside-out" model in determining which part to activate: it activates the smallest part that contains the mouse location.

Figure 5. The same desktop after the user clicks the triangle

Just as the content of a part may be selected for editing, an embedded part (which is content of its containing part) may itself be selected for certain operations. To select an embedded part, the user drags across it or, if the part is active, clicks its border. Figure 6 shows what happens when the user clicks the active frame border in Figure 5: The graphics part is selected and its border changes to show handles; the part that contains it -- the text part -- becomes active again. The menus are replaced by the text menus and the graphics palette goes away. (The same thing happens to the menus and palette when the user selects text in the text part, or clicks there to get an insertion point; in all cases, content that resides in the text part has been selected.)

Figure 6. Selected embedded part

In summary, parts viewed in frames can be active, inactive, or selected. This state is indicated by the appearance (or absence) of a frame border. Parts viewed as icons can be only inactive or selected.

• A part is active when it contains the current selection or the insertion location (which could be a visible insertion point, as in text, or an unmarked default location, as when the background in a graphics part is clicked). The selection may be within the part's intrinsic content or it may be a part embedded in the active part. When an embedded part becomes active, OpenDoc displays the active frame border -- a double dotted line -- around the part.

• A part is inactive when the user is working in some other part. When viewed in a frame, an inactive part has no visible frame border around it. (Note that when a part is inactive, its part editor can still be running; for example, if there's a part that searches a database, the user can start the search and go off to do other work in another part in the same document while the search continues.)

• Finally, a part may be selected. The user selects a part in a frame view by dragging across it, or by clicking its border if it's the active part. The containing part is responsible for the visual appearance of a selected part's frame; typically, the frame shows handles, to allow resizing. To select a part viewed as an icon, the user simply clicks the icon.

In general, as soon as the user clicks inside a part's frame, that part becomes active. The editor for the previously active part removes its menus, palettes, and other user interface elements, and the new active part's editor displays its user interface elements. The active part receives commands and keyboard events. Only one part at a time may be active within a document because, as in today's documents, there can be only one selection at a time.

RESIZING FRAMES

From a user's point of view, resizing a frame is similar to resizing an on-screen object today. A difference in OpenDoc is that the same frame may show different numbers of resize handles on its border when it's in different containers, because the containing part's editor determines the appearance of a selected-frame border. Your part editor may display more or fewer resize handles than other editors -- and perhaps none, if your editor doesn't allow the frame's size to be changed.

Your part editor also controls how much space an embedded frame occupies. When a user attempts to change the size of a frame embedded in your part, the embedded part negotiates with your part about the new size. Your editor may grant the requested size, reduce it, or refuse altogether, depending on its current contents and other part preferences such as snap-to-grid. The containing part also determines whether to adjust the layout of its own intrinsic content around the frame when a frame's size changes.

Some containing parts may require that embedded frames be rectangular, in which case their selection handles would resize only to rectangular areas. Others might allow embedded frames to be nonrectangular; for example, a containing part could provide selection handles that act independently, as shown in Figure 7.

Figure 7. Independent resize handles

When a user changes the size of your part's frame, you should not stretch or scale the contents of the frame, but rather just change the viewing area. (Note how this differs from the resizing of content, such as a selected graphics object, in which case scaling may well occur.) Figure 8 shows a table part in its original state and after resizing to a smaller size; the viewing area has become smaller, but the content hasn't been scaled.

Figure 8. A table part before and after resizing

Although we recommend against scaling when a frame is resized, for some parts scaling may make sense.

To see the entire table, the user can choose View in Window from the Edit menu. The table part then opens into a separate window (called a part window) allowing all its content to be seen, as shown in Figure 9. Although the part is viewed in a window, it's not a document -- it's still an embedded part. Figures 8 and 9 show views of the same content, and any changes made in one are reflected in the other views.

Figure 9. The table part opened into its own window

COPYING AND MOVING CONTENT

The user can copy and move any content with the Cut, Copy, Paste, and Paste As commands as well as a variety of drag and drop operations. All these commands and operations work with embedded parts as well as intrinsic content, and they work between parts in the same document as well as between different documents. Also, with drag and drop or the Insert command (in the Document menu), the source for a copy operation can be an entire document.

The Paste As command presents a dialog that allows the user to specify the data format to convert to when pasting. Holding down the Command key during drag and drop is the equivalent of Paste As; at the end of the drop, the Paste As dialog is presented.

Copied or moved content is inserted at the insertion location or replaces the current selection, with the exception that the Insert command inserts the contents of the document after the current selection.

The part editor makes "embed vs. merge" decisions in certain circumstances -- that is, whether to insert the copied or moved content as an embedded part or to merge it with the destination part's intrinsic content. For example, a copied text part would be merged into another text part but would be inserted as an embedded part in a graphics part. Users will most often want the part editor to make these decisions, but they can always override them with the Paste As command.

Links. The Paste As command, or its drag and drop equivalent, also allows links to be created. Links are special cases of the copy operation: OpenDoc updates the copy when the original content changes (the user specifies in what situations updating should occur). Both intrinsic content and embedded parts can be linked, and links can exist within a single part, between two parts in a single document, or between multiple parts in different documents. The same content can be linked to multiple destinations, but each link is technically one-way; every link has a single source and a single destination. Typically, only edits to the source of the link are allowed. Some part editors may allow edits to the destination (such as a font change); however, these edits will not persist after the destination is updated from the source.

OPENDOC MENUS

OpenDoc provides these basic menus when a document is opened: Apple, Document (replacing the File menu), Edit, Help, and Application. The other menus vary depending on which part is currently active. As we saw earlier, when a part is activated, the associated part editor installs its menus and any tool palettes or in-window controls. When a part (or the document window itself) is deactivated, the menus and palettes associated with the active part's editor are removed.

Note that when content is dragged into a frame, the part editor shouldn't install its menus unless the mouse button is released within the frame. For example, if the user selects some text in a text part and drags it into a graphics part, the initial text menus shouldn't be replaced until the user releases the mouse button within the graphics part.

Figure 10 shows what the basic menus might look like when a part whose editor is named SurfWriter is active. As you can see, the part editor has included its name in some of the commands. In the sections that follow, we'll look further at some of the commands in the Document and Edit menus.

Figure 10. The basic OpenDoc menus

DOCUMENT MENU COMMANDS

Most of the commands in the Document menu behave similarly to their File menu counterparts. Generally these commands refer to an entire document (the exception, Open Selection, is here because it's an open operation like Open Document). These commands should be augmented only if absolutely necessary, and only by the root part's editor.

Notice that the Quit command isn't included, nor should it be added; OpenDoc editors are unloaded automatically when no longer needed. Also note that we're recommending support for Save a Copy rather than Save As; Save a Copy keeps the current document open and active, and the copy remains closed until the user opens it.

The Document menu includes these new commands: Open Selection, Open Document, Insert, and Drafts.

• Open Selection opens a selected part into a part window, allowing the user to, for example, look at the contents of a part viewed as an icon. (Double-clicking the icon would also work.) Note that this command applies to the currently selected part and not to the active part, which is the part containing the current selection.

• Open Document is analogous to Open File: it lets the user choose a document (through the Standard File dialog) and open it into a window, just as when the document is opened from the Finder.

• With the Insert command, the user can choose a document (again, through the Standard File dialog) to insert into the active part. It inserts the contents of the document at the insertion location or after the current selection. This command may be used with a stationery pad to embed a new "blank" part.

• The Drafts command allows the user to take a "snapshot" of the current state of the document at any time, creating a draft that can be accessed (or deleted) later through this command. Drafts are stored efficiently, as differences from the previous draft, so there's little penalty for using them. Previous drafts are "preserved" historical versions of the document; they aren't "live" and must be copied out to be edited.

EDIT MENU COMMANDS

The commands in the Edit menu are used to edit contents of the active part -- for example, selected text or a selected embedded part -- or to modify properties of a selected part. Because different part editors may require different editing commands, the active part editor may add additional commands to this menu.

Undo and Redo work as usual except that they can be invoked successively -- that is, if the user chooses Undo three times in a row, the last three "undoable" actions are undone in order.

As described earlier, Cut, Copy, and Paste can be used to copy and move embedded parts as well as intrinsic content. The Paste As command lets the user specify the data format to convert to when pasting, and also includes an option for creating links.

The other commands of special interest in the Edit menu are Part Info, View in Window, and Show Frame Outline:

• Part Info displays a dialog for editing a selected part's properties -- for example, changing the part kind to another (compatible) part kind or changing the view type from icon to frame or vice versa. This command is replaced by Link Info if the user selects a linked part. If intrinsic content is selected, the part editor may change this command -- for example, to Paragraph Info or Circle Info.

• View in Window opens the active part into a part window. If the active part is already viewed in a window, this command brings that window to the front. (Remember that a selected part can be opened into a part window with the Open Selection command in the Document menu, or by double-clicking if it's an icon.)

• We recommend that you add Show Frame Outline to the Edit menu when a part in a frame view is opened into a part window. In the part window, this command puts an outline around the content that matches what's visible in the frame in the containing part, making it easier to correlate the two. The user can also drag the outline to change what's displayed in the frame in the containing part.

OPENING A WORLD OF POSSIBILITIES

OpenDoc revolutionizes the way developers deliver software, and does so without any dramatic upheavals to the user. OpenDoc part editors and container applications can coexist with applications and documents of today, providing OpenDoc's benefits without disrupting how users work with current applications. Your OpenDoc parts should behave much like current applications, so that users don't have to go through a substantial learning process. Our user tests show that users think OpenDoc simply fixes some "bugs" and lets them work the way they want. In other words, you and OpenDoc will provide business as usual -- plus.

---

RELATED READING

• OpenDoc Human Interface Guidelines, OpenDoc Programmer's Guide, OpenDoc Class Reference, OpenDoc Cookbook, and Drag and Drop Human Interface Guidelines. These documents will eventually be available in printed form but meanwhile are provided electronically with early releases of OpenDoc.

• The OpenDoc World Wide Web pages, located at http://www.cilabs.org.

• develop articles by Kurt Piersol: "Building an OpenDoc Part Handler," Issue 19, and "Getting Started With OpenDoc Graphics," Issue 21. (The term part handler used in these articles has since changed to part editor.)

• Apple Directions, "OpenDoc Your Mind" in the December 1994 issue, and periodic articles (including Q&As) by the authors, starting with the January 1995 issue.

DAVE CURBOW is the technical lead of the OpenDoc Human Interface team. Before that he worked on AppleScript and developer tools such as ResEdit. In an earlier life he was a software engineer on the Xerox Star and a now-forgotten mainframe operating system. When he escapes from the office, Dave can often be found working with his wife on their house or exploring cathedrals, castles, and other wonders in England (including the Kew Bridge Steam Museum). It's well known that Dave can be bribed with dark chocolate.

ELIZABETH DYKSTRA-ERICKSON is a recent addition to the OpenDoc Human Interface team. She comes to Apple from research and product development in collaborative technology and interactive multimedia at US WEST Technologies, Pacific Bell, and the University of Amsterdam. In her copious free time, she teaches human-computer interaction at the University of San Francisco, conspires to resurrect her 1980's tech-punk band, and marvels with her husband at the havoc potential of their two-year-old daughter.

Thanks to our technical reviewers Dave Bice, Tantek Çelik, Ray Chiang, and Lori Kaplan, and to the OpenDoc Human Interface teams at Apple, Claris, IBM, and WordPerfect, especially Sue Bartalo, Kristin Bauersfeld, Dick Berry, Alex Bigney, Jennifer Chaffee, Pat Coleman, Dan Jordan, Jeff Kreeger, Per Nielsen, Kerry Ortega, David Roberts, David C. Smith, Mark Stern, Mike Thompson, and Ron Zeno. Special thanks to Dave Bice for providing source material for this article.