Author: DCE
Created: April 23, 2002
Modified: April 23, 2002

Boosting Our Collective IQ: A Selection of Readings
Dr. Douglas C. Engelbart
1995 (AUGMENT,133150,)

Originally published in a special bound edition for attendees of the 1995 World Wide Web Conference to commemorate Engelbart's receipt of the SoftQuad Web Award. Includes excerpts from three Engelbart papers, plus epilogue and award information. Yuri Rubinsky and Christina Engelbart, Editors.
See also Printer Friendly version.

Toward Augmenting the Human Intellect and
Boosting our Collective IQ* 1

How did I wander into the wide, very sparsely populated frontier spaces of old?

I became motivated (committed) in 1951 to improving mankind's capability for dealing with its pressing problems, especially those over-taxing our collective capability to cope with complexity and urgency. I visualized people collaborating interactively on visual displays connected to a computer complex. I'm not "numerically oriented"; my vision has always facilitated discursive thinking and collaboration.

By 1962, after a ph.D. in Electrical Engineering/Computers at Berkeley and in my fifth year at the Stanford Research Institute (SRI), I developed a "Conceptual Framework for Augmenting Human Intellect". Its fundamental concepts still guide my pursuit. The hypermedia design principles I concentrate on here are but secondary derivatives of that larger-goal conceptual framework. In fact, all our computer developments into the 1970s (synchronous distributed shared-screen conferencing, windowing systems, outlining tools, the mouse, among others) and since are secondary derivatives of this conceptual framework; I view the computer merely as a supportive tool. Other major framework elements include a "bootstrapping" strategy fostering networks of organizations collaborating on capability infrastructures, explicit co-evolution of tool-systems and human-systems (skills, knowledge, procedures), and the key integrative paradigm: Concurrent Development, Integration and Application of Knowledge (CoDIAK).

My goal for this short piece is to encourage the further development of the framework's technological cornerstone – an open hyperdocument system (OHS), an integrated, seamless multi-vendor architecture in which knowledge workers share hyperdocuments on shared screens. Hyperdocuments are multimedia files supporting linking and multiple object types. The hyperdocument system should enable flexible, on-line collaborative development, integration, application, study and reuse of CoDIAK Knowledge.

My hypermedia design notions evolved from the OHS concept, and were further shaped by years of development and real user application experience since the early '60s: the oN-Line System (NLS) development at SRI over a 13- year span and AUGMENT, its subsequent 12-year commercial form. Peak usage saw more than 20 mainframe servers networked across the country, supporting significant pilot implementations in many organizations that truly transformed how people performed knowledge work.

And, now that World Wide Web (www) has opened people's eyes to (a small portion of) hypermedia's potential, we should expect active penetration into the hypermedia frontier – towards widely used OHS. In the limited space here, I'll express some design thoughts (actually selected AUGMENT features) for the www's continued evolution. The references describe a more complete set, including very important non-hypermedia aspects for system architectures.

Everything in the Work Environment is Live Hyperdocument Stuff: All knowledge products, such as email, notes, source code, to-do lists, work breakdown structures, status reports, design documents, user guides, trouble reports, and others are inherently hyperdocument objects. The infrastructure provides knowledge products with all the hyperdocument capabilities described here.

Integrated Applications: A tool system using a universal knowledge base replaces the standard application or function-based paradigm. Individual application subsystems (graphical editors, program language editors, spreadsheets) work with knowledge products, but do not "own" hyperdocuments in the sense of being responsible for their storage or representation. For instance, one could create a Gantt chart within a project management system, and manipulate it as a graph in a charting application or as mail in an email application. An integrated core application package provides base capabilities of composing, reading, annotating, linking and manipulating knowledge products. All knowledge workers – authors and users – modify and incorporate other knowledge products into their own information bases and knowledge products (much as Ted Nelson advocated in Xanadu).

Explicitly Structured Documents: Objects within a hyperdocument have an explicit structure in which structural and logical substructures may be addressed and manipulated. For example, one can manipulate any statement in a hierarchical structure as an aggregate branch of all its substatements (with each maintaining its individual identity). This greatly extends the notion of manipulating sections and subsections in today's outlining tools.

Every Object Intrinsically Addressable (Linkable to): Every knowledge object – from the largest documents, to aggregate branches, down to content units such as characters – has an unambiguous address, understandable and readable by a user, and referenceable anywhere in the hyperdocument system. Such intrinsic addressability should be integrated deeply into commands for editing, structuring, jumping. Intrinsic addressing options not only are natural to learn and embed in links, but serve as parameters for direct, user-invoked jumping and manipulation commands. This addressing scheme allows direct or indirect addressing (absolute or relative, and through aliases; indeed we allow unlimited indirect address chaining) and working with objects not currently displayed. For instance, one can copy a structure without finding and opening the file containing it. Meta-level referencing (addresses on links themselves) enables knowledge workers to comment upon links and otherwise reference them.

View Control of Form, Sequence and Content: A structured, mixed-object hyperdocument may be displayed with a flexible choice of viewing options: selective level clipping, filtering on content, truncation or other transformation of object content, new sequences or groupings of objects including those residing in other documents, etc. Links may specify views so traversal retrieves the destination object with a prespecified presentation view (e.g., display as a high-level outline or display only a particular statement). View specification becomes a natural and constantly employed part of a user's vocabulary.

Hyperdocument Library System: Hyperdocuments may be submitted to a library-like service (an administratively established AUGMENT Journal) that catalogs them, and provides a permanent, linkable address and guaranteed as-published content retrieval. This Journal system handles version and access control, provides notifications of supercessions and generally manages open-ended document collections.

Open hyperdocument software concepts are but a small part of a larger Bootstrapping Initiative, currently underway. We are fostering a cooperative community of organizations interested in strategically improving their collective improvement capabilities, and thereby augmenting each organization's – and indeed society's – potential to excel in our rapidly changing world.

References 1n

  1. Engelbart, D. C. Toward high-performance knowledge workers. In OAC '82 Digest Proceedings of the AFIPS Office Automation Conference. (April 5-7, 1982 San Francisco) pp. 279-290 Republished in Computer-Supported Cooperative Work: A Book of Readings Greif, I. (Ed.) Morgan Kaufmann, San Mateo, Ca. (1988) pp. 67-78. <AUGMENT, 81010,>.
  2. Engelbart, D.C. Authorship provisions in AUGMENT. In Computer Supported Cooperative Work: A Book of Readings. Greif, I.(Ed.) Morgan Kaufmann, San Mateo, CA. (1988) pp. 107-126. Also in Groupware: Software for Computer-Supported Cooperative Work. Marca, D. and Rock, G., (Eds.) IEEE, New York, NY (1992) <OAD, 2250,>.
  3. Engelbart, D.C. Knowledge-domain interoperability and an open hyperdocument system. In Proceedings of the Conference on Computer-Supported Work. (October 7-10, 1990, Los Angeles) pp. 143-156. Republished in Hypertext/Hypermedia Handbook, Berk, E. and Devlin, J., (Eds.) McGraw-Hill (1991) pp. 397-413. <AUGMENT, 132082,>.
  4. Engelbart, D.C. Toward high-performance organizations: A strategic role for groupware. In Proceedings of the Groupware '92 Conference (August 3-5, 1992, San Jose, CA.) Morgan Kaufmann, San Mateo, CA. <AUGMENT, 132810,>.

Knowledge-Domain Interoperability
and an Open Hyperdocument System* 2

This paper anticipates that the tools and methods of computer-supported cooperative work (CSCW) will become harnessed with revolutionary benefit to the ongoing, everyday knowledge work within and between larger organizations. Toward that end, the following concerns about interoperability between knowledge-work domains will have to be met and something such as the "open hyperdocument system" must become available for widespread use.

As computers become cheaper and we learn more about harnessing them within our cooperative work, they will come to support an increasing number of different domains of knowledge work. Moreover, the sphere of computer-supported activities within each domain will steadily expand as more function and more skill become employed.

It is predictable that increasing functional overlap will occur as these expanding domains begin to overlap. It has become apparent to me that someday all of our basic knowledge-work domains will be integrated within one coherent "organization knowledge workshop". This leads to thinking about an overall, integrated architectural approach to the ever larger set of common knowledge work capabilities emerging within a multi-vendor environment.

Much has been accomplished to date in standards and protocols in the highly active field of networked workstations & servers, where "interoperability between hardware and/or software modules" has become a central theme.

This paper considers the "interoperability between knowledge domains". This interoperability theme will be increasingly important for a workable CSCW framework as the scope and degree of CSCW increases. Dramatic increases will predictably create a marked paradigm shift about how to organize and operate cooperative human endeavors. I think that two phenomena will yield changes and a paradigm shift that will make this interoperability of paramount importance.

(1) With a relatively unbounded technological frontier together with immense and growing economic pressure, the speed, size and cost of computers, memory, and digital communications will continue improving by geometric progression.

(2) Awareness and importance of CSCW is emerging, with a predictable trend toward our doing more and more of our personal and cooperative knowledge-work online.

Assuming an inevitably gigantic scale for our inter-knit "CSCW world" provides some important guidance for the continuing investment of our business resources and professional time.

For one thing, each year earlier that an effective degree of knowledge-domain interoperability is in place within important organizational or institutional domains could be worth hundreds of millions of dollars – could mean the difference between vitality and sluggishness.

And for another, we would prefer to avoid investing our research, product development, or organizational-change resources toward ends that won't be interoperably compatible within that future, radically different paradigm.

Interoperability in an Individual's Knowledge Workshop 2l

To begin with some very basic knowledge-domain interoperability issues, consider your own (future?) "Computer-Supported Personal Work" (CSPW). Assume that you have acquired a fairly comprehensive, online "knowledge workshop", you have found better and better software packages to support the kinds of tasks shown in Figure 1:

Figure 1
Figure 1. Each functional domain is a candidate for working interchange with all others.

Consider what you will some day have when your individual workshop inevitably becomes truly integrated. Between the email and the task management files, or the status reports, or whatever, you really would like to tie these functional domains together with a flexible free-flow of information and linkages.

What kind of interoperability do you have now? I happen to think that the interoperability provided today within most CSPW domains has a great deal of improvement yet to be pursued. But I'd resist any serious arguments about this unless it be approached within the context of a coherent "CSCW interoperability framework" such as outlined below. Let me say in warning, though, that from such a framework I will contend that the marketplace for CSPW will change drastically as CSCW takes hold within our larger organizations and their inter-organizational communities.

Interoperability in a Group's Knowledge Workshop 2m

Suppose that you and a colleague each have a fully integrated CSPW domain, comprised of nicely interoperable sub-domains as in Figure I. And suppose that you want to work together online. Consider the interoperability between your respective knowledge-work domains, as in Figure 2.

Figure 2
Figure 2. Close cooperation between compound knowledge domains puts new demands on knowledge-work interchange.

Now you're faced with a new challenge and a new problem. You might set it up so you have a few lines that cross between domains, but why stop there? When do two people in intense cooperative work not need total interoperability? In fact, they depend on it heavily in the paper world. Why not online?

Interoperability Across Time and Space 2n

Yet another example of multiple domains is found in the familiar time-place matrix shown in Figure 3. In many cases, activities in the different quadrants involve the same substantive work content. Is knowledge-work interoperability between the quadrant domains an issue? Very much so. For example, face-to-face meetings need to flexibly utilize anything from the whole organizational knowledge base, and the meeting's records should immediately become an integral part of that same base for later-time work.

A Point About Online Group Knowledge Work 2o

The matrix in Figure 3 is very neat and ordered. Here in Figure 4, I offer another picture of multi-domain, group knowledge work

Figure 3
Figure 3. Collaborative processes generally considered.

which isn't so cleanly laid-out. This reflects how I feel about the various knowledge-work domains with which my CSPW domain must interoperate.

Figure 4
Figure 4. Consider some knowledge domain with which you intersect significantly.

The purpose of interoperability is to avoid having information islands between which information cannot flow effectively. Since we grew up in a paper-based framework we've given little thought about how much exchange and interoperability support we really do have, and how much we depend upon it. To be interoperable in our CSPW world we could simply print out and hand over the hard copy. With WYSIWYG screens and Desktop Publishing, we're doing that with nicer paper, faster.

So when we inevitably move from computer-supported paper generation and exchange to computer-supported online creation and exchange, we will need the same level of interoperability. And as the number and scale of knowledge domains involved in a given CSCW "web" increases, so does the need for "online interoperability".

Interoperability Across Knowledge Domains 2p

To appreciate the extraordinary complexity of heavy industrial knowledge work, and the associated requirements for interoperability, consider the important functional domains within a large manufacturing organization producing a complex product, such as an airplane. It is a serious enough challenge to provide effective interoperability among the knowledge workers within any of the domains in Figure 5; just consider the inter-domain challenge. And then consider that some of these domains, such as customers and suppliers exist "outside" the organization, each with its own equally complex multi-domain structure.

Figure 5
Figure 5. Each functional domain is a candidate for working interchange with all others.

Toward High-Performance Organizations:
A Strategic Role for Groupware* 3

The CoDIAK Process 3a

Increased pressure for reduced product cycle time, and for more and more work to be done concurrently, is forcing unprecedented coordination across project functions and organizational boundaries. The need for highly effective knowledge work capabilities is becoming increasingly urgent. Yet most organizations do not have a comprehensive picture of what knowledge work is, and of what aspects would be most profitable to improve. In my mind, the point of greatest leverage is what I have come to call "CoDIAK" for the COncurrent Development, Integration and Application of Knowledge.

Figure 6
Figure 6.

Figure 6 (see previous page) represents the high-level core of a CoDIAK process, such as can be found in a complex knowledge-intensive project. In the center is a basic organizational unit, representing the interactive knowledge domains of a single individual, or of individuals or groups within a project team, department, functional unit, division, task force, whole organization, community, or nation.

Each organizational unit is continuously analyzing, digesting, integrating, collaborating, developing, applying, and re-using its knowledge, much of which is ingested from its external environment.

Figure 7
Figure 7.

A result of this continuous knowledge process is a dynamically evolving knowledge base as shown in Figure 7 above, consisting of three primary knowledge domains:

Intelligence Collection: An alert project group keeps a watchful eye on its external environment, actively surveying, ingesting, and interacting with it. The resulting intelligence is integrated with other project knowledge on an ongoing basis.

Dialog Records: Responding effectively to needs and opportunities involves a high degree of coordination and dialog within and across project groups. This dialog, along with resulting decisions, is integrated with other project knowledge on a continuing basis.

Knowledge Product: The resulting planning documents provide a comprehensive picture of the project at hand. These documents, which are iteratively and collaboratively developed, represent the knowledge products of the project team, and constitute both the current project status and a roadmap for implementation and deployment.

The CoDIAK process is rarely a one-shot effort. Lessons learned, as well as intelligence and dialog, must be constantly analyzed, digested, and integrated into the knowledge products throughout the life cycle of the project.

With minor adjustments in the boxed lists in Figure 7, this basic generic CoDIAK model seems to apply equally well to academic scholarship, heavy industry, government, medical research, social institutions, consumer product business, consulting firms, trade associations, small non-profits, and so on.

The CoDIAK capability is not only the basic machinery that propels our organizations, it also provides the key capabilities for their steering, navigating and self repair. And the body of the applicable knowledge developed represents a critically valuable asset. The CoDIAK capability is crucial across the organization, whether in strategic planning, marketing, R & D, production, customer support, or operations. The CoDIAK capability should be considered a core business competency in the organization's capability infrastructure.

The foregoing dictates some very significant requirements for any system that attempts to support the CoDIAK processes within and across our future, high-performance organizations. Inevitably, these tools will need to be fully integrated and fully interoperable, supporting very flexible, wide-area sharing of pieces of the knowledge base. This poses the associated need for a new way of thinking about the nature of the knowledge packages we have called "documents". This above requirement for flexibly arranged sharing of essentially arbitrary knowledge chunks provides a very strong argument for documents becoming built from modular-concept nodes with arbitrary inter-node linking – hypertext.

Open Hyperdocument Systems (OHS): For Generic CoDIAK Support 3b

My early assumption, amply borne out by subsequent experience, is that the basic supporting technology for future high-performance knowledge work will be an integrated system based upon multi-media hyperdocuments.

Furthermore, there will be critical issues of interoperability within and between our organizations and their knowledge domains. The ever-greater value derived from online, interactive work within a hyperdocument environment will require a significantly higher degree of standardization in document architecture and usage conventions than heretofore contemplated.

It is inevitable that this service be provided by an "open system" of hyperdocuments and associated network and server architectures. The basic arguments for this Open Hyperdocument System (OHS) are presented in Ref-5; and the hyperdocument system features described below are assumed by me to be strong candidates for requirements for the eventual OHS whose evolution will be so critical to the productivity of industries and nations.

Following is a brief general description of the system design that has evolved from the conceptual orientation described in this paper, through the experience of many years and trial events. Please note that the term "system" is very important here.

Shared Files/Documents – the most fundamental requirement. Generalized file sharing is to be available across the entire global domain in which any online collaborative working relationship is established (e.g., world-wide).

Mixed-Object Documents – to provide for an arbitrary mix of text, diagrams, equations, tables, raster-scan images (single frame or live video), spread sheets, recorded sound, etc. – all bundled within a common "envelope" to be stored, transmitted, read (played) and printed as a coherent entity called a "document".

Explicitly Structured Documents – where the objects comprising a document are arranged in an explicit hierarchical structure, and compound-object substructures may be explicitly addressed for access or to manipulate the structural relationships.

Global, Human-Understandable, Object Addresses – in principle, every object that someone might validly want/need to cite should have an unambiguous address, capable of being portrayed in a manner as to be human readable and interpretable. (E.g., not acceptable to be unable to link to an object within a "frame" or "card".)

View Control of Objects' Form, Sequence and Content – where a structured, mixed-object document may be displayed in a window according to flexible choice of viewing options – especially by selective level clipping (outline for viewing), but also by filtering of content, by truncation or some algorithmic view that provides a more useful portrayal of structure and/or object content (including new sequences or groupings of objects that actually reside in other documents). Editing on structure or object content directly from such special views would be allowed whenever appropriate.

The Basic "Hyper" Characteristics – where embedded objects called links can point to any arbitrary object within the document, or within another document in a specified domain of documents – and the link 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.)

Hyperdocument "Back-Link" Capability – when reading a hyperdocument online, a worker can utilize information about links from other objects within this or other hyperdocuments that point to this hyperdocument – or to designate objects or passages of interest in this hyperdocument.

Link Addresses That Are Readable and Interpretable by Humans – one of the "viewing options" for displaying/printing a link object should provide a human-readable description of the "address path" leading to the cited object; and, the human must be able to read the path description, interpret it, and follow it (find the destination "by hand" so to speak).

Personal Signature Encryption – where a user can affix his personal signature to a document, or a specified segment within the document, using a private signature key. 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.

Hard-Copy Print Options to Show Address of Objects and Address Specification of Links – so that, besides online workers being able to follow a link-citation path (manually, or via an automatic link jump), people working with associated hard copy can read and interpret the link-citation, and follow the indicated path to the cited object in the designated hard-copy document.

Also, suppose that a hard-copy worker wants to have a link to a given object established in the online file. By visual inspection of the hard copy, he should be able to determine a valid address path to that object and for instance hand-write an appropriate link specification for later online entry, or dictate it over a phone to a colleague.

Hyperdocument Mail – where an integrated, general-purpose mail service enables a hyperdocument of any size to be mailed. 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.

The Hyperdocument "Journal System" – an integrated library-like system where a hyperdocument message or document can be submitted using a submittal form (technically an email message form), and an automated "clerk" assigns a catalog number, stores the item, notifies recipients with a link for easy retrieval, notifies of supercessions, catalogs it for future searching, and manages document collections. Access 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 any of the prior documents, and the back-link service lets the online reader of a document detect and "go examine" any passage of a subsequent document that has a link citing that passage.

Access Control – Hyperdocuments in personal, group, and library files can have access restrictions down to the object level.

External Document Control (XDoc) – (Not exactly a "hyperdocument" issue, but an important system issue here.) Documents not integrated into the above online and interactive environment (e.g. hard-copy documents and other records otherwise external to the OHS) can very effectively be managed by employing the same "catalog system" as for hyperdocument libraries – with 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 "XDoc" records in the hyperdocument world.

Figure 8
Figure 8. "Hyperdocument" provides flexible linkages to any object in any multi-media file; "Open" provides vendor independent access within and across work groups.

The overview portrayal in Figure 8 shows the working relationships between the major system elements described above. Note the shared catalog service that supports use of the Journal and External Document services.

Details of features and designs for well-developed prototypes of some of the above may be found in Ref-6, Ref-7, and Ref-8.

Four General Groupware Architectural Requirements 3c

Besides the aforementioned Hyperdocument Mail and Hyperdocument Library features that depend upon special larger-scale architectural features, there are at least four other important tool-system capabilities that are very important to wide-area groupware services such as those being considered here:

Global and Individual Vocabulary Control – somewhat new in the history of computer services are issues regarding the evolution and use of a common "workshop vocabulary" among all the users of the forthcoming "global knowledge workshop". Common data dictionaries have been at issue, of course, but for a much more limited range of users, and for a more limited and stable vocabulary than we will face in the exploding groupware world.

Our own architectural approach (see Ref-6, Ref-9 and Ref-10) has been to introduce into every user-interface environment a common Command-Language Interpreter (CLI) module that derives the user's available operations (verbs) as applied to the available classes of objects (nouns) from a grammar file (individualized if desired with respect to the size and nature of the verbs and nouns utilized from the common vocabulary). The 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".

Each of us knowledge workers will become involved in an even richer online environment, collaborating more and more closely within an ever global "knowledge workshop", with multi-organizational users of widely divergent skills and application orientations who are using hardware and software from a wide mix of vendors.

Without some global architectural capability such as suggested above, I can't see a practical way to support and control the evolving global "workshop vocabulary" in a manner necessary for effectively integrating wide-area groupware services.

Multiplicity of Look-and-Feel Interface Choices – Based upon the same Command-Language Interpreter (CLI) architecture as above, a "look-and-feel interface" software module would be located between the CLI and the window system. Providing optional modules for selected look-and-feel interface characteristics would serve an important practical as well as evolutionary need.

There would be a basic constraint necessary here. When working interactively, no matter what particular look-and-feel style is being used, a user has a particular mental model in mind for the significance of every menu item, icon, typed command or "hot, command-key combination" employed.

The necessary constraint needed here is that the resulting action, via the interface module that is being employed for this user, must be produced through the underlying execution of processes provided by the Command-Language Interpreter module as derived from use of common-vocabulary terms. And the users should learn about their tools and materials, and do their discussing with others about their work, using the underlying common-vocabulary terms no matter what form of user interface they employ.

Besides relaxing the troublesome need to make people conform to a standard look-and-feel, this approach has a very positive potential outcome. 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 skill 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 evolution toward truly high performance.

Shared-Window Teleconferencing – where remote distributed workers can each execute a related support service that provides the "viewing" workers with a complete dynamic image of the "showing" worker's window(s). Used in conjunction with a phone call (or conference call), the parties can work 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. Generic provisions of this service is discussed in Ref-6.

Inter-Linkage Between Hyperdocuments and Other Data Systems – for instance, a CAD system's data base can have links from annotations/comments associated with a design object that point to relevant specifications, requirements, arguments, etc., of relevance in a hyperdocument data base – and back-link service would show hyperdocument readers which passages were cited from the CAD data base (or specified parts thereof).

Similarly, links in hyperdocuments may point to objects within the CAD bases. And, during later study of some object within the CAD model, the black-link service could inform the CAD worker as to which hyperdocument passages cited that object.

The CoDIAK Process Supported by an OHS 3d

With the above tool capabilities, together with well-developed methods and other human-system elements, the organization's capability infrastructure could support the following types of online CoDIAK scenarios.

Note that the following online interactions are designed to work, even if the users are in different organizational units, in different organizations, using different application packages on different workstations (assuming access to the data is not barred by stringent privacy features, naturally). The real test of an OHS is when you can click on a link you received via email from someone in a different organization, jumping directly to the passages cited, and then comfortably maneuver through the "foreign" knowledge domain, possibly jumping up a level with an outline view to see the context of the given passage, following other links you find there, and so on, without having to fumble through unfamiliar processes.

Intelligence Collection: Now an alert project group, whether classified as core business, or improvement activity, can keep a much enhanced watchful eye on its external environment, actively surveying, ingesting, and interacting with it mostly online. Much of the external intelligence is now available in hyperdocument, multimedia form, having been captured in an OHS Journal facility. When I send you an email to let you know about an upcoming conference, I can cite the sessions I think you'd be interested in, and you can click on the enclosed citation links to quickly access the cited passages (taking advantage of hypertext links and object addressability). When I do a search through the Journal catalogs to research a question for the proposal I am writing, I can see who has cited the material and what they had to say about it. If the material is offline (i.e. in XDoc), I can quickly discover where it is stored and how to obtain a copy, probably requesting it via email. If the material is online, I can access it instantly, usually starting with a top-level outline view of the document's titles (taking advantage of the OHS document structure and custom viewing features), possibly setting a simple filter to narrow the field, then quickly zooming in on the specific information I require. I can quickly build an annotated index to the intelligence documents, or objects within those documents, that I want to keep track of. I can share with you a macro I wrote to trap certain incoming intelligence items and reformat them in a certain way, and you could fire this up in your own environment to work off your pet key-words (taking advantage of the common-vocabulary architectural feature). All the intelligence collected is easily integrated with other project knowledge.

Dialog Records: Responding effectively to needs and opportunities involves a high degree of coordination and dialog within and across project groups. In an OHS environment, most of the dialog will be conducted online via the Journal. Email would be used mostly for "throw-away" communiqués, such as meeting reminders. All memos, status reports, meeting minutes, design change requests, field support logs, bug reports, and so on, would be submitted to the Journal for distribution. Asynchronous online conferencing would be supported by the Journal, with each entry tagged and cataloged for easy future reference. Document exchange would be a matter of submitting the document to the Journal with a comment such as "Here's the latest version – please note especially the changes in Section G, differences are listed in File Y" including links to that section and that file for easy access. The reviewers would click on the links, and proceed to review the document. To make a comment, the reviewer would click on the object in question, and enter the comment, such as "Replace with 'XYZ'," or "Watch out for inconsistencies with Para G4!" with a link to the passage in G4. The author then gets back the indexed comments, and has many options for quickly reviewing and integrating them into the document. Such dialog support will obviate the need for many same-time meetings.

Same-time meetings, when needed, would be greatly enhanced by an OHS. The dialog motivating the meeting would already be in the Journal. Agenda items would be solicited, and the agenda distributed via the Journal. At the meeting, the agenda and real-time group notes can be projected on a large screen, as well as displayed on each participant's monitor (using the "shared screen" feature), and any participant can point to the displayed material (e.g. using a mouse). Controls can be passed to any participant to scribble, type, or draw on this virtual chalkboard. Any presentation materials and supporting documents can be instantly retrieved from the knowledge base for presentation. All resulting meeting documents, along with references to supporting documents cited, would subsequently be submitted to the Journal for immediate access by all authorized users.

In addition, tools will soon become generally available for flexibly contributing, integrating, and interlinking digitized speech into the OHS knowledge base. Early tools would be available for speaker recognition, for special-word recognition, and even for basic transcription to text – and for installing and following links between modules as small as a word embedded in a long speech string. This will greatly enhance the development, integration, and application of dialog records. More elegant tools will follow, and as human conventions and methods evolve to make effective use of technology, the quantity and completeness of recorded dialog will become much more significant.

Knowledge Product: Throughout the life cycle of the project, the online OHS knowledge product will provide a truly comprehensive picture of the project at hand. Intermediate project states, including supporting intelligence and dialog trails, can be bundled as document collections in the Journal for document version management. All knowledge products will be developed, integrated, and applied within an OHS, with concurrent contributions from many diverse and widely distributed users. These users can also work as if sitting side by side, reviewing a design, marking up a document, finalizing the changes, etc. (using the shared screen feature). Finding what you need among the thousands of project documents will be a simple matter of clicking on a link (provided by the Journal catalogs, or by your project's indices), and zooming in and out of the detail, or by having someone else "take you there" (using the shared screen feature). Accountability is absolute – Journal submittals are guaranteed to be authentic, and each object can be tagged by the system with the date and time of the last write, plus the user who made the change. Documents can be signed with verifiable signatures.

Everyone is but one quick "link hop" away from any piece of knowledge representation anywhere in the whole knowledge collection. Smart retrieval tools can rapidly comb part or all of the collection to provide lists of "hit links" with rated relevance probabilities.

Conventions for structuring, categorizing, labeling and linking within their common knowledge domain will be well established and supportive of a high degree of mobility and navigational flexibility to experienced participants – much as residents get to know their way effectively around their city if they get much practice at it.

As a group adapts its ways of working to take better advantage of a tool system such as projected here, the classes of knowledge objects will grow, as will the functions available to operate upon them – and that growth will be paralleled by the concurrent evolution of an ever richer repertoire of the humans' "workshop knowledge, vocabulary, methodology and skills".

There is tremendous potential here, and many methods, procedures, conventions, organizational roles to be developed in close association with the tools. And, if the OHS is to be open, there is much deep exploration to be done into different application domains, such as Computer-Supported Cooperative Work (CSCW), organizational learning, Total Quality Management (TQM), Enterprise Integration (EI), program management, Computer-Aided Software Engineering (CASE), Computer-Aided Engineering (CAE), Concurrent Engineering (CE), organizational memory, online document delivery and CALS, and so on.

Potential customers for augmented CoDIAK capabilities can be seen everywhere in today's global society: e.g., all of the "Grand Challenges" earmarked in the U.S. for special support. Essentially every professional society will eventually operate this way; as will legislative bodies and government agencies, and university research programs.

In short, our solutions to every other challenging problem that is critical to our society will become significantly facilitated by high-performance CoDIAK capabilities. Provides a stimulating challenge for the groupware community, doesn't it?

In closing, I would like to emphasize the importance of the evolution of perceptions, visions and paradigms. I am convinced that cultivating the appropriate paradigm about how to view and approach the future will in the pursuit of high-performance organizations be the single most critical success factor of all.

References 3e

  1. Engelbart, D.C. 1962. Augmenting Human Intellect: A Conceptual Framework, Summary Report, Stanford Research Institute, on Contract AF 49(63-8)-1024, October, 134 pp.
  2. Engelbart, D.C 1963. A Conceptual Framework for the Augmentation of Man's Intellect. Vistas in Information Handling, Howerton and Weeks (eds), Washington, D.C.: Spartan Books, pp. 1-29. Republished in Greif, I. (ed) 1988. Computer Supported-Cooperative Work: A Book of Readings, San Mateo, CA: Morgan Kaufmann Publishers, Inc., pp. 35-65.
  3. Engelbart, D.C. 1988. The Augmented Knowledge Workshop. Goldberg, A. (ed), 1988. A History of Personal Workstations, New York: ACM Press, pp. 35-65.
  4. Engelbart, D.C. and Lehtman, HG. 1988. Working Together, BYTE Magazine, December, pp. 245-252.
  5. Engelbart, D.C. 1990. Knowledge Domain Interoperability and an Open Hyperdocument System. Proceedings of the Conference on Computer-Supported Cooperative Work, Los Angeles, CA, October 7-10, pp. 143-156. <AUGMENT, 132082,>. Republished in Berk, E. and Devlin, J. (eds) 1991. Hypertext/ Hypermedia Handbook, New York: Intertext Publications, McGraw-Hill, pp. 397-413.
  6. Engelbart, D.C. 1982. Toward High Performance Knowledge Workers. OAC '82 Digest, Proceedings of the AFIPS Office Automation Conference, San Francisco, CA, April 5-7, pp. 279-290. <AUGMENT, 81010,>. Republished in Greif, I. (ed) 1988. Computer-Supported Cooperative Work: A Book of Readings, San Mateo, CA: Morgan Kaufmann Publishers, Inc., pp. 67-78.
  7. Engelbart, D.C. 1984. Collaboration Support Provisions in AUGMENT. OAC '84 Digest, Proceedings of the 1984 AFIPS Office Automation Conference, Los Angeles, CA, February 20-22, pp. 51-58. (OAD, 2221,).
  8. Engelbart, D.C. 1984. Authorship Provisions in AUGMENT. COMPCON '84 Digest, Proceedings of the COMPCON Conference, San Francisco, CA, February 27 – March 1, pp. 465-472. (OAD, 2250,). Republished in Greif, I. (ed) 1988. Computer-Supported Cooperative Work: A Book of Readings, San Mateo, CA: Morgan Kaufmann Publishers, Inc., pp. 107-126.
  9. Irby, C.H. 1976. The Command Meta Language System. AFIPS Conference Proceedings, NCC Vol. 45, Montvale, NJ: AFIPS Press <AUGMENT, 27266,>.
  10. Watson, R.W. 1976. User Interface Design Issues for a Large Interactive System. AFIPS Conference Proceedings, Vol. 45, Montvale, NJ: AFIPS Press, pp. 357-364. <AUGMENT, 27271,>.
  11. Engelbart, D.C. 1972. Coordinated Information Services for a Discipline-or Mission-Oriented Community. Proceedings of the Second Annual Computer Communications Conference, San Jose, CA, January 24. Republished in Grimsdale, R.L and Kuo, F.F. (eds) 1975. Computer Communication Networks, Leydon: Noordhoff. <AUGMENT, 12445,>.
  12. Grenier, R., Metes, G. 1992. Enterprise Networking: Working Together Apart. Digital Press. (Very relevant general treatment; special emphasis given to "Capability-Based Environment" along the lines outlined in this paper.)
  13. Parunak, H.V.D. 1991. Toward Industrial Strength Hypermedia, Hypertext/Hypermedia Handbook, Berk, E. and Devlin, J. (eds), New York: McGraw-Hill, pp. 381-395. (Provides very useful considerations relevant to requirements for the Open Hyperdocument System as discussed in this paper.)

Epilogue: 1995 and Beyond 4

The issue of maximizing Collective IQ presents a grand challenge with tremendous potential payoff. Indeed the team, company, institution, community, or whole nation which goes after this critical pursuit most aggressively will come out far ahead of its meandering counterparts in productivity, effectiveness, and competitiveness. The World Wide Web provides an excellent springboard for this pursuit, assuming it can move from archival publishing into supporting our dynamic, malleable, heterogeneous CoDIAK work environments.

The architecture of the future electronic documents, and of the supportive application systems for working with them, will be a critical factor in limiting or enhancing the performance levels attainable. These architectures are too important to allow their evolution to be dominated by simple, vendor-customer market forces. For any real hope of gaining significant progress, explicit advocacy and pursuit of high-performance collective knowledge-work capability has to be taken up by a "critical mass" of stakeholders, funds, and organizational backing.

As a starting point, the critical yet-to-emerge technology for pursuing these goals is the Open Hyperdocument System (OHS). A highly evolvable advanced prototype OHS which implements the above-stated requirements should be made available for experimentation. This would provide a starting point for exploring the associated work practices, conventions, roles and policies for online collaborative planning, authoring, structuring, linking and managing dynamically evolving repositories. Furthermore, a number of prototypical high-performance teams should be cultivated as models of future workmodes, which can be deployed to support particularly complex mission-critical work.

The ongoing results of such a program would be immediately applicable within many knowledge-intensive activities and grand challenges in government, industry, and society, including software engineering, manufacturing, procurement, concurrent engineering, total quality, legislation, networked improvement communities, re-engineering, tele-commuting, digital libraries, distance learning, crisis action, and so on. Cultivating industry and community participation in the formulation of requirements and standards, and collaborating on pilot trials and lessons learned, would provide a much-needed accelerative boost to this effort. And furthermore, boosting the Collective IQ of industry-government collaboration with the emerging tools and practices would offer further leverage to this critical pursuit.

After years of ground-breaking activity, we have outlined the scope of work that needs to be launched, and defined a high-leverage strategic improvement process which we believe will carve the most expedient evolutionary path. We have a highly-evolved prototype of the type of integrated collaborative hyperdocument system which will be needed to boost Collective IQ – including a web browser/server that supports the object-level addressability, zooming, view control, shared window teleconferencing, journal/library, workflow, etc. And we are conducting "expeditions" to provide first hand experience to organizations serious about exploring the frontier, with the formation of an industry-government alliance in the offing to bootstrap this important and exciting effort.

Dr. Douglas C. Engelbart 5

In association with the International World Wide Web Conference Committee, SoftQuad Inc. has created an annual Web Award, honoring an individual whose vision and work have helped make the web possible. As part of the award, this book has been published by and for the Fourth International Web Conference, December 1995, in Boston, USA.

Commemorating a lifetime of imagination and achievement, and for his contribution to computing, communication, collaborative work, and the foundations of the World Wide Web, the International World Wide Web Conference Committee presents the first SoftQuad Web Award to Dr. Douglas C. Engelbart, the inventor of the graphical user interface, of shared-screen teleconferencing, context-sensitive help and the mouse.

Dr. Engelbart has an unparalleled thirty-year track record in predicting, designing and implementing the future of organizational computing. Founder of the Bootstrap Institute which is devoted to the notion of supporting the improvement process and tools for improvement within organizations, Dr. Engelbart is author of a collection of seminal articles, and the leader of a team of individuals who, over the years, have contributed much to the theory and practice of modern collaborative computing.

Very early, Dr. Engelbart recognized that in addition to aspiring to be increasingly faster and smarter at their core missions (whether creating better widgets or solving societal problems), organizations will have to get increasingly faster and smarter at how they keep improving. He recognized that humanity's technical and non-technical capabilities had co-evolved slowly, over the centuries, but that with the advent of digital technology, the technical elements would soon shoot ahead of the non-technical, and tend to automate rather than augment human intellect.

Dr. Engelbart is best known, perhaps, for the 90-minute multimedia presentation he gave at the 1968 Fall Joint Computer Conference. Using NLS (for oNLine System), the groupware system developed by his lab, the Augmentation Research Center, he and colleagues thirty miles (connected by micro-wave) away collaborated in presenting on-screen video teleconferencing, hypertext links both in text and graphics, and demonstrated the use of the world's first mouse. (The covers of this book include stills from archival footage of that event.)

In recent years there has been a surge of interest and exploration in the interrelated topics of Computer-Supported Cooperative Work, in groupware, and in networked hypermedia. As the selections of his writing in this book show, Dr. Engelbart anticipated and helped shape the computing environment in which we live and work, and continues to offer direction, particularly in the area of the World Wide Web, the most visible manifestation of the accuracy of his vision. This award and this book honor the role he has in our lives.

Endnotes 6

*^Chapter 1: Excerpted from Toward Augmenting the Human Intellect and Boosting our Collective IQ, Douglas C. Engelbart, August 1995. Communications of the Association for Computing Machinery Inc., [ACM]. Reprinted with permission.

*^Chapter 2: Excerpted from Knowledge-Domain Interoperability and an Open Hyperdocument System, Douglas C. Engelbart, from Proceedings of the Conference on Computer-Supported Cooperative Work, Los Angeles CA, October 7-10, 1990, pp. 143-156 <AUGMENT, 132082,>. Also republished in full in Hypertext/Hypermedia Handbook, Berk, E. and Devlin, J. (Eds.) McGraw-Hill, 1991.

*^Chapter 3: Excerpted from Toward High-Performance Organizations: A Strategic Role for Groupware, Douglas C. Engelbart, from GoupWare '92, Proceedings of the GroupWare '92 Conference, San Jose, CA, August 3-5, 1992, Morgan Kaufmann Publisher, pp 77-100.