hide header
|
Author: HGL
Created: Wed 28 Jan 1998 07:38:02 GMT+00:00 Modified: Wed 28 Jan 1998 07:40:45 GMT+00:00 OHS Framework Version 2 • 28-Jan-98 White Paper (ALLIANCE,980,) Available Here: permalink | HyperScope(?) Return to Bibliography 0 Introduction 1The 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 Framework 2Hyperdocument Content and Structure 2aContent Objects 2a1Elementary Objects 2a1aObjects 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 Documents 2a1bDocuments 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 Objects 2a1cObjects 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 Stamps 2a1dEach 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 Documents 2a1eUsers 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 Structure 2a2Explicitly Structured Documents 2a2aObjects 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 Documents 2a2bDocuments, 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 Portrayal 2bAddressing 2b1Global, Human-Understandable, Object Addresses 2b1aEvery 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 Humans 2b1bIt 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 Control 2b2The Basic "Hyper" Characteristics 2b2aEmbedded 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" 2b2bInformation about other objects pointing to a specific object in a document is available.2b2b1 Access Control 2b2cHyperdocuments 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 Portrayal 2b3View Control of Objects' Form, Sequence and Content 2b3aObjects 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 Links 2b3bPeople 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 Support 2b4Hyperdocument Mail 2b4aAn 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" 2b4bA 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) 2b4cDocuments 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 Utilities 2cInterface and Hardware Independence 2c1Global and Individual Vocabulary Control 2c1aWithin 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 Choices 2c1bKnowledge 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 Support 2c2Shared-Window Teleconferencing 2c2aRemote 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 communication 2c2bA 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 Connectivity 2c3Inter-Linkage Between Hyperdocuments and Other Data Systems 2c3aThe 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 Programmability 2c4Extensible applications 2c4aObjects 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 Systems 2dFoundational Knowledge Environment 2d1
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 Collaboration, coordination, concurrency 2d1bShared authoring, linked commentary, shared files, group indexes, shared-window teleconferencing across applications, workflow ...2d1b1 Dynamic knowledge capture, integration, management 2d1cAutomated capture, indexing and cross-referencing, integrated email, journal/library, intelligence collections; utilities for repository management2d1c1 Value-added access, maneuverability, utility 2d1dDynamic portrayal, precision browsing, filtering, integrated editor, object-level addressibility, linkability, traceability, annotated index, accommodation for disabled...2d1d1 Paradigm Shift Summary 2d1eOpen Hyperdocument Systems represent a clear departure from prevailing information system: 2d1e1
Collaborative Authoring 2d2Structured 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 Study 2d3Precision 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 Publishing 2d4Draft 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 Support 2d5Agenda 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 Management 2d6Integral time records, todo lists, status reports, email management; policies, procedures, reference manuals all integral.2d6a Project Management 2d7Structured 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 Engineering 2d8Structured 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 Transfer 2d9Facilitates 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. 2d10References 3Ref-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. 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 Contributors 4 |
|||||||||