Designing the OpenDoc® Human InterfaceDave Curbow

Human Interface Design CenterApple Computer, Inc.

1 Infinite Loop MS 302-1HICupertino, CA 95014 USA

curbow@best.com

Elizabeth Dykstra-EricksonHuman Interface Design Center

Apple Computer, Inc.1 Infinite Loop MS 302-1HICupertino, CA 95014 USA

+1 408 974 6462eade@apple.com

ABSTRACTThis paper tells the story of the development of the humaninterface for OpenDoc, a large-scale, complex, cross-platform commercial development project at AppleComputer. OpenDoc was an ambitious four year design anddevelopment effort by Apple with IBM and other partners.The OpenDoc HI is a departure from traditionalapplications. This historical review highlights how wedesigned OpenDoc and the lessons we learned.

KeywordsOpenDoc, design process, user-centered design, humaninterface specification, collaboration

INTRODUCTIONOpenDoc is a development platform, and thus is verycomplex — designing it was more like designing anoperating system than designing a new application. It wasan ambitious and visionary project for Apple, involving amassive effort with complex logistics and politics. Itsdesign posed a number of very unusual HI challenges.Like most projects of this size, OpenDoc had a multi-yearincubation period; it involved cross-disciplinary teams; andit followed user-centered design principles. Unlike mostprojects at Apple, it has had a cross-company collaborativedevelopment team. It continues to exhibit one of the bestmodels of team behavior. Also, it is one of Apple’s mostthoroughly documented new technologies, due to a rigorousand finely-grained HI Specification. The success of thisproject influenced the HI design process at Apple.Briefly defined, OpenDoc is an object-oriented softwaredevelopment architecture that enables software developersto create component software used in compounddocuments. It allows a user to create and edit documentscontaining virtually any kind of content — e.g., text,graphics, tables, spreadsheets, sound, video, virtual reality,and network and internet connections. These are referred toas parts and manipulated via part editors (see Glossary atthe end of this paper). Most compound document systemshave a similar appearance. OpenDoc’s advantage is its

support for the creation and manipulation of compound,collaborative, and customizable documents on multiplecomputing platforms. It replaces data import and exportfunctions with edit-in-place and drag-and-drop for addingand changing content.Our goal was to develop an open standard for distributedcomponent software which would interoperate with otherarchitectures, such as Microsoft’s OLE. A standards body,CI Labs1, was established to own the technology beingdeveloped.The majority of this paper will consist of a description ofthe development of OpenDoc from the initial concept to itsimplementation. We'll break our discussion into threephases -- investigation, design, and implementation — thatcorrespond to the internal development process. As we givethis account, we'll occasionally pause to reflect on theutility of various decisions. After a description of theprocess, we'll step back and reflect on the lessons of theOpenDoc project for HI Design.Because this is a vast project, we can't provide all thedetails; instead we'll focus on four themes that will be ofvalue to other HI designers: leveraging existing research,the role of documentation in development, the politics ofdevelopment and inter- and intra-company collaboration.

PROCESSFirst we’ll give a quick sketch of the development processfollowed by OpenDoc. Next, we'll discuss the make up ofthe HI team over the course of the project. Finally, we’lldiscuss our work during each phase of development.

Design Process SketchThe typical Apple development process begins with theConcept phase — that’s when an idea for a product isbriefly outlined for management approval. Often, the realgenesis of an idea occurs long before this presentation. ForOpenDoc, the genesis occurred in the mid ‘80s when JedHarris, a researcher in Apple's Advanced Technology

1Component Integration Laboratories, Inc., is a nonprofit

association dedicated to promoting the adoption ofOpenDoc as a vendor-neutral industry standard forsoftware integration and component software. See http:www.cilabs.org.

Group (ATG) formed an informal team to examinecomponent software. One of his team's key ideas was thetransition from an application-centered paradigm to acontent-centered paradigm (automatically invoking

whatever components are required to handle the content).This research continued in ATG until Jed moved to productdevelopment where he put together a small team that madea Concept proposal to management in mid-1992.

Concept Phase

DesignInvestigation ImplementationCustomer “Wishes”

Design Validation -

User Studies, Reviews

Engineering Feasibility Analysis

HI Refinement

Future Releases -HI Refinement

Market Research

HI Best Guesses& User Studies

Conceptual Model &HI Design

Feature Set

Released Software

Engineering Design & Impl.

Research

Figure 1. Software Design ProcessFollowing management approval of the Concept proposal, aproduct team was formed for subsequent stages of productdevelopment. Figure 1 shows a schematic of these phases,and associated tasks from an HI perspective.The goal of the Investigation phase was to determine ifOpenDoc could be successful, if it would make a goodproduct for Apple. It was during this phase that a smallnumber of HI designers and engineers joined the team. Ourtwo primary tasks were to perform the initial research andcreate a design sketch of what the product might look like.This work is represented in Figure 1 as the Research task— discussed later in detail.Table 1 summarizes the major phases and deliverables fromthe HI team during the development process.Phase HI Deliverables Duration

Concept Management Presentation N/AInvestigation 1) Research Requirements

2) Design Sketch3 months

Design 1) Conceptual Model2) HI Specification

11 months

Implementation 1) Revised HI Spec2) HI Guidelines

15 months

Post Release 1) User Studies2) Revised HI Spec

Ongoing

Table 1. Phases and DeliverablesAt the end of the Investigation phase, management agreedthat we should continue to the Design phase and providedfunding for additional HI designers, engineers, marketingand support staff.During the Design phase, our goal was to create a completedesign, one that Engineering could begin to implement. Webegan by reexamining our prior research, looking forloopholes and filling in the gaps. Also, it was during theDesign phase that we began working with designers fromour partners. This is discussed in detail in the section,Design Review.When we were able to deliver the HI Specification toEngineering, the project entered the Implementation phase.During this phase, Engineering built the product accordingto the specification, while Quality Assurance checked fordeviations between the product and the specification. Wecollaborated with these other teams to design solutions tothe problems and shortcomings found — and wecontinually revised the specification.Because OpenDoc is a technology intended for developers(see Glossary), we targeted our releases for developer-specific milestones, for example Apple’s World WideDevelopers Conference held each April and the MacworldExpo/San Francisco held each January.

HI Team CompositionNow we'll describe the various kinds of HI specialistsworking on this project. Interaction designers wereresponsible for creating the conceptual model andappropriate behaviors. The HI Architect was an interactiondesigner. Visual designers provided visual designs andfeedback on interaction design. Usability specialists createdplans and studies to provide supporting and confirming datafrom user studies. Our Prototype Builder was skilled atquickly building prototypes which could be used to try outdesign ideas or during early user studies. Figure 2 showshow the balance of specialties shifted during the course ofthe project. The designers labeled “Non--Apple Designers”were from our partner companies.

2

4

6

8

10

12

Non-AppleDesignerUsabilitySpecialistPrototypeBuilderVisualDesignerInteractionDesigner

Phases:A. InvestigationB. DesignC. Implementation

# of Designers:

A B CFigure 2. Number of HI Designers Over Time

For example, during the Design phase, we needed skillssuch as a Prototype Builder and Usability Specialists.These additional people also helped when brainstormingpossible design ideas. However, during the longerImplementation phase we reduced the number of HIdesigners because our needs changed — we no longerneeded the prototype builder and we needed fewer usabilityspecialists. During this phase we continued to revise thespecification and run user tests. Our team had fourinteraction designers plus occasional support from VisualDesigners and Usability Specialists. The number ofdesigners among our partners also decreased slightly, forthe same reason. However, the number of people weworked with increased. For example, a large number ofengineers, product marketing specialists and evangelists(see Glossary) were added during this phase.

ResearchNow we will discuss in detail the research work doneinitially during the Investigation phase and refined duringthe Design phase. This research was subdivided intoseveral tasks and deliverables, as summarized in Table 2.Although some of these tasks had dependencies on priortasks, we were able to do some work in parallel. Each taskrepresents major milestones for the HI team in thedevelopment process and is discussed in more detail below.

Identify Target UsersOne of the first tasks was to accurately identify the targetuser population for OpenDoc. During the Investigationphase we made some educated guesses. But, during theDesign phase we had to do better. To get an accuratereading of our target user population we worked with theOpenDoc marketing specialist. He identified desktoppublishing, K-12, higher education, and smallbusiness/home office as primary target market segments.He then brought us together with several Apple marketspecialists, for example, someone responsible for Apple’sK-12 business. These specialists, through their ongoingresearch, had a wealth of information available about usersi n t h e i r p a r t i c u l a r m a r k e t s e g m e n t .

Research Tasks Deliverables

Identify target users User MatrixIdentify user tasks ScenariosIdentify user needs 1) User Needs document

2) User Needs matrixIdentify issues in meetingfeatures

Issues Database

Survey Apple technology 1) Issues Database2) User Needs document

Perform competitiveanalysis

1) Reports on competingproducts2) User Needs3) Issues Database

Table 2. Research TasksThey did not gather this data explicitly for HI design. Thus,it was important for us to work closely with the marketingspecialists for their interpretation of this data. They helpedus to better understand the user population, their tasks andneeds. For example, the publishing market specialist told usabout the need to provide control over color separation forthat market. From the data we collected from marketingspecialists, we were able to characterize first-time, novice,and experienced users within each market segment. Thesecharacteristics contributed to user profiles that we used towrite task scenarios, identifying typical user tasks. We usedthe profiles and scenarios to generate product features andto support design decisions.

We developed a user matrix to document and contrast usercharacteristics for first time, novice, and experienced usersaccording to the tasks we could expect them to be able toaccomplish using OpenDoc. Here are some examples ofthose user characteristics:

First-Time Computer User• Can learn how to create compound documents• Doesn’t want advanced capabilities to get in the way of

getting started with compound documents• Doesn’t expect to do advanced operations such as

linking and scripting (see Glossary)

Novice Macintosh User• Can use multiple parts in a document, but only those

originally installed• Can use stationery• Does not know about the concept of “part editors;” only

sees and uses parts• May be using “At Ease” or other non-Finder

environments

Experienced Macintosh User• Can install new part types onto the system.• Can use multiple editors and switch between editors in a

document• Can use library of parts and stationery• Familiar with scripting and interpart communications

capabilities• Very familiar with all basic Mac and most advanced

featuresDeveloper• Can deliver new part types and associated editors to

usersToday, four years since the beginning of the OpenDocproject, we’ve found this early documentation still veryuseful. Consulting it has helped us understand why someusers have problems using OpenDoc — there areoccasional mismatches between our user definitions andactual users. For example, we believed that noviceMacintosh users would be familiar with and able to usestationery, but we’ve been surprised to discover throughuser testing that this is not true. This limitation does not,however, hold for OpenDoc on all platforms. In contrast,OS/2 users are more familiar with stationery, although theyuse the term templates. We also learned that severalfeatures of the MacOS we characterize as fundamental arenot used by novices, such as marquee selection and openingfiles via the Standard File interface. After recognizing ourmistakes, we worked with Apple Instructional designerswho created materials to educate novice users.In retrospect, we believed that users were somewhat moresophisticated than they proved to be. We see two solutionsto this problem — 1. Refine our user profiles. 2. Provide

additional instructional materials to users for use duringuser studies and actual use.Our companion paper, Role of User Studies in the Designof OpenDoc (this volume), provides additional informationon this topic.

Identify User TasksGiven a model of our target user population, we set aboutto identify user tasks. We did this by way of first buildingscenarios of use and then deriving user tasks from them.We identify user tasks by determining exactly how a userperforms a job. Explicitly describing the steps taken byusers when performing a task provides details of theinformation and process flows. Knowing these steps helpsus to better determine users' needs so that the system wedesign can effectively address those needs.

Generate ScenariosThe OpenDoc Human Interface team generated ten sets ofuser task scenarios to develop a better understanding ofwhat an OpenDoc user might need. In the ideal situation,we would write up user task scenarios from fieldobservations. We would collect empirical data to obtain adescription of the task and develop an understanding ofuser needs. However, we could not have conducted a fieldstudy without having had to create both OpenDoc andthird-party components which used it. This was clearly achicken-and-egg problem!2 Ultimately, we used generated(rather than observed) scenarios in the OpenDoc project.We were comfortable using such an approach because wewere able to supplement actual test results with competitiveanalyses of similar existing systems, such as the XeroxStar. For example, we were able to determine that usersliked compound documents and edit-in-place. Also, welearned that the inside-out activation model (see Glossary)worked well, but users had some problems selectingembedded objects. Based on this, we determined that wewould make selection of embedded objects easier inOpenDoc than in the Xerox Star.

Derive User TasksWe identified user tasks independently from systemconstraints and focused instead on the users' needs. Thisallowed us to think of new design solutions to users'problems. In particular, the task descriptions did notpresume a system design (except to describe a system theuser may currently be using), but instead uncovered theunderlying needs the user has, independent of how he orshe may be satisfying that need today (e.g., with a currentsystem).

2OpenDoc 1.0 was released December 1995. Field studies

were designed early but are only just recently in planning,made possible by the availability of mature end-usercomponents.

Identify User NeedsBy analyzing the user tasks, we were able to identifyspecific user needs. We documented these needs and usedthem to derive the OpenDoc feature set. The following isan example of the user needs identified via user taskscenarios.• Coexist with today’s applications• Transfer existing skills• Able to select data• Natural way to deal with and edit content of different

kinds in a document• Transfer data from non-OpenDoc to OpenDoc

documents (and vice versa)• Easy management of different parts of a document (e.g.,

in situ editing, drag and drop)• Need a clear input focus (i.e., feedback)• Clear feedback to user of boundaries that affect

content's behavior or appearance• Have all parts of compound document in one file and be

able to modify each part• Easy to add new kinds of data to the document,

including kinds not yet invented• Need to transfer data from and to documents,

irrespective of kind• Able to change form, appearance, shape and other

attributes of parts and contentBecause we characterized users as we did, we were able todesign for different categories of users. For example,experienced users may need to check to see what OpenDoceditor is being used to edit a particular part, while noviceusers would not have this need. The design implication hereis that we could use progressive disclosure to revealadvanced features of simple tasks, thus moving complexityaway from the novice user but still making it available toexperienced users. Likewise, one class of users may needcapabilities not needed by any other class. For example,users in the desktop publishing market segment may needcolor separation capabilities while few other user will. Thedesign implication here is that we needed to be able toextend controls for certain markets, resulting in OpenDoc’svery flexible plug-in architecture.

Identify Issues in Supplying FeaturesIn the course of many meetings and discussions to workwith the data we collected and build the scenarios, we werecontinually identifying design issues that needed to beresolved. As we began designing the conceptual model, wehad identified approximately 100 issues. Some were clearlyrelated, and we needed a mechanism that allowed us tomake sense of the relationships. We chose to group relatedissues. To do this, we used the "post-its on the wall"method. That is, we wrote each issue on a sticky note andposted it on the wall, looking for obvious groupings. This

method allowed us to easily move issues around andregroup.We used this set of sticky notes to develop a simple issuesdatabase to track issues, their design implications, and theirresolutions. This repository, similar to those maintained bycertain design rationale support tools such as IBIS or DRL[1], was structured but informal. Recognizing that someissues were clearly more important than others, weinstituted a simple priority system. This way we were ableto make certain that we factored high priority issues intothe design before lower priority ones. We continued addingissues until the Design phase was complete. Table 3 showsan example of HI issues.

Survey Apple TechnologyWe knew that various groups within Apple had previouslyinvestigated many aspects of component software andcompound documents. In addition, we knew that Apple haddelivered, or was about to deliver, several technologies thatwe could use to support OpenDoc. The engineering and HIteams examined this work for relevance to OpenDoc and,when appropriate, we influenced the design of theseproducts. For example, the DragManager (supports drag &drop between applications) was being developed in theearly days of OpenDoc. In our third user study, we receivedstrong feedback that users felt drag & drop was verypowerful and easy to use. Based on this, we decided that itwould be an important technology to include in OpenDoc.Thus, we worked to influence its HI design andimplementation.

Perform Competitive AnalysisWe analyzed competing products, to see if there were userneeds that we had overlooked. Products we analyzedincluded the Xerox Star, Microsoft OLE and the OLE 2.0prototype, Taligent’s “PINK” project, ClarisWorks andClaris Impact, as well as several early Apple researchprojects.User Model of Parts

High Prioritypart metaphor (tool, container, accessory?)multiple views of same partcan any part be opened anywhere? what happens?where can part frames appear (on desktop, indocument)?where can part icons appear (on desktop, in document)?interaction with desktop modelMedium Prioritypart editors (a user visible concept?)direct manipulation of parts

Table 3. HI Issues

One of our conclusions was that the Xerox Star dealt with alarge percentage, but not all, of the same issues thatOpenDoc was facing. It had been widely used for severalyears by several thousand users and so had been refinedextensively. We were able to follow up our competitiveanalysis by interviewing two of the principle designers ofthe Xerox Star. We asked questions like, “Were therethings in the design that now appear to be mistakes?” Wewere also able to identify a few users of some of the otherproducts and interview them. The data gathered wasrecorded in papers and the Issues database.

DesignNow we will talk about creating a design, based on the datagathered. Table 4 summarizes the steps in this process.Completing these tasks required several months.

Map Needs To FeaturesThe first step in the design process was to define a set offeatures that satisfied the user needs identified previously.Sometimes simply looking at a set of needs suggested a setof features; for example, the need for users to transfer skillsfrom today’s applications, as well as for OpenDoc tocoexist with today’s applications, suggested that we reuseas many of today’s designs as would work in OpenDoc.Thus, we kept Cut, Copy and Paste, but modified them towork seamlessly with content containing embedded parts.Other features were suggested by examining our survey ofprevious Apple research and our competitive analysisreports.In an effort to keep the feature set as small as possible, yetstill cover all the user needs, we created a 35x99 matrix ofUser Needs by Features. A portion is shown in Table 5.This matrix allowed us to:• Understand the relationship between user needs and

features• Effectively modify or design new features by easily

referring to the user need

Design Tasks Deliverables

Map Needs to Features Input to Feature SetCreate Conceptual Model 1) Conceptual Model

document2) Prototypes

Develop Usability Goals Usability Goals documentDevelop SpecificPerformance Criteria

1) Usability Test Plan2) PerformanceRequirements document

Document the Design 1) HI Spec2) HI Notes3) HI Guidelines4) Platform Checklist

Document the RationaleBehind the Design

Design Rationaledocument

User Tests 1) Test Plan2) Test Prototypes3) Test Results &Recommendations

Review Design with:1) Engineers & Marketing2) Apple HI teams3) External Partners4) 3rd-Party Developers

1) Revised HI Notes2) Revised HI Spec3) Issues Database

Work with CI Labspartners to makeOpenDoc cross-platform

Consultation to1) IBM2) WordPerfect/Novell

Table 4. Design Tasks

CopyCopy via DragDeleteUndoRedoShow PropertiesChange Properties

Editing Parts

User Needs

Features

1. Select data!2. Edit naturally! ! x3. One compound file!4. Easy part mgmt! x x x x 5. Easy to add parts

Table 5 . User Needs by Features Matrix• Identify "holes" in the feature set (when a need has no

feature to satisfy it)• Identify unnecessary features (when a feature has no

corresponding need)• Identify redundant features (when two or more features

satisfy the same needs)• Effectively design and focus our user testsFeatures in this matrix were grouped to make it easier tofind related features, as above where we show a portion ofthe “Editing Parts” category. The features and theircategories map directly onto the description of the featureslater written in the OpenDoc Human InterfaceSpecification.

Create the Conceptual ModelThe Concept phase is generally short and determines if aproject should go forward. We created an initial design andproduced a User Experience Document and a MacromediaDirector® prototype that illustrated the user experience.

As we began the Design phase — during which we dugdeeper into the requirements and double checked our initialfindings and recommendations — we also produced severalnew documents reflecting the volumes of data we hadgathered.The first step in creating the OpenDoc HI design was tocreate an appropriate conceptual model. To do this, we firstidentified the features and related issues that were mostimportant and attempted to create a coherent design thatsatisfied all of them. We began by brainstorming, sketchingon a whiteboard and creating rough prototypes.As we were creating the conceptual model and laterfleshing out the rest of the design, we followed a fewdesign principles:• Make it possible for users to reuse as much as possible

of their knowledge of today’s applications and apply itto using OpenDoc

• Avoid surprising the user• If two things look very similar (conceptually, visually),

strive to MAKE them the same — or very distinctAfter writing a document describing a coherent conceptualmodel, we began to create the HI Specification for all thefeatures, showing how they fit into the conceptual model.To do this, we examined the feature set and issues databaseagain, looking at the lower priority features and relatedissues.There are clear dependencies between components of theconceptual model. Figure 3 (below) shows a fewcomponents. These dependencies mean that if we modifythe design of one component, we must examine the designof dependent components and then possibly modify them tobe in alignment with the higher priority component. For

Goals Methods Measures

Improved ease of use Drag & drop all overEdit in place

task timingserror rate

Improved learnability Easy user modelProgressive disclosure

task completion rate with and without tutorials and/orassistance

task timings with and without tutorials and/or assistanceFunctionality matches user

needs and tasksField study (in planning) user satisfaction ratings (in planning)

Table 6. Usability Goals

example, if we made a change to the Activation model, wewould need to revisit the design of Content Selection, PartSelection, Menus, Sense of Place, etc. Likewise, if we

made a change to Drag & Drop, we had to double check theActivation Model, Sense of Place and Undo. You’ll noticethat most of the dependencies are one way, but two of them

Menus, Tools, etc.

Basic Document Model(Special paper vs. Plain paper)

Content Selection

Part Selection

Cut, Copy & Paste

Undo

Drag & Drop

Activation Model(How to Edit content)

Sense of Place

Document Creation Save Model

Adding Content

Figure 3 . A Fragment of the Conceptual Model: Issues and their Dependencies

are two way — Content and Part Selection. Modifying thedesign of either of these components required that weexamine and possibly modify the other component.In fact, we never created a complete diagram, but juggledthis information in our heads. At one point, we counted thenumber of components in the model — it was about 200items, far too many to easily remember. We now realizethat keeping this map in our heads was a mistake, for notall the relationships were obvious, and we spent much time“remembering” these dependencies.

Develop usability goalsAfter developing a conceptual model, we began work onusability goals. An excerpt from the OpenDoc UsabilityGoals dated 11/9/92 is shown in Table 6. We used thesegoals to direct user studies performed throughout the designprocess.These goals are general and were used to construct morespecific Usability Objectives. Table 7 shows an excerpt ofdocument-centered usability objectives. These objectivesled directly to the design of specific user studies.

Compound Document Objectives

1. Develop more natural application/documentparadigm2. Support natural interaction with parts3. Develop effective selection model4. Seamless integration with current system5. Effective and natural use of pasting and linking

Table 7. Specific Usability ObjectivesWe believed it was important that users be able to quicklyuse OpenDoc, so we tried to facilitate transfer ofknowledge from the current Macintosh UI to the OpenDocUI. However, we also recognized that there are someproblems that are not well handled by the Macintosh UI,and better solutions would require users to learn a newmodel.This was reinforced by an early conversation with AppleFellow, Alan Kay. He reminded us that it is important forusers to explore their environment, and to learn about itscapabilities. One example of how we took this to heart isour use of progressive disclosure as a means of hidingcomplexity, relying on users to explore the system.

Develop specific performance criteriaTable 8 illustrates the performance criteria determinedjointly by the HI and Quality Assurance teams, based onMIL-STD-1472C [2]. The engineering team used these ascriteria for deciding between implementation alternatives.When OpenDoc 1.0 shipped, all but the launch timecriterion had been met.

Event Performance Goal

Part Activation* .2 - .4 secFrame highlight when dragover

.1 sec

Resize/Reshape Frame Reshape frame must followpointer in real time wheremouse velocity ≤ 200pixels/second

Open Document ≈ 1 secNew Part Creation 1. Via Paste

<.5 sec (no translationneeded)<2 sec (simple translation)2. Via Drag-and-Drop.5 - 1 sec

Menu command completion 1. Editing Cmds,Formatting/Layout [≈1sec]2. Close Document (nosave dialog) [< 3 sec]3. Link propagation (Doc A-> B real time update) [< 3sec]

Activate / Deactivate Frame(change focus)

Frame hilight when cursormoves into frame .1 sec

Open Part Property Sheet < 1 secDrag / move part withindocument

Same as Resize/Reshapeframe

* Frame Highlighting, palette & menu switch

Table 8. Performance CriteriaDocument the DesignOpenDoc was not the first object-oriented componentsoftware product. Several members of the team werefamiliar with the Xerox Star and the design process used inits creation, as described in the 1982 Byte article,Designing the Xerox Star User Interface [3].The “bible” of that project was the “Star Functional Spec,”a very detailed specification that spelled out the behaviorand appearance of the finished product. Oftenspecifications are vague enough that there is room forinterpretation; this was not the case with the StarFunctional Specification. During their implementationphase, the Xerox engineering staff discovered that theycould not implement some behaviors exactly as specified.New designs were created, but the specification was notrevised to reflect the changes. As a result, there wasn’t asingle document which specified the human interface for

the product. Later this was recognized as a flaw in theprocess.The OpenDoc HI team resolved to deliver a similar HISpecification, but keep it always up to date. This turned outto be a key decision. This document, plus the HI Guidelinesand the Design Rationale (both described later), wereinstrumental in guiding the OpenDoc implementation.Much of the information in these documents also becamepart of the OpenDoc Programmer’s Guide, the publiclyavailable developers’ resource book.Writing The HI SpecificationGiven the Conceptual Model paper, plus information in thefeature spec and the issues database, two senior HIdesigners wrote an initial draft of the HI Specification.Once we had written this draft of the spec, we realized wehad overlooked several issues. As a result, the team spentseveral more months investigating issues and reworking thedesign and specification. The spec had many holes to fill.So, each interaction designer was made responsible forcompleting the design of various sections.We sifted through the mountain of data, and talked withother HI designers and the engineers. We reused existingdesigns where applicable and brainstormed new ones. Werecorded everything — even sketches from brainstormsessions. We used a whiteboard that produced a printedcopy, and we signed, dated and filed a copy in case of legalneed later.Each designer’s objective was to write a formal HI Note foreach feature for which they were responsible. In this note,they laid out design alternatives, and their pros and cons.Next, the entire HI team reviewed the work. The teammight accept a recommendation, or employ a user study tochoose between alternatives. Engineering was responsiblefor qualifying the implementability of these decisions.Finally, we updated the specification. To date, there are 36OpenDoc Human Interface Notes each addressing adifferent set of issues. These HI Notes also continue toserve as repositories for information that needs to beincluded in future versions of the specification orguidelines.The HI Specification is 211 pages describing the interactionand visual behavior of OpenDoc -- down to the level ofmouse events and pixels. It includes sections on:Conceptual Model of Documents and PartsPart IconsPart FramesEditors and ViewersMenusInteraction with non-OpenDoc documentsWindowsPart CategoriesPart Properties and SettingsPreferencesViewing a PartChanging a Part’s Representation

Selecting Parts vs. content in a partActivating a FrameEditing a FrameCut, Copy and Paste - additional behaviors for OpenDocDrag and DropCreate, Delete, and UndoStationery/TemplatesDocument and Part NamingInstalling and Removing EditorsDocument Versioning (Drafts)LinkingScriptingExtending OpenDoc with Plug-Ins and ServicesAdapting OpenDoc to other platformsThe specification addresses each of these aspects of thehuman interface and examines it in terms of its definition,guiding metaphor, behavior and states, visual appearance,and interaction with other interface elements. Thespecification addresses in particular the user’s conceptualmodel and step-by-step user interactions. In contrast, the HIGuideline omits most user behaviors and concentratesinstead on what developers must do to implement thespecified system.HI GuidelinesWhile we were writing the specification, we recognizedthat we would need to write guidelines for developers. Sowe began writing that document, and we revised it severaltimes over the next 3 years.By the time of the publication of the OpenDocProgrammers Guide [4], 107 pages of that book weredevoted to new or revised HI Guidelines. We alsoinfluenced the guidelines for other Apple projects and aforthcoming edition of the Macintosh Human InterfaceGuidelines [5].

Document Rationale Behind DesignNear the end of the Design phase we produced a DesignRationale document, capturing the information on whichwe based our decisions. We wrote it without knowledge ofthe formal method known as Design Rationale, althoughwe later discovered some overlap with this method.Our purpose in writing our Design Rationale was to supportthe review process (discussed below) and to provide futureteam members with answers to questions about designdecisions. We intended this document, and the other data inour archive, to provide a rational basis for making changesin the future. The archive, currently over 450 MB, ofpapers, email, and prototypes is used by team members as aresearch source. Work continues on the OpenDoc HIdesign, so periodically a new CD is pressed and distributedto team members and other interested groups.

User TestsDuring the Design phase, we ran four user studies to gatherinformation about user tasks and our initial design ideas.Two of these were paper-and-pencil tests. We also used a

Macromedia Director® prototype to determine if userscould understand the basic interaction model.In the middle of the Design phase we constructed aprototype in C to allow us to test our Drag & Drop model.A couple of months later we were able to begin usingprototype code written by the engineers, rather thanbuilding our own. This allowed us to perform morecomplete user studies. Later in the Implementation phase,we ran six more user studies.

Design ReviewDuring the writing of the HI Specification, there were dailyinformal reviews between HI, Architecture andEngineering that shaped the design. There were also twokinds of formal reviews:• Review by engineering for feasibility• Review of user needs, features and designsWhen we released the first draft of the HI Specification,engineering went over it with a fine-toothed comb, lookingfor features that would be impossible to implement asspecified. We had a formal meeting where the engineeringteam talked about specific difficulties and recommendedmodifications. We produced a second draft of the spec,incorporating their feedback.Next we sent the HI Specification and Design Rationale toHI designers and researchers throughout Apple for theircomments. At this review we defended the design,answered questions, recorded problems found andsuggestions made. Afterwards, we wrote another draft ofthe specification.Now that we had created a coherent, written specification,we were ready to go back to external parties for theirreview. In particular, we requested feedback from 3rd-partydevelopers who had given us input early in the process.These reviewers reported problems such as overlooked userneeds, and they suggested design alternatives. We cameback to these developers several times over the next coupleof years.We also began meeting with our partners in CI Labs—IBM, WordPerfect, Novell, Sun, etc. They helped usunderstand other platforms and special requirements. Weconducted periodic face-to-face meetings and establishedan email mailing list to discuss issues and solutions.When we started talking publicly about OpenDoc (thenknown by the code name “Amber”) we gave out hundredsof copies of the HI Specification. At that time many Appledevelopers started asking questions and making suggestionsthat helped us to further refine the design. Later, after theWindows- and OS/2-specific specifications were released,we received feedback from those developer communities.

Work With Partners on Other PlatformsThe first step in porting the Apple design was taken by HIdesigners at our partner companies. They reviewed theMacintosh OpenDoc HI spec and identified conflicts and

shortcomings. We then collaborated on a solution —deciding either to make a change to the Apple design, or toadd a feature to their platform. We did not use a leastcommon denominator approach to design, but rather a topdown design process.During this review process, we realized that much of thedesign of OpenDoc for Macintosh could be “ported” to theother GUI platforms with few changes because theMacintosh was largely a superset of other GUIs. However,there were a few mismatches, and we found ways toresolve them. If a feature was missing on one platform, weinvestigated how we might add it. For example, UNIX doesnot support the concept of stationery — a key componentof OpenDoc. It was added to IBM’s implementation ofUNIX, known as AIX.Occasionally, other platforms provided a key feature in away that was very different from how it is provided on theMacintosh. For example, where Drag & Drop exists, itbehaves very similarly — except that the visual feedback isvery different. In cases like this, we abstracted the designand permitted a variance. That is, we specified the featurein sufficient detail that each partner was able to create adesign that satisfied that feature for their platform. Anotherexample is the OS/2 standard for menus. This requiredmenu commands to be organized differently from theMacintosh design. Thus, we created a variance for menucommand arrangement, but not for the commandsthemselves.We were concerned that there should be one identity forOpenDoc, with no large differences between the differentplatform implementations. To this end, we created aPlatform Checklist. This checklist specified the basicdesign of features that make up OpenDoc and must bepresent on all platforms claiming to support OpenDoc.

ImplementationThe HI Specification became the “bible” for OpenDoc. TheQuality Assurance team refused to pass the implementationof a feature unless it matched the specification. As a result,engineers coded closely to the specification. In fact, if theywere asked (even by HI) to make a modification, theyrefused to do so until they saw it in the HI Specification.This forced us to keep the specification up to date.We actively encouraged QA and Engineering to issue bugsagainst problems and underspecified features in the HISpecification. Often, the problems were edge cases we hadfailed to consider during the Design phase. Sometimes wecould redesign the feature on the spot, but other times werequired a week or more. Some problems required us tobuild prototypes and conducted user studies to choose thecorrect design alternative. Each time we chose analternative to the documented design, we updated the HISpec and marked the bug as FIXED. This was Engineering’scue to make any needed changes to the implementation andthen QA would test and approve the change. This systemkept the various teams in tight synchronization.

As a result, the HI Spec is quite large and detailed. Whenthe first release of OpenDoc shipped, the HI Specificationwas 211 pages and had been through at least 5 majorrevisions and as many minor ones. It has served as a modelfor subsequent HI Specifications here at Apple.

LESSONS FROM THE DESIGN PROCESSHI teams at Apple are typically cross-disciplinary. TheOpenDoc project team was interesting because it was cross-functional and it included designers from multiplecompanies. As a platform, OpenDoc was conceived byApple and supported by Apple’s partners IBM, Novell, andWordPerfect. Early supporters also included Sun, HP,Lotus, Taligent and XSoft.Members of the project team included engineering, humaninterface, product marketing, evangelism, and legal teamsfrom Apple, IBM, WordPerfect, Novell and Sun.Specialists on the team included market researchers,interaction designers, visual designers, usability specialists,prototype builders, software architects, coding wizards,quality assurance engineers and technical writers. Thisbrought many different perspectives to our tasks.

Team ProcessThe working relationship engendered at the beginning ofthe project was remarkably positive and effective andremains to this day one of the best examples of teamcollaboration within Apple. Part of the reason was theinitial make up of the Apple project team. We know that HIdesigners are often brought into a project after it is wellunderway. Even at Apple, which prides itself on user-centered design, this sometimes occurs. However, theOpenDoc software architects insisted that HI was not theirdomain and that suitable designers should be assigned tothe project. This recognition that HI design was aspecialized role, just as engineering or marketing arespecialized roles, set the stage for all subsequent interteaminteractions.Each group (architecture, engineering, marketing,management) helped define the product by publiclyspecifying constraints. For example, marketing specifiedthe class of computer systems on which OpenDoc wouldrun, while HI specified performance criteria for importantoperations. These constraints were valuable in helping uschoose between design alternatives.Anyone can provide a good idea -- but the HI team has theresponsibility to determine if a particular idea works in theoverall design. When the team rejects an idea, it isimportant to document why it was rejected and tocommunicate this information to the originator of the idea.Any member of the product team was free to contributeideas and criticism to another team, but in the end, eachteam was held responsible for the excellence of theirdeliverables. Thus, throughout the first four years ofOpenDoc, the HI team was responsible for ensuring that theuser interface was the best one possible. We found it veryhelpful to decree that the HI Architect had the authority to

unilaterally decide an issue. This worked as a forcingfunction to bring designers together.

Social ControlThe HI team had great influence on the design processbecause we worked to be in control of it. That may seemlike an odd statement; after all, most designers WANT tobe in control, but often are not. Because we were brought inat the beginning of the process, and we were expected to beresponsible for the design, we decided that our job wouldbe easier if we could be instrumental in driving the designprocess. Thus, at the first kick-off meeting, we presented aproposal for how we recommended doing the design work.Because no else presented a competing proposal at thattime, everyone focused on modifying our proposal until itwas acceptable.Another example of how we worked to be at the center ofthe process is more literally physical. To focus effort,Apple management sequestered the Apple team in a smallbuilding away from the main campus. The HI team stakedout four cubes in the middle of the group of work cubicles,and tore down the walls to create a large open space.Because of a lack of space in the building, this area becamethe informal meeting place for everyone. Whenever a hottopic arose, people from the surrounding cubes seemedpulled to our area and joined in the discussion.

Physical ControlThe breadth of the entire multi-company team causedcomplexity in communicating; only the Apple teams werelocated in the same city. Other members were scatteredthrough the US and UK. This distance and disciplinarydiversity required an open model of sharing documentationacross teams. Lots of paper was exchanged and weeklytelephone conversations were conducted with an emphasison engineering (primarily API) negotiations. The HI teamconducted its inter-company business through email andperiodic face-to-face meetings with our partners fromacross the US and UK.

Creative ControlThe feature set was “owned” by the project manager, butwas largely defined by the Apple Human Interface team.Features were negotiated with the various teams andincluded input from a broad range of contributors, but thehuman interface team and the architects had the largestdegree of control. We had a shared goal to keep the featureset as small as possible but sufficient to meet user needs.Apple has a well-known tradition of user-centered designand interface excellence which results, in part, from strongsupport of human interface guidelines. In the case ofOpenDoc, our engineers were well versed in the guidelinesand were highly sensitized to the human factorsconsideration of user needs. The HI team decided when itwas necessary to break the guidelines or replace them withmore appropriate guidelines. This is particularly importantwhen the technology worked on is new and very differentfrom traditional applications for which the guidelines were

written. We felt comfortable doing this because our HIteam members are part-owners of the larger Apple HIGuidelines, and we expected a foundation technology suchas OpenDoc to stress and advance these Guidelines.In many aspects, the Apple HI team was at the center of thedesign process -- gathering research, influencing the AppleEngineering and Marketing teams, influencing othercompanies, and creating the official design documentation.It was important to build on Apple’s history and learningsand not do design in a vacuum. Therefore, our teamleveraged much existing material. For example, there arevarious Apple research organizations that carefully trackusers’ responses to our products. We used this information,rather than beginning with a “blank page” and then doingprimary research to understand users and their needs.Because we were able to do this, we were able to avoidmuch time and effort that we otherwise would have spentdoing primary research on the spot.The HI team clearly influenced the Apple Engineering teamvia documentation such as the HI Specification, but also viacollegial discussions and negotiations. We also influencedmarketing by providing prototypes and input to collateralwhich were used to sell the ideas in OpenDoc.Our partners relied on the Macintosh OpenDoc HI designfor their own platforms. We proposed the initial design,took their input, reviewed their specifications, wrote thePlatform Checklist and made the “final” decisions oncontested design decisions — all of which gave us a greatdeal of control over the overall design of OpenDoc.We influenced developers by producing material toshowcase OpenDoc’s developer opportunities. Forexample, we did three presentations, each to audiences ofmore than 1000 developers. We also wrote four majorjournal articles, a magazine article and a dozen monthlyFAQ articles sent to Apple developers. We appeared in aninformational video produced for the developercommunity. We also provided consulting via email. Weparticipated in Apple’s World Wide DevelopersConference in 1993 through 1996, presenting and offeringon-the-spot consulting.To expose OpenDoc to HI professionals, we did apresentation to BayCHI (the San Francisco Bay Areabranch of the Association for Computing Machinery’sSIGCHI) and then at British Computer Society HCI ‘94;presented posters at ECSCW’95 and British ComputerSociety HCI ‘95; and manned a heavily-trafficked demobooth at CHI ‘96.

INSIGHTSWe view the OpenDoc project as an extremely successfullong-term effort in both design process and in the quality ofthe interface. We’d like to conclude by offering some ofour insights on how to make other development projects asrewarding as ours has been.

1. Have a Process• Established milestones, well-understood deliverables,

and a time table is crucial to managing the designdevelopment process.

• Clear roles (e.g. HI Architect, Interaction Designer,Visual Designer, Usability Specialist) and clearly assignresponsibility or “ownership” for a portion of thedesign.

2. Keep Comprehensive Documentation• If the product design isn’t clearly specified, it will be

open to interpretation.• The specification can become a living focus for design.

If done correctly, it will outlive individuals and productversions.

• It is important to document your rationale for design —you will need to justify decisions.

• It is as important to document ideas that were rejectedand why, as it is to document the ideas you accept.

• Anything you can build as a designer (prototypes,resources, etc.) will help ensure that your design isunderstood.

• Documentation relieves you of the burden ofremembering every detail. For example, had wecompleted the Conceptual Model Issues diagram(shown in figure 3) we would have spent far less timerecalling forgotten details.

3. Have a Team Process and a Focus for Control• Having a team composed of a broad set of disciplines

can bring needed diverse perspectives on design.• It was helpful that team members had experience on all

the target platforms. We made it a goal early in ourproject to actively recruit members from partnercompanies to complement our experience.

• Having this expertise on target platforms early in theprocess helped us avoid single-platform bias in design.

• Distance made it difficult to collaboratively design. Oneteam was responsible for leading/proposing and otherteams for ratifying (with changes and suggestions forimprovement).

• When working with other members of the project team,e.g. engineering, it was important that we were viewedas members of the team, not as consultants to the team.

• We found that anyone can have a good idea -- our job asdesigners are to find the ones that will work.

• Apple’s overall reputation for HI design skills made iteasier for our design team to lead, and kept usaccountable for living up to the reputation.

• An important company objective should be to performongoing customer research to find requirements we’vemissed or misunderstood, including opportunities torefine our products.

• Existing research will never provide all the informationyou need, but it can reduce your time-to-market andyour costs.

• There has to be a “user” in user-centered design —taking time to understand your target users and theirneeds will allow you to build a product that meets thoseneeds without guessing.

4. User StudiesWe also learned some things about user studies and whatthey can and cannot be expected to accomplish. They are:• Study results cannot be used to say what a design should

be, only that a design doesn't work.• Expect imperfect user studies! It is often impossible to

construct a good testbed.• Expect to make mistakes doing a study, but be prepared

to iterate the process to catch mistakes.• Look for unexpected results! We were often looking for

information about one component of the design andlearned coincidentally about unrelated components.

Of course, it is impossible to do an infinite number ofstudies. So, there will always be some uncertainty about theresults. (That’s why we have follow-up releases.)

GLOSSARYWe’ve used a few terms that may be unfamiliar. Here are afew short definitions:Developer: When we speak of developers, we areprimarily referring to third-party software developers whouse our technology platform to develop components whichcould be sold to customers. The secondary developer targetis fourth-party developers, who may package componentsfrom third-party developers as customized solutions forspecific customers.Evangelist: A marketing specialist who serves as a point ofcontact between developers and Apple. Often they helpdevelopers adopt a new technology, such as OpenDoc.Inside-Out Activation: Inside-out activation refers to themodel for activation of an embedded part via a single click.For example, consider a table embedded within this textdocument. The user positions the pointer inside the tableand clicks once. If the user can immediately begin editing,this is inside-out activation. By contrast, in the outside-inactivation model when the user clicks inside the table thetable is selected. Some other gesture, such as a double-click, is necessary to edit within the table. This becomes amajor problem when the user cannot see the structure, andtherefore cannot know if one, two, or more clicks arerequired before she can edit the desired content.Part: The fundamental building block in OpenDoc. Allparts have content and properties. Parts may be representedon the display screen as either icons or frames.Part Editor: The software needed to display and edit apart. Analogous to an application.

Linking: A link is a relationship between two parts orpieces of part contents. A Link operation is a modifiedCopy in that the copy is updated every time the originalchanges. A link allows part contents to appear to be in twodifferent places, even though it is only stored once. Forinstance, a document might link in a picture from anotherdocument, or a bar chart may display some data which islinked in from a row of a spreadsheet in the samedocument.Links may be within a part, between two parts in the samedocument, or between two parts in different documents.They may even span networks. Both part contents andentire parts may be linked. Links are one-way only.Scripting: OpenDoc allows users to use scripts to automatetasks. Scripting is one type of end-user programming.

ACKNOWLEDGMENTSWe thank our colleagues on the OpenDoc team, especiallyKurt Piersol and Jed Harris, the architects of OpenDoc;also, David C. Smith who wrote the first Conceptual Modelpaper; and Dan Jordan who co-authored the DesignRationale, an Apple internal document (some of which wasreused in this paper). Both David and Dan were membersof the Apple HI team, along with (in chronological order)Mark Stern, Stephanie Guerlain, George Corrick, JeremyHewes, Jennifer Chaffee, Sue Bartalo, Kristin Bauersfeld,Michael Thomas, Per Nielsen, Jeff Kreeger, Kerry Ortega,Geoff Schuller and Katie Candland. Principal IBM HIdesigners included, Scott Isensee, Shirley Martin, DickBerry and Dave Roberts.We also acknowledge early OpenDoc-related work atApple performed by Annette Wagner, Frank Ludolph, LeeHonigberg, Scott Jenson, John Sullivan and GittaSalomon.

TRADEMARKSOpenDoc® and QuickTime® are trademarks of AppleComputer, Inc. registered in the United States and othercountries.Director® and Macromedia® are registered trademarks ofMacromedia, Inc.Xerox® is a trademark of Xerox Corporation.Any other named products profiled herein are trademarksof their respective companies.

REFERENCES1. Moran, T. P., Carroll, J. M. (Eds.) (1996). Design

rationale: concepts, techniques, and use. LawrenceErlbaum Associates, Inc.

2. MIL-STD 1472C (1984). Human engineering designcriteria for military systems, equipment, and facilities.US Dept. of Defense, 2 May 1981 (including Notice 1, 1September 1983 and Notice 2, 10 May 1984).

3. Smith, D. C., Irby, C., Kimball, R., Verplank, W,. &Harslem, E (April 1982). “Designing the Star UserInterface.” Byte, pp. 242-282.

4. Apple Computer, Inc. (1995). OpenDoc Programmer’sGuide. NY, NY: Addison-Wesley.

5. Apple Computer, Inc. (1992). Macintosh HumanInterface Guidelines. NY, NY: Addison-Wesley.