Date: 25 Oct 2000 22:00 PDT
From: | Doug Engelbart |
Bootstrap Institute DOUG@bootstrap.org> Reply-To: ohs-dev@bootstrap.org |
To: | ohs-dev@bootstrap.org |
Subject: | Draft Plan for HyperScope-OHS launch and development |
Via the first basic AUGMENT-to-HTML translation process
put together by Eugene,
I've installed a recent draft at
There are a few translation details which could be fixed, but basically it does what I'd looked for.
Eugene adjusted the URL "naming" to mirror what we use in AUGMENT, where the link address is [BI,2120,] -- i.e. it was submitted to the "BI" Journal, where it was given the permanent access number of "2120".
We might make adjustments to this "BI/2120.html" file, but the intent would be that none of the content, structure, or "Location Numbering" would change. And it undoubtedly will be superseded with updated versions; and also supported by other planning documents regarding deeper details and/or modifications to this, and, also, plans associated with other phases of the larger Bootstrap Program.
So I invite dialog about this plan to make use of links to the specific content locations being discussed.
And note that we'd like to translate quite a few of the AUGMENT reference files into this browser-accessible form. E.g., a full series of User Guides.
Sincerely,
Bootstrap Institute
Doug
Doug Engelbart
DOUG@bootstrap.org>
** Draft OHS-Project Plan, Doug Engelbart, 23-Oct-2000
We are addressing the large-scale, pervasive challenge of improving the collective development and application of knowledge. Many years of focussed experience and conceptual development underlie the strategic framework guiding this proposal. 1B
The HyperScope will be a lightly modified web browser supported by an "Intermediary Processor" (IP) which operates between the browser and the files or data bases holding existing working knowledge of a collaborative community. The HyperScope is not an editor. 2B
Brief Functional Description of Phase-1 HyperScope -- new capabilities provided to HyperScope users operating within legacy environments: 2C
Translation into the I-File's special structure and format creates, among other things, new label tags attached to many objects (e.g. each paragraph), so that links serviced by the HyperScope can explicitly target many objects in the file which were not addressable in their "legacy" form. Ideally, every object in a file should be targetable by a link whose author wants to comment specifically about that object. 2C2
The HyperScope will offer a set of "transcoded viewing options" which a user can selectively employ to examine that file. Simple example: just show me the first line of each paragraph. 2C3
It is planned to enable the option of incorporating a "view specification" (viewspec) to a link so that a subsequent user will not only have execution of that link take him to the desired specific file location, but will also show the contents there with the specified view. 2C3B
Considerable evolution is expected to take place here. In the "open-source" mode, many groups would be experimenting and tuning, contributing to the evolution. 2C3C
In principle, this manner of HyperScope access can be implemented for any standard type of file or data base. The Project will establish the basic implementation conventions, and proceed to develop the translation and special I-File properties appropriate for a selected sequence of file/db types -- planning tentatively for those to be used by: 2C4
Note: Here again, it is planned to facilitate Open-Source development so that many individuals and application communities can pursue specialty application needs and possibilities. (Facilitating this evolution is planned.) 2C4D
When viewing a legacy file via his HyperScope, a user will easily be able to install a HyperScope link (HS-Link) in any legacy file, targeting an explicit location in the file being viewed on his HyperScope. Clicking on the desired target object in a HyperScope "Copy mode," he can subsequently turn to the "legacy editor" and "Paste" the appropriate link into the legacy file. Later execution of that link will take any subsequent HyperScope user to the desired, specific location and with the specified view. 2C5
AND, in a larger sense, it would enable a practical way to improve on the established academic convention of only publishing AFTER appropriate peer review (with attendant time delays in the cycle of knowledge evolution). 2C6D2
HERE, a promising alternative is offered: Publish now, let Peer Review and "evolving attribution" take place after. I.e., much more than just counting citations can here provide effectively attributed peer evaluation: explicit back-link assessment of trails can operate in many complex knowledge-evolution environments to isolate the key contributions (and also the key misleading entries). 2C6D3
A conventional URL with a "#label" extension can position the HyperScope at a given object in the target file. Extended conventions will enable the link to point to subordinate objects -- e.g., to a word in a paragraph, to an expression in an equation, ... 2C7A
A very powerful extension to the relative addressing is a convention which directs the HyperScope to go to a specific location and then follow the link at that position -- and perhaps at the link's destination to do further relative positioning and "link following." This indirect linking provides very powerful functionality when users learn to harness it. 2C7B
Example -- every word is implicitly linked to its definition in a dictionary; every special term is implicitly linked to its definition in that discipline's glossary; every instance of an object's name in a source-code file is implicitly linked to its implementation code; ...; every pronoun is implicitly linked to its antecedent. Special "jump" commands can be provided which can operate as though the term in question is explicitly linked to the "implicitly linked" object. (Jump to Definition, ...) 2C7C
Later, when editing of the Intermediary File will be offered, any legal edit operation executed in one window is reflected accurately and immediately in all other of that file's portrayal windows. 2C8A
This flexibility in utilizing multiple windows has surprising value when users learn to make effective use of it. 2C8B
Options offered via simple selection means -- E.g.: 2C9
Click-select a given paragraph, then Jump Next, Last, First, Origin, ... 2C9B
First click indicates what jump is desired; second click can be in any other window, indicating where the jump-result view is to be portrayed. Whatever viewing spec already established in the target window will also prevail when the jumped-to file/location is portrayed there. 2C10A
Also, in the interval between window clicks, icon or menu clicks, or character input, can indicate the new viewing spec if the user desires something different from what is currently set for the target window. 2C10B
For instance: Window 1 could be relatively narrow, with view spec set for small font and only first line of each paragraph portrayed; Window 2 wider, with larger, more-readable font and full-paragraph portrayal. 2C10C
An OHS "User Interface System" (UIS) will be developed to provide a basic range of functions for moving, viewing and editing. 3B
Provision for archiving, version control, etc. will be developed so that it becomes possible to develop and maintain an evolving knowledge base solely within an OHS environment -- with integrated flexibility and power accumulated from the best that was accomplished via HyperScope usage among the legacy files. 3C
Now the VERY important feature of this approach to OHS development comes into play: task by task, or person by person, in almost any order and rate, users can start to keep their files entirely within the OHS environment. All the working material is still interlinkable, whether in OHS or legacy files. 3D
And the critical community-development processes will become VERY important here -- to start the active "co-evolution" of the "Human System" and the OHS "Tool System" (as discussed at length in the "Bootstrap Publications"). 3E
For the scale of utilization that will be necessary, in number of inter-operating groups, in the diversity of inter-operable knowledge domains, and in the continuing changes in tools and skills, processes, etc. -- it will be absolutely critical that... 3F
Being able effectively to support web-connected mobile phones is one example. 4A1
But a VERY IMPORTANT purpose here is to enable individuals, or special-role support teams, to experiment with interface equipment, functionality, and control options, together with optional special attributes of the standard Intermediary File, to pursue especially high performance at important parts of their knowledge processes. 4B
Having this kind of exploration in any event will be necessary. Doing it with special extensions to the widely used OHS will be very important in enabling feasible migration of these tools and skills out into the rest of the communities. Moreover, doing this exploratory high-performance activity over the SAME WORKING domains amplifies that benefit immensely; motivated individuals can optionally acquire special interface equipment, take some special training, and move up to a "new class of user proficiency" (e.g. becoming a certified Class-4B Knowledge Integrator). 4C
There are support roles anticipated in developing and maintaining a community's Dynamic Knowledge Repository (DKR) which could very well be taken on by specially trained High-Performance Support Teams. Such a team could for instance be fielded in a university (as a research project into High-Performance Collective Knowledge Work), and take on the "Knowledge Integrator" role for a professional society's DKR. And competitive exercises could be conducted among teams from different universities -- or companies, or agencies, or countries -- as part of an explicit processes to facilitate improvement in "Collective IQ." 4D