From Dialog with Doug Engelbart and documents, as cited below:
Audio description by Doug: https://soundcloud.com/user-75792421/doug-hs-intro-filt-c
High Resolution Linking
[SOURCE: Doug Engelbart, interviews & OHS Draft document]
INTRO: HyperScope will allow industry standard document types to exhibit advanced features simply by being accessed through the HyperScope system.
EXAMPLE: Instead of waiting for the full system, HyperScope can add links to documents where there none, simply by accessing the document through a HyperScope aware browser.
INITIAL IMPLEMENTATION: 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 or an authoring environment, it is simply a good way to start providing OHS type functionality at the browsing and reading stage at minimum disruption to the end users.
ININTIAL FEATURES: A HyperScope user will be able to follow links into and between “legacy” files in a manner similar to using a browser with web-based HTML files. And more, there will be numerous new capabilities and features which will give a HyperScope user considerable more flexibility and working power than users limited to standard browsers and “legacy” editors.
High-Resolution Addressability: As HyperScope is used, legacy informaiton is translated into an intermediary file format called I-File. 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.
Copying-Pasting HyperScope Links: 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.
EXAMPLE: Here “http://xxx.xxx.xxx#aaa” targets a specific object, assumedly not labelled in the legacy file, but given the “aaa” label by the Translator any time that it translates that targeted file into the I-File format.
The HyperScope can point to any arbitrary object within the document, not just to the whole document. High Resolution Linking allows the convention of a page being the object to refer to to become obsolete. Any object, whether on a page or not, can be linked to. High resolution referencing is designed for easy retrieval of anything anyone might want to reference or comment on.
Every object is accessible through manual links (as with HTML today) and through relative addressing (first paragraph in this document) and indirect linking (find .
EXAMPLE: Manual Linking (Any word/page which the author of the document has chosen to give an address to, as with HTML and anchors today). Indirect Linking (Find link in paragraph and follow it such as find someone’s records and follow any link in their ‘Personal” information field if it’s a link, to see their personal home page). Relative Addressing (For example: Third paragraph in this document.)
In response to what may be an ordinary HTTP link, the targeted file will be (a) retrieved from its server and (b) dynamically “translated” into an Intermediary file (I-File) with special structure and format implemented with XML+.
EXPANDABILITY: For any community seriously interested in applying HyperScope (and the follow-on, full OHS), it is assumed that appropriate “translator modules” will be developed for every file/DB type of significance to their collaborative efforts. It is expected that an increasing list of customized translators will be developed as different application communities extend the range of legacy files to be brought into integrated HyperScope use.
From past experience it is expected that users will invent many variations of the ways they would like to view portions of their files, under different circumstances, often shifting rapidly between views just as one might rotate a physical object, or shift its distance, to get a better understanding of what is there.
View-Specifications: 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.
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.
Expanded set of HyperScope accessable “Legacy File Types:” 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:
EVOLUTION: Considerable evolution is expected to take place here. In the “open-source” mode, many groups would be experimenting and tuning, contributing to the evolution.Evolution of the Intermediary File format will be given careful attention since it is destined to become the format for the full Open Hyperdocument System (which will continue its evolution).
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.
View Controls/View Specs
[SOURCE: Doug Engelbart, interviews & OHS Draft document]
When accessing a document, the user may specify the way in which it should be portrayed.
EXAMPLE: Outline view.
User Specified Content Filters. A simple content-analysis language may be used in a “Set Content Pattern” command, which compiles a little content-checking program. One of the view-specification options will cause the system to display only those statements which satisfy both the structure and level conditions imposed by other view specs, and which also pass the content-analysis test applied by this program. Where desired, very sophisticated content-analysis programs may be written, using a full-blown programming language, and placed on call for any user.
EXAMPLE: Show only paragraphs with the word “America”.
View Control Of Objects’ Form, Sequence & Content where a structured, mixed-object document may be displayed in a window according to a flexible choice of viewing options – especially by selective level clipping (outline for viewing), but also by filtering on 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 will be allowed whenever appropriate.
EXAMPLE: Jump to paragraph.
Backlink Database [SOURCE: Doug Engelbart, interviews & OHS Draft document]
Database of Links With Backlink Capability will allow users to not only follow a link one way, but also easily see who is linking to any given page. Back-Link Management: Provision will be made to capture information about links pointing through the HyperScopes into a specified collection of files, to establish a “Back-Link Data Base” (BLDB). For each such link, information to be captured would be such as:
Explicit target object being cited;
The “foreign” location of the link;
EXAMPLE
Advanced Hypermedia [SOURCE: Doug Engelbart, interviews & OHS Draft document]
OHS uses a different system from what we are used to with Hypertext, which vastly increases the users options. Moving from one location to another is referred to as jumping:
º Jumping can take place through a simple click on a manually created link as with regular Web URLs.
º Jumping can be implicit such as looking a word up in a dictionary or glossary.
º Jumping can be relative such as jumping to next item in a sequence, to the end of a document, jumping to predecessor etc.
º Jumping in OHS affords the users further flexibility by allowing view specs to be added to the end of jumps and addressees, specifying how the document jumped to is to be displayed including truncation for dynamic outline generation.
EXAMPLE: Jump to the ‘Phone Number’ entry in the database for ‘John Doe’ and show me the results.
Relative Addressing: 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 expressiion in an equation, …
Indirect Linking: 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.
Implicit Linking: 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 imlementation 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, …)
Same file in multiple windows — no real limit there — simultaneously allowing different positioning and differnet viewing portrayals of a given file. 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.
This flexibility in utilizing multiple windows has surprising value when users learn to make effective use of it.
A click in a given paragraph, not on an embedded link, would hoist that paragraph to the top of the window.
Non-Link Jumps; Options offered via simple selection means — E.g.:
Click-select a given paragraph, then Jump Next, Last, First, Origin, …
Double-click Jumps offer surprisingly flexible options:
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.
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.
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.
NOTE: Link Typing has been advocated and discused for many years. With the above HyperScope-facilitated LDB, link-type utilization within appropriately developed community conventions and practices, would offer very important enhanced capability for collective knowledge development.
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 knowedge evolution).
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).
Multiple levels of User Interface
[SOURCE: Doug Engelbart, interviews & OHS Draft document]
A “look-and-feel interface” software module will be located between the Command Line Interface and the user. Providing optional modules for selected look-and-feel interface characteristics will serve an important practical as well as evolutionary need. 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 users will automatically learn about their tools and materials, intuitively coming to understand underlying common-vocabulary terms no matter what form of user interface they employ, and may move from more graphically pretty interface modules which spell out potential options at every juncture, to simpler and more flexible interfaces which rely more on the knowledge of the system.
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 based on simple click-on-the icon over simplicity.
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 our evolution toward truly high performance. The bottom line is OHS is easy to get into and easy to evolve in.
EXAMPLE: Icon based GUI system, extensive hierarchal menu systems and high performance command line interface where the user can exert as much control as he or she can remember the commands for, commands which can be learnt while using the easier but less flexible interfaces.
The OHS Interface Architecture will be set up explicitly to provide for multiple UIS options, with a common, full-feature Application Program Interface (API). To support extensive capability evolution, it will be necesary to provide for a range of UIS options, varying in complexity, potential competency level, difficulty to learn, types of interface devices and modalities, etc. Being able effectively to support web-connected mobile phones is one example.
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.
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).
Full Syntax Interaction
[SOURCE: Doug Engelbart, interviews & OHS Draft document]
Today we live in a world of programmers and end users. OHS will change that by giving more flexibility to end users for building their own tools and environments. Instead of the prevailing simplistic icon based interface, which is easy to learn but inherently limited (imagine speaking by clicking on words), OHS builds on a noun and verb language (imagine speaking by typing on a keyboard alphabet. Never mind, you don’t need to imagine that…). The system of nouns and verbs (with high definition dynamic linking) can be combined, given simple logic and even timed:
The Nouns (objects) are any computer detectable objects (of any granularity- fine or coarse, as required).
EXAMPLE Nouns: Text Strings: Visible, invisible, phrase, number. Structure: Statement (node such as paragraph), branch (node and all of its sub nodes), plex (node and siblings) group (consecutive set of branches in a plex, like a sub-plex), and document/file.
The Verbs (actions) are any programmable function the computer can perform on a noun (object).
EXAMPLE Verbs: Copy, paste, append (take two statements {nouns} and append them together), break (break of the lower part and make new paragraph/statement to make a {higher, lower or equal level} new statement), insert, delete, move, transpose, replace, sort, freeze, force.
Combining The Nouns & Verbs provides a powerful way of exercising command.
EXAMPLE: Transpose branches which is like taking two chapters and interchanging them, which can be done even if the two parts are not in the same file. Sort: Sort by rule (such as date/time/alphabetical/second word {in regular or reverse order} etc. and if desired have the results automatically copied if criteria are met.
The Logic is simply the ability to add decision making abilities to commands, based on the If/Then structure.
EXAMPLE: Example Operators: Loops, conditionals (if/then). Example Use: If blind space is found in front or behind paragraph- delete the space. Alternative Example Use: Copy everyones name and number from specified are code only.
Timed Events. Commands can be scheduled to run at certain intervals.
EXAMPLE: Run command every morning at 10am.
Commands Can Be Combined To Create Agents. A series of commands can be compiled into an Agent which can even call upon other agents.
EXAMPLE: Check mail from ‘so and so if so’ has arrived with ‘such and such’ content and if it has, add content to ‘such and such’ a database and launch ‘such and such’ Agent with the senders email address copied to the Agent.
Commands Can Be Given/Entered Through URLs with attached commands, command line interpreter (as used in UNIX and DOS systems among others), pop-up Web page interfaces and point and click icons.
EXAMPLE: Through OHS aware browser: http://www.bootstrap.org/:o will show an outline view of the main Bootstrap page.