UI Design + Management

When OpenDoc’s component-based architecture “broke” the AppleGuide online help engine, I initiated and managed a major UI revision to AppleGuide.

I developed the needs analysis, defined user requirements, then assembled a cross-functional team that developed solutions and made engineering changes.

Solutions included a dynamically assembled help “view” that let components bring their help own content and integrate it into help for an OpenDoc process.

For more detail, see OpenDoc: Building Help for a Component-Oriented Architecture.

 

AppleGuide for OpenDoc

Challenges

OpenDoc provided a framework in which a set of parts functioned as a single document. Users created a document by opening a “shell,” then dragging in with components. For example, “The Oil Report” (above) was created by opening an OpenDoc shell, then dragging in text, chart, and picture components to handle content. OpenDoc documents were also dynamic—the user could drag components in and out at any time.

However, AppleGuide could not detect components or integrate help for a dynamic, user-defined “bundle” of components. It was designed to deliver application-based help—e.g, the help for the SimpleText application was delivered in a single help file called “SimpleText Guide.”

Solution—OpenDoc parts bring their own help

The engineers provided an essential linchpin:  a tagging protocol that allowed a component to “check in” its own help content. This feature allowed OpenDoc developers to own and distribute help content with each component. As the technology owner, Apple could own and distribute OpenDoc framework help without increasing developer overhead.

The new AppleGuide dynamically created a guide based on the components in an OpenDoc document.  When the user opened a new OpenDoc shell, AppleGuide automatically created and named a help “view”—e.g., The Oil Report Guide. In addition, the help content dynamically changed if components were added or deleted.