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 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 thedevelop 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