Author: HGL
Created: Wed 28 Jan 1998 07:38:02 GMT+00:00
Modified: Wed 28 Jan 1998 07:40:45 GMT+00:00
TECHNOLOGY TEMPLATE PROJECT
OHS Framework


Harvey Lehtman, Doug Engelbart, and Christina Engelbart
Version 2 • 28-Jan-98
White Paper (ALLIANCE,980,)
0

Introduction 1

The technology template is a hierarchy of characteristics of an Open Hyperdocument System (OHS) by which commercial and research tools can be designed, implemented, and evaluated. "Hyperdocument" implies flexible linkages to any object in any multi-media file. "Open" implies vendor-independent access to the hyperdocuments within and across work groups, platforms, and applications.1a

The characteristics in the template hierarchy range from the definition of low level content and structural elements of a Hyperdocument File System; the means for accessing, navigating, linking, manipulating, and portraying these elementary objects; the basic services, applications, and utilities built from these elements and methods; through end user systems constructed from and interacting with the lower level elements in the hierarchy.1b

The initial template is based on a number of papers by Engelbart cited in the reference section. Many of the initial elements were contained in the Augment system that evolved over many years under his direction. The template is meant to create a living structure into which elements can be added, refined, and in general be discussed by members of the larger Bootstrapping community. 1c

We hope evaluations of systems and tools from developers will refer to elements of this template as a way of demonstrating how closely these systems approximate a true OHS. 1d

We also hope that these design criteria can serve as a proposal for a core set of methods for Java applets and a class of basic objects responding to these methods so new, interacting, Web-based systems can easily satisfy the requirements for an OHS.1e

Framework2

Hyperdocument Content and Structure2a

Content Objects2a1

    Elementary Objects2a1a

Objects are basic content packets of an arbitrary, user and developer extensible nature. Types of elementary objects could contain text, graphics, equations, tables, spreadsheets, canned-images, video, sound, code elements, etc.2a1a1

    Mixed-Object Documents2a1b

Documents are a coherent entity made up of an arbitrary mix of elementary objects bundled within a common "envelope" to be stored, transmitted, read, printed, or otherwise be operated on.2a1b1

the MIME specification is an example of a document definition based on a higher level collection of elementary objects.2a1b2

    Shared Objects2a1c

Objects and the documents made out of them are shareable among members of a networked community: they may be simultaneously viewable, manipulable, and changeable according to rules appropriate to their nature and supported in access permissions and restrictions contained in their definitions.2a1c1

    Object ID-Time Stamps2a1d

Each creation or modification of an object automatically results in the creation of a stamp containing information concerning the date, time, date, and user identification associated with that modification.2a1d1

Users can filter and control the portrayal of this information and their associated content objects.2a1d2

    Personal Signature Encryption/Verification/Authentication of Objects and Documents2a1e

Users can affix personal signatures to a document, or a specified collections of objects within the document, using private signature keys. Users can verify that the signature is authentic and that no bit of the signed document or document segment has been altered since it was signed. Signed document segments can be copied or moved in full without interfering with later signature verification.2a1e1

Structure2a2

    Explicitly Structured Documents2a2a

Objects comprising a document can be arranged in an explicit structure. A hierarchy is but one example of such a structure; others could include more complex cross-linked structures. Compound-object substructures may be explicitly addressed for access and manipulation.2a2a1

    Shared Documents2a2b

Documents, a user defined knowledge package of structured objects, are shareable, subject to access or privacy provisions, across the entire global domain in which any online collaborative working relationships are established in potentially ever-changing and evolving ways. This is the most fundamental requirement of an OHS.2a2b1

Access controls can include, for example, allowing or disallowing a range of access types.2a2b2

Access and Portrayal2b

Addressing2b1

    Global, Human-Understandable, Object Addresses2b1a

Every object that someone might validly want/need to cite or otherwise access should have an unambiguous address, capable of being portrayed in a human readable and interpretable manner. Most common existing spreadsheet programs have provisions similar to this for cell addressibility.2b1a1

    Link Addresses That Are Readable and Interpretable by Humans2b1b

It should be possible to display and specify the complete link address of any object in the global domain of the OHS. This human-readable description of the "address path" leading to the cited object should permit a transparent possibility for human understanding of the path including the possibility of reading, interpretation, and conceptually following the specification.2b1b1

Linking/Filtering/Access Control2b2

    The Basic "Hyper" Characteristics2b2a

Embedded objects called links can point to any arbitrary object within the document, or within another document in a specified domain of documents. Links can be actuated by a user or an automatic process to "go see what is at the other end," or "bring the other-end object to this location," or "execute the process identified at the other end." These executable processes may control peripheral devices such as CD ROM, video-disk players, etc.2b2a1

    Hyperdocument "Back-Links"2b2b

Information about other objects pointing to a specific object in a document is available.2b2b1

    Access Control2b2c

Hyperdocuments in personal, group, and library files can have access restrictions down to the object level based on individual identity or organizational role. 2b2c1

Access controls can include, for example, allowing or disallowing a range of access types such as read, write, or knowledge about existence.2b2c2

Portrayal2b3

    View Control of Objects' Form, Sequence and Content2b3a

Objects may be displayed differently depending on user or application control or the nature of the portrayal device.2b3a1

A structured, mixed-object document may be displayed in a window according to a flexible choice of viewing options. These could include selective level clipping (e.g., outline views), but also filtering by content, truncation or some algorithmic view that provides other portrayals of structure and/or object content perhaps incorporating new sequences or groupings of objects residing in other documents. Editing on structure or object content directly from such special views would be allowed whenever appropriate.2b3a2

    Hard-Copy Print Options to Show Addresses of Objects and Address Specification of Links2b3b

People reading documents online, or offline from hardcopy portrayals of a time snapshot of a document, are able to follow link citations though human visible and interpretable addresses.2b3b1

Asynchronous Collaboration Support2b4

    Hyperdocument Mail2b4a

An integrated, general-purpose mail service enables a hyperdocument of any size to be disseminated to anyone in the knowledge community. Any embedded links are also faithfully transmitted and any recipient can then follow those links to their designated targets that may be in other mail items, in common-access files, or in "library" items subject, of course, to access controls.2b4a1

    The Hyperdocument "Journal System"2b4b

A Journal is an integrated library-like system into which a hyperdocument message or document can be submitted. 2b4b1

An automated "clerk" assigns each Journal document a unique, permanent catalog number, stores the item, notifies designated recipients (if any) with a link for easy retrieval, notifies of supercessions, catalogs it for future searching, and manages document collections. 2b4b2

Access to Journal documents is guaranteed when referenced by its catalog number, or "jumped to" with an appropriate link. Links within newly submitted hyperdocuments can cite any passages within prior documents. The back-link facility lets an online reader of a document detect and examine subsequent documents containing links citing that document.2b4b3

    External Document Control (XDoc)2b4c

Documents not integrated into an above online and interactive environment (e.g., hard-copy documents and other records otherwise external to the OHS) can be managed by employing the same "catalog system" used for hyperdocument libraries with a back-link service to indicate citations to these "offline" records from hyperdocument (and other) data bases. OHS users can find out what is being said about these "External Document" (XDoc) records in the hyperdocument world as well as access instructions..2b4c1

A knowledge environment in an OHS includes Shared Files, Throw-Away Email, Journal/Library, and External Documents (XDOC). Documents in each of these four areas can have hyperlinks among themselves as appropriate to the retention level implied by their definition. (Thus citations to Journal items will always be valid while citations to Throw-Away Email are not guaranteed.)2b4c2

Services, Applications and Utilities2c

Interface and Hardware Independence2c1

    Global and Individual Vocabulary Control2c1a

Within a collaborating knowledge worker domain, there will be a population with a range of capability and experience performing an evolving and expanding array of functionality on varied hardware and software devices from an assortment of developers. These workers will have to be able to learn, discuss, and perform similar activities in this heterogeneous, interconnected system.2c1a1

An formal abstraction of the user interface for the tools within the workshop permits collaboration while allowing differences between commercial offerings. This abstraction in the form of a Command Meta Language describes users' available operations (verbs) on classes of objects (nouns) in grammatical descriptions of tools.2c1a2

A Command Language Interpreter (CLI) interprets user actions, based upon the contents of the currently attached grammar file, and executes appropriate actions via remote procedure calls to a common application program interface of the "open system environment."2c1a3

This architectural approach, with its abstraction of user interface issues, is a practical way to support and control the evolving global "workshop vocabulary" effectively integrating distributed groupware services on wide ranging platforms.2c1a4

    Multiplicity of Look-and-Feel Interface Choices2c1b

Knowledge workers will have a range of preferences for interaction style based on previous experience, hardware device capability, and esthetic desires.2c1b1

A computer-human interaction "look-and-feel interface" software module based upon the same Command-Language Interpreter (CLI) architecture mentioned above could offer modules for preferred interaction characteristics.2c1b2

When working interactively, no matter what particular look-and-feel style is being used, a user can have a particular mental model in mind for the significance of every type of command interaction. They can learn from other co-workers who may have vastly differing personal interaction preferences.2c1b3

Besides relaxing the troublesome need to make people conform to a standard look and feel, this approach has a very positive potential outcome in permitting evolution of interaction styles and expanded functionality while maintaining access to past functionality. So far, the evolution of popular graphical user interfaces has been heavily affected by the "easy to use" dictum. This has served well to facilitate wide acceptance, but it is quite unlikely that the road to truly high performance can effectively be traveled by people who are stuck with vehicular controls designed to be easy to use by a past generation.2c1b4

As important classes of users develop larger and larger workshop vocabularies, and exercise greater process skills in employing them, they will undoubtedly begin to benefit from significant changes in look and feel. The above approach will provide open opportunity for that important aspect of our evolution toward truly high performance.2c1b5

Realtime Collaboration Support2c2

    Shared-Window Teleconferencing2c2a

Remote distributed workers can view and manipulate the workplace environment of collaborators, as if they are sitting side-by-side, to review, draft, or modify a document, provide coaching or consulting, support meetings, and so on. Control of the application program (residing in the "showing" worker's environment) can be passed around freely among the participants.2c2a1

    Real time communication2c2b

A range of tools for teleconferencing, "chatting," and facilitating group decision making may be available in media ranging from text through audio and video. There should be provision for capturing these interactions for later examination and annotation and inclusion in the permanent knowledge workshop Journal.2c2b1

Interapplication Connectivity2c3

    Inter-Linkage Between Hyperdocuments and Other Data Systems2c3a

The OHS must contain the ability to access and comment on data in tools and systems outside of its immediate scope.2c3a1

For example, a CAD system's data base can have links from annotations/comments associated with a design object that point to relevant specifications, requirements, discussions, etc., in an associated OHS. Hyperdocuments in turn may point to objects within the CAD bases. During later study of some object within the CAD model, the back-link service could inform the CAD worker which hyperdocument passages cited that object.2c3a2

End User Programmability2c4

    Extensible applications2c4a

Objects manipulation tools can be configured into larger applications or modifications of existing application features. These components can be traded as part of an application exchange and can foster the evolution of the system.2c4a1

End User Systems2d

Foundational Knowledge Environment2d1

Aimed at supporting the ongoing development of work-in-progress for individuals, teams, organizations, communities, whole nations...; integrating dialog records, intelligence collections, as well as knowledge products; accommodating dynamic contributions from broad diversity of participants - in real-time, concurrently and over time. See also scenarios of usage <Ref-2>, and original motivation for this work <Ref-3>.2d1a

    Collaboration, coordination, concurrency2d1b

Shared authoring, linked commentary, shared files, group indexes, shared-window teleconferencing across applications, workflow ...2d1b1

    Dynamic knowledge capture, integration, management2d1c

Automated capture, indexing and cross-referencing, integrated email, journal/library, intelligence collections; utilities for repository management2d1c1

    Value-added access, maneuverability, utility2d1d

Dynamic portrayal, precision browsing, filtering, integrated editor, object-level addressibility, linkability, traceability, annotated index, accommodation for disabled...2d1d1

    Paradigm Shift Summary2d1e

Open Hyperdocument Systems represent a clear departure from prevailing information system:2d1e1

From To
2d1e1a

Tool-centric system Document-centric system
2d1e1b

Function-oriented tool system Integrated end-to-end knowledge management environment
2d1e1c

Authoring and publishing Developing, integrating and applying knowledge online
2d1e1d

Isolated passive libraries and archives Active "living" libraries seamlessly integrated within the organization's work processes
2d1e1e

One user class: "easy to use" Many classes of user: pedestrian to high performance
2d1e1f

File level addressability Object-level addressability
2d1e1g

"Load & scroll browsing" in WYSIWYG or outline view modes "Precision browsing" Jumping directly to any object in any file with on-the-fly custom views
2d1e1h

Windows tied to a file and to the application used Windows are portals into a file repository; a variety of applications may use any window
2d1e1i

Each application has unique file design Applications use common file design
2d1e1j

"Interoperability" means font styles retained Means my structured hyperknowledge interoperates in your environment, I can send you a link into my domain
2d1e1k

Collaborative Authoring2d2

Structured outlining and rearranging, easy reuse of existing material, easy link-creation and annotation to cite related work. Publish drafts for review (see Online Publishing below); reviewers comment via annotated links. Track what's been changed, by whom, when. Integrate and track concurrent contributions of many participants. Version control, management of document collections.2d2a

Study2d3

Precision browsing includes cross-window jumping and dynamic view control; keep annotated lists of links or hits to selected passages, email links to author or co-workers with questions or comments2d3a

Online Publishing2d4

Draft of final document is submitted to the repository via email, automatically assigned document number, cataloged; email notification with link to document automatically issued to distribution list (if any). Can supersede, add to, reply to a document. Full access and version control, traceability, accountability, authentication.2d4a

Meeting Support2d5

Agenda development, group note-taking, shared-window teleconferencing, full access to repositories; capture and cross-reference meeting records within the repository, integrate into work-in-progress.2d5a

Personal Time Management2d6

Integral time records, todo lists, status reports, email management; policies, procedures, reference manuals all integral.2d6a

Project Management2d7

Structured work breakdown, status reports, work flow all integral, structured and crosslinked for automated management reporting and perusal at any level of detail; can backtrack on events, revisit rationale, debrief; supports evolutionary customer-centered projects throughout life cycle with close coordination between designers, end-users, implementers2d7a

Software Engineering2d8

Structured source code, cross referencing between source, design, requirements, bug reports, user documentation; click on procedure name to access its source; OO structure semi-automatic; each line of code stamped with time/ID of last edit for filtered view (e.g. who last changed this part of the code, or show all statements edited since a certain date/time); see also Project Management and Continuous Improvement, Learning, Technology Transfer2d8a

Continuous improvement, Learning, Technology Transfer2d9

Facilitates co-evolution of practices and tools, pro-active customer/stakeholder participation, shared repositories, integration of lessons learned; shared-screen coaching and virtual help desk; graduated user proficiency (clear path from unskilled user to high-performance support teams)2d9a

Etc.2d10

References3

Ref-1: The above requirements are an extension of Engelbart's 1992 Groupware paper "Toward High-Performance Organizations: A Strategic Role for Groupware," Douglas C. Engelbart, Proceedings of the GroupWare '92 Conference, San Jose, CA, August 3-5, 1992, Morgan Kaufmann Publishers. Reference section titled sections "6 OHS For Generic CoDIAK Support"and "7 Four General Groupware Architectural Requirementst" (AUGMENT,132811,7); refer to sections 1-5 for rationale. 3a

Ref-2: "Toward High-Performance Organizations: A Strategic Role for Groupware," Douglas C. Engelbart, Proceedings of the GroupWare '92 Conference, San Jose, CA, August 3-5, 1992, Morgan Kaufmann Publishers. Reference section titled "The CODIAK Process Supported by an OHS" (AUGMENT,132811,9) 3b

Ref-3: "Augmenting Human Intellect: A Conceptual Framework. Summary Report" Douglas C. Engelbart, AFOSR-3223 under Contract AF 49(638)-1024, SRI Project 3578 for Air Force Office of Scientific Research, Stanford Research Institute, Menlo Park, Ca., October 1962. 3c

see also Tech Template meeting notes 03-Dec-97, 07-Jan-983d

Contributors4

  • Doug Engelbart - BI
  • 4a
  • Christina Engelbart - BI
  • 4b
  • Martin Haeberli - Netscape
  • 4c
  • Harvey Lehtman - IFTF
  • 4d
  • Nick Ragouzis - Enosis Group
  • 4e
  • Jeff Rulifson - Sun
  • 4f
  • Jeff Smith - NTT
  • 4g