June 95 - According to Script: The OpenDoc User Experience
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
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
- 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
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
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
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
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
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
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.
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
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
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 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
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
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
- 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
- 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
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 --
- 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.