HyperScope Features Requirements for version 1.0 HyperScope 

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.

 

 

Vannevar Bush’s Memex

“A record if it is to be useful to science, must be continuously extended, it must be stored, and above all it must be consulted.” (Bush, 1945)

Vannevar Bush was the founder of the precursor to NASA and the chief scientist of the Unites States during world war 2, as the founder and head of the National Defense Research Committee, an agency which he presented to president Roosevelt on a single price of paper which Roosevelt approved in 15 mins with the signature ‘FDR OK’. His singular drive towards technological progress, as his biographer Gregg Pascal Zachary (who joined us for a Future of Text) points out:

Bush’s influence crossed narrow disciplines, shaping the panorama of American experience. His analog computers foreshadowed the emergence of the digital computer, the most far-reaching tool ever devised. Not since Benjamin Franklin had an inventor played so large a role in government. Bush’s management of atomic weapons research, despite initial caution, was a model for later “big science” projects. His unstinting support for federal funding of science and engineering after World War II altered the face of higher education and guaranteed U.S. supremacy in military and civilian technology. His repeated call for military planning and coordination, at a time when defense spending devoured the lion’s share of the federal budget, provided a beacon for reformers.

Gregg Pascal Zachary, 1997

At the end of the war Bush published an article in the Atlantic Monthly with the evocative title ‘As We May Think’ where, as the editor highlights in the introduction: He urges that men of science should then turn to the massive task of making more accessible our bewildering store of knowledge.

Bush introduces a theoretical system: 

Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and, to coin one at random, ‘memex’ will do. A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.

“…the essential feature of the Memex. The process of tying two items together is the important thing” (Vannevar Bush , 1945)

He continues: 

The user taps a single key, and the items are permanently joined … Thereafter, at any time, when one of these items is in view, the other can be instantly recalled merely by tapping a button below the corresponding code space … Moreover, when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly … It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book. It is more than this, for any item can be joined into numerous trails.

The owner of the memex, let us say, is interested in the origin and properties of the bow and arrow. Specifically he is studying why the short Turkish bow was apparently superior to the English long bow in the skirmishes of the Crusades. He has dozens of possibly pertinent books and articles in his memex. First he runs through an encyclopedia, finds an interesting but sketchy article, leaves it projected. Next, in a history, he finds another pertinent item, and ties the two together. Thus he goes, building a trail of many items. Occasionally he inserts a comment of his own, either linking it into the main trail or joining it by a side trail to a particular item. When it becomes evident that the elastic properties of available materials had a great deal to do with the bow, he branches off on a side trail which takes him through textbooks on elasticity and tables of physical constants. He inserts a page of longhand analysis of his own. Thus he builds a trail of his interest through the maze of materials available to him.

And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outraged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail.

To me this is very much about citation handling as well as liquid view layouts. 

HyperScope Features Requirements for version 1.0 HyperScope 

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.

 

 

Vannevar Bush’s Memex

“A record if it is to be useful to science, must be continuously extended, it must be stored, and above all it must be consulted.” (Bush, 1945)

Vannevar Bush was the founder of the precursor to NASA and the chief scientist of the Unites States during world war 2, as the founder and head of the National Defense Research Committee, an agency which he presented to president Roosevelt on a single price of paper which Roosevelt approved in 15 mins with the signature ‘FDR OK’. His singular drive towards technological progress, as his biographer Gregg Pascal Zachary (who joined us for a Future of Text) points out:

Bush’s influence crossed narrow disciplines, shaping the panorama of American experience. His analog computers foreshadowed the emergence of the digital computer, the most far-reaching tool ever devised. Not since Benjamin Franklin had an inventor played so large a role in government. Bush’s management of atomic weapons research, despite initial caution, was a model for later “big science” projects. His unstinting support for federal funding of science and engineering after World War II altered the face of higher education and guaranteed U.S. supremacy in military and civilian technology. His repeated call for military planning and coordination, at a time when defense spending devoured the lion’s share of the federal budget, provided a beacon for reformers.

Gregg Pascal Zachary, 1997

At the end of the war Bush published an article in the Atlantic Monthly with the evocative title ‘As We May Think’ where, as the editor highlights in the introduction: He urges that men of science should then turn to the massive task of making more accessible our bewildering store of knowledge.

Bush introduces a theoretical system: 

Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and, to coin one at random, ‘memex’ will do. A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.

“…the essential feature of the Memex. The process of tying two items together is the important thing” (Vannevar Bush , 1945)

He continues: 

The user taps a single key, and the items are permanently joined … Thereafter, at any time, when one of these items is in view, the other can be instantly recalled merely by tapping a button below the corresponding code space … Moreover, when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly … It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book. It is more than this, for any item can be joined into numerous trails.

The owner of the memex, let us say, is interested in the origin and properties of the bow and arrow. Specifically he is studying why the short Turkish bow was apparently superior to the English long bow in the skirmishes of the Crusades. He has dozens of possibly pertinent books and articles in his memex. First he runs through an encyclopedia, finds an interesting but sketchy article, leaves it projected. Next, in a history, he finds another pertinent item, and ties the two together. Thus he goes, building a trail of many items. Occasionally he inserts a comment of his own, either linking it into the main trail or joining it by a side trail to a particular item. When it becomes evident that the elastic properties of available materials had a great deal to do with the bow, he branches off on a side trail which takes him through textbooks on elasticity and tables of physical constants. He inserts a page of longhand analysis of his own. Thus he builds a trail of his interest through the maze of materials available to him.

And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outraged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail.

To me this is very much about citation handling as well as liquid view layouts. 

Liquid Information
thoughts

by frode hegland

2017

2016

2015

2014

2013

2012

2011