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.
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.
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.
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.
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.
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.
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.
the MIME specification is an example of a document definition based on a higher level collection of elementary objects.
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.
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.
Users can filter and control the portrayal of this information and their associated content objects.
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.
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.
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.
Access controls can include, for example, allowing or disallowing a range of access types.
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.
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.
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.
Information about other objects pointing to a specific object in a document is available.
Hyperdocuments in personal, group, and library files can have access restrictions down to the object level based on individual identity or organizational role.
Access controls can include, for example, allowing or disallowing a range of access types such as read, write, or knowledge about existence.
Objects may be displayed differently depending on user or application control or the nature of the portrayal device.
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.
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.
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.
A Journal is an integrated library-like system into which a hyperdocument message or document can be submitted.
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.
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.
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.
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.)
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.
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.
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."
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.
Knowledge workers will have a range of preferences for interaction style based on previous experience, hardware device capability, and esthetic desires.
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.
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.
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.
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.
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.
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.
The OHS must contain the ability to access and comment on data in tools and systems outside of its immediate scope.
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.
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.
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
Shared authoring, linked commentary, shared files, group indexes, shared-window teleconferencing across applications, workflow ...
Automated capture, indexing and cross-referencing, integrated email, journal/library, intelligence collections; utilities for repository management
Dynamic portrayal, precision browsing, filtering, integrated editor, object-level addressibility, linkability, traceability, annotated index, accommodation for disabled...
Open Hyperdocument Systems represent a clear departure from prevailing information system:
|Tool-centric system||Document-centric system|
|Function-oriented tool system||Integrated end-to-end knowledge management environment|
|Authoring and publishing||Developing, integrating and applying knowledge online|
|Isolated passive libraries and archives||Active "living" libraries seamlessly integrated within the organization's work processes|
|One user class: "easy to use"||Many classes of user: pedestrian to high performance|
|File level addressability||Object-level addressability|
|"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|
|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|
|Each application has unique file design||Applications use common file design|
|"Interoperability" means font styles retained||Means my structured hyperknowledge interoperates in your environment, I can send you a link into my domain|
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.
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 comments
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.
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.
Integral time records, todo lists, status reports, email management; policies, procedures, reference manuals all integral.
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, implementers
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 Transfer
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)
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 sections titled "6 OHS For Generic CoDIAK Support" and "7 Four General Groupware Architectural Requirements" (AUGMENT,132811,7); refer to sections 1-5 for rationale.
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)"
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."
See also Tech Template meeting notes 03-Dec-97, 07-Jan-98