|
Development Environment
Technical/Legacy Environment
Platforms to support:
Transfer methods/protocols to support:
- POP3 - standard mail checking protocol.
- SMTP - standard mail sending protocol.
- HTML 3? - Web standard display protocol.
Minimum Spec computers to support:
Groupware Environment
Conventions etc.
Minimum Capabilities -
Groupware
:
Minimum Capabilities -
Email/Mailing List
:
Minimum Capabilities -
Engelbart
From Draft OHS-Project Plan, Doug Engelbart,
23-Oct-2000 <BI,2120,>
High-Resolution Addressability: 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.
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.
View-Specifications: The HyperScope will offer a set
of "transcoded viewing options" which a user can selectively
employ to examine that file.
EXAMPLE:
just show me the first line of each paragraph.
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. 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. Considerable evolution
is expected to take place here. In the "open-source"
mode, many groups would be experimenting and tuning, contributing
to the evolution.
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:
A. the OHS-dev community (including open-source participants);
B. the Software Productivity Consortium's member community:
C. communities selected with NIH (and possibly cooperatively
with DARPA) for strategic progression of co-evolving tool- and
community-development processes.
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.)
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.
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:
A. Explicit target object being cited;
B. The "foreign" location of the link;
NOTE: both 6a and 6b being very much more
usefully explicit if exercised via HyperScope use.
C. The author of that other-file citation link.
D. The "Type" of link citation, as per the vocabulary
of "link typing" adopted by the usage community, and
provided for inclusion in "link syntax" by appropriate
standardization processes.
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).
Extended addressing conventions to improve linking power:
A. 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.
EXAMPLE: To
a word in a paragraph, to an expressiion in an equation, ...
B. 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.
C. 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.
Non-Link Jumps; Options offered via simple selection
means.
EXAMPLE:
A click in a given paragraph, not on an embedded link, would
hoist that paragraph to the top of the window.
EXAMPLE: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.
EXAMPLE:
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.
We assume that the above capabilities would be useful
to almost any collaborative community, essentially as soon as
adequate HyperScope-application support services could be provided.
(NOTE that a qualified SRI group is explicitly set now to establish
and operate such servics. Optional whether arrangements for this
are pre-established at outset of the "OHS-dev Project",
or later when support of a particular community choose to become
involved. In any event, suitable lead time needs be allowed.)
Special Evolutionary Provision
: Multi-class UIS Architecture
and High-Performance Teams.
From Draft OHS-Project Plan, Doug Engelbart,
23-Oct-2000 <BI,2120,>
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.
EXAMPLE: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).
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 competetive 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."
Maturing/Evolving the Hyperscope into full-feature OHS.
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).
An OHS "User Interface System" (UIS) will be developed
to provide a basic range of functions for moving, viewing and
editing.
Provision for archiving, version control, etc. will be developed
so that it becomes possible to develop and maintain an evolving
knowledge base soley within an OHS environment -- with integrated
flexibility and power accumulated from the best that was accomplished
via HyperScope usage among the legacy files.
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.
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").
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
A the Tool System be as open to continuing evolution as can be
managed, and
B the application communities be specifically organized to participate
pro-actively in the Human-Tool co-evolution.
It is sincerely hoped that organizations investing in the
Stage-1 HyperScope development and use will do so with clear
intent to be simultaneously readying their targeted application
communities for becoming pro-active, "evolutionary participants."
|