>this linear discussion list is not ideal. There
>is the annotation mechanism in PCP but it is not used for dialogue
>based discussion.
>In this way the theory of how PCP should develop might come
>closer to the practice. What do others think?
This issue has been around for almost a decade of computer conferencing. In
the late 80's
considerable discussion was given to conference management and ways of
processing the
linear string into something more accessable.
What follows is what I, as a non programmer, consider is needed to augment
collaboration
on the WWW. If you know of anyone pursuing this, please inform. -- Larry
Victor
OVERLAY HYPERTEXT AND OTHER TOOLS MISSING IN WWW - rough draft
Laurence J. Victor et@primenet.com 95/10/21, 95/09/29
=FE WWW: NETWORKED DATABASE OR MEDIUM-FOR-COLLABORATION
Most contemporary hypertext systems, for computers or for
the WWW, are primarily networked databases. The primary use
is to search for information and to read or download that
information. When nodes are composed for the WWW, they are
intended primarily for searching, not to be commented on or
modified.
Buttons or links are attached to places on the display
during composition of the document to be displayed. Some
websites provide facility to attach a comment to a specific
node, or add a node to the web. Readers are unable to add
buttons or links to displays they read, or attach nodes to
places within a display.
------------------------------------------------------------------
EXCEPTION: Recent version of Quarterdeck Mosaic has a quick
means of attaching ONE note per URL, with a pen/notepad icon
at any point (movable) on the displayed URL. This note is
stored in the users system, but will come up any time the URL
is accessed, even if the URL is not stored in the user's
system. Only ONE note per URL, but this is a start. MIME
(whatever that means) may be a route towards what I recommend
below.
------------------------------------------------------------------
Authors could possibly leave their pages and nodes open to
all to edit and modify; but that would lead to confusion.
Some means is needed to preserve what an author creates, and
yet to permit others to attach links to specific places
within their creations.
The lack of this ability limits the use of contemporary
hypertext and the WWW for fluid collaborative participation.
ListServe interactivity is slow and cumbersome; it creates a
linear string of documents difficult to navigate and
generally too time-consuming for newcomers to read as a
whole. Search techniques can help, but they don't facilitate
the creative/collaborative process.
Many people are unaware of the many potentials for
collaborative interactivity with hypertext as a medium. Old
paradigms often block support for needed development.
=FE INTERACTIVE vs PARTICIPATORY
The term "interactive", as applied today, is limited. The
user can "interact" by navigation choice, but often not
by response parity. I suggest the term "participatory" to
include what is currently missing in "interactive".
=FE POTENTIAL IMPACT ON EVOLUTION OF HTML STANDARDS
The more programs become entrenched to an implied set of
functions and protocols, the more difficult it is to
change. Contemporary computer systems evolved within a
set of narrow paradigms and envisioned future uses. As
the technology improves, new functions can be performed
that were not thought of before because they were
impossible without the new technology.
The long traditions we have had with a more permanent
text that was difficult to modify has set us with an
attitude that we can only append to text -- to reference
back to it, and not to modify it. With the ability to
store older versions and full archives of prior text
systems, we are in a position to dynamically anneal the
the past. (See Neil Larson on "knowledge annealing".)
=FE FUNCTIONAL CHARACTERISTICS OF OVERLAY HYPERTEXT
What I propose may already exist, but is not promoted or
widely used. I propose additional features to be added to
the contemporary hypertext website. Consider a
contemporary website, a system of linked documents (that
can be scrolled, consisting of more than one screenful).
Distinct "buttons" signal links to other documents in the
website, or to other nodes on the Internet. Documents
also contain "forms" that enable readers to export
information from the website, and sometimes link that
exported information to the website -- but not to
specific places on the display of documents. Searches for
specified strings can also be done from within documents.
I use the term "overlay" to refer to a process where one
screen display can be overlayed by another screen
display, but where the source information for the
displays is not altered. For example, symbols indicating
buttons for links could be overlayed over the primary
text without permanently adding the buttons to the
primary text. When viewed, overlay and primary, user
could click on the button and make the link. These
buttons and links are different from those made by the
author of the primary document, primarily in that they
can be quickly and freely added by any authorized reader
(including the author). When the overlay links to another
document or web, the document or web is not part of the
overlay code. The overlay code (or file) contains only
the link information (e.g., URL).
The overlay should be attached to a character of the
display, and not a location in the display - so that
format editing will not disturb the overlay link. This
would permit authors of an original primary document to
edit it without removing most links. When an author edits
a primary document, notification of this may be
automatically sent to all authors of overlays. Authors of
overlays , with certain restrictions, can edit or remove
their overlays.
Other overlays could add guiding structure to diagrams or
other graphics, including textual commentary. These
guiding structures and popup text already exist, but are
part of the initial composed document. What I propose is
for an easy means by which authorized readers can make
their guiding diagrams and popup text available to other
readers of the primary document - without altering the
primary document.
=FE OVERLAYS TRANSFER WITH MASTER
All overlays created by different readers to a primary
document are attached to that document, and copies or
transmission of the document includes the overlays -
unless the raw document is explicitly requested. Advanced
forms could permit a reader or copier to select a subset
of overlays according to specified parameters.
=FE RAPID TOGGLE OF OVERLAY
Readers have the choice to hide all overlays, or to
display only selected overlays. A small window could
display that overlays were present, and possibly
statistics about the overlays. Some may prefer this
toggle to be audio activated.
=FE OVERLAY PARAMETERS QUICKLY ACCESSIBLE
Before making a full jump over a link indicated by an
overlay button, the reader can toggle to view a display
of parameters of that linked document. This information
will be part of the overlay that is attached to the
primary document; the information within the linked
document is not contained in the overlay. Overlays can be
attached to overlays - so a reader may alert other
readers that s/he has comments about that particular
overlay.
Many overlay parameters can be considered:
=FE Overlay author's ID.
=FE Author of documents linked (may be different from
author of overlay - this permits readers to link
documents authored by others).
=FE Date range for addition of overlay.
=FE Category profile of the overlay, such as: recommended
edit, amplification, example, question, reference, etc.
=FE Size of linked document (or time to access speed of transfer).
=FE Type of linked document (text, graphics, sound, web, etc.).
=FE Statistics about the use of the overlay jump.
=FE OVERLAY SELECTION
Some documents could become overwhelmed with overlays.
Readers should be able to select overlays to be displayed
using the parameters for overlays. They could select
overlays only by selected authors, within a specified
date range, and those which propose edits of the primary
document -- for example.
It should be easy to make this selection, from a toggled
popup menu or other device. Statistics of overlays to a
given document should be easily accessible, to assist
selection.
An additional feature would be a means of accessing all
documents which have overlays attached that meet a
specific set of parameters.
=FE LINKED_FROM ACCESS
One should also be able to toggle to a selection process
that displays ALL overlays that lead to that document,
with the ability to jump backwards. Today, many documents
in a web have a HOME button to take a reader to the top
of the web, when they had entered the web from another
web.
When an overlay is attached, and the link specified, the
attachment of the link information to the linked document
should be automatic.
=FE TAILORING OF OVERLAY DISPLAYS
Users will prefer different ways the overlay symbols will
be displayed (size, color, blinking, placement), and
should be able to tailor their overlay display. For
example, it may be preferred that overlay symbols be
displayed in the margin, with overlay lines leading to
the point of reference.
It should also be possible to select some information to
be included in the overlay button, so readers won't have
to click on the button to find out the nature of the
link. Button/icon characteristics, such as color, shape
and size could be used to code for type of link.
Eventually, users may be able to select from a set of
format parameters for the display of the primary
document, whereon the format of the overlays could be
coupled with selected format of the primary document.
Authors of primary documents can FREEZE their format, if
it is critical to the presentation of the information.
=FE MANAGING AND EDITING OVERLAYS
Protocols will be needed for managing and editing
overlays. Also, for keeping an archive of sequential
overlay sets. If many overlays are added to the same
location in the display, or many that fit into common
categories, an overlay menu may be inserted by the
editor. Once an overlay set is edited, readers should
have the option of using either the edited set or the
original set.
=FE EASY CREATION OF OVERLAYS
For this to be useful, to facilitate online
collaboration, it must be easy to create and use
overlays. However, it need not be required that such use
be novice friendly. It may require some training to
become at ease with the process.
=FE HISTORICAL OVERLAYS
=FE FORMAT INFORMATION TOGGLE: PCWRITE & GRANDVIEW
I still use an old DOS PIM called GrandView from Symatec,
which hasn't been updated for 6 years. I am composing
this on GrandView. "Format tags" could be toggled on or
off. A link to another file could be displayed either as
an "*" or as <Link: D:\DIR\FILEFILE.EXT>. Text would
advance and wrap around or shrink back on toggling.
My first 8088 DOS wordprocessor was PCWrite. It had a way
to toggle printing format information, in highlight and
later color. It was possible to compose the string that
would be hidden or displayed. For a time I played with
alternative ascii symbols as special codes for jumps.
Using the bookmark feature, I was able to create a
hypertext on one file, that worked smoothly.
What I called button prefixes and suffixes were composed
of strings which bracketed the bookmark symbol, which
when toggled would display something about the jump.
=FE MIST+ OVERLAY EDITOR
In 1984 I experimented with designing a hypertext online
conferencing system. I used the Microprocessor
Information Support Tools (a version of the EIES
conferencing system created by Peter and Trudy
Johnson-Lenz). This 1200 baud limited system, had an
elaborate line editor. You could create an editing ascii
file that when applied to another document created by the
same editor, made all the edits to what was displayed
without altering the primary document. I was able to
overlay buttons in this manner. By merging edit files, I
could select from a field of buttons only those I wanted
displayed. Technology forced me from MIST before I could
make the system operational.
=FE HYPERCARD
The original hypercard for the MAC (which I studied in
its early forms, but never used) had a complex overlay
feature.
=FE MARGINAL CONTEXT
Ancient manuscripts often were hypertext systems, with
marginalia, and marginalia to marginalia. Modern printing
sometimes employs marginal notation. One can imagine as
system of margin or border symbolism to signify larger
context for what is within the margin. This border
information could slowly cycle (increasing the amount if
info it could contain). It could be an overlay, with
buttons to jump into the context. The border could be
specific to the reader.
=FE CYWEB MERGING & EXTRACTION
Given the back and forth composing/editing of webs, it may
be advantageous to first extract the web of primary
documents to your local storage system, add the overlays
and links, and then merge the overlays online into the
web. Given that all the overlays to a given document are
independent, concurrent creation of overlays will cause no
difficulty.
=FE CYWEB ANNEALING
The design of this system should facilitate what I call
"cyweb annealing" (borrowed from Neil Larson's "knowledge
annealing"). Annealing involves collaborative editing and
modification of major webs: nodes and links, text format
and graphics, content, etc. Document components from older
versions can be included (with historical back-reference).
This involves some of the principles in Ted Nelson's
Xanadu. What were once overlay buttons can be incorporated
into permanent buttons in the annealed web.
=FE EVALUATION
Feedback from users and statistical analyses of feedback
will be needed to guide web annealing. Special overlay
buttons can lead to easy-to-use evaluation forms.
Evaluation forms may even use auditory input or feet
input.
If there is major disagreement re annealing, there can be
alternative annealed versions made.
=FE CYWEB SKETCHING
The architecture of nodes and links for a hypertext web is
independent of the appearance of the nodes in display.
Composing attractive displays takes time and effort. Once
composed, a person is often reluctant to change them. The
architecture of the web can be proven functional only with
use. Users will recommend new links and breakup of single
large displays into smaller linked displays. To jump or to
scroll? Thus, it is efficient to have a way of rapidly
sketching the architecture of a web, with readable
content, before effort and time is given to display
design.
Neil Larson's system of hypertext authoring tools is very
suitable as a hypertext sketcher. Neil's software has many
limitations, but also many tools for rapid hypertext
architecture construction. He has tools for checking for
buttons without links, loops, displays of all links to a
given node, etc. Recent versions include graphics and
audio. Limits are one frame per screen, no windows, no
mouse action.
The concept of hypertext sketching has been difficult to
communicate, as if the architecture of the web was not
that critical, or could be designed without testing in
actual use.
=FE SECURITY
Security is a concern, but not a barrier. Authenticity of
authorship is essential, including the author act of
creating links.
Of greater concern, is the security of web data to
breakdown or sabotage. Also, the more realtime working
offline, the less load on the physical web. Neil Larson's
crude online hypertext system enabled you to navigate a web
on the host, but with each jump it first checked to see if
the node was on your own (remote) system. If it was, it was
not downloaded, but your file was displayed. If the date,
time, or filesize on your web was different from on the
host, the nodefile was automatically uploaded. Whenever you
finished navigating a web, ALL that you did is now
preserved on your own web. This feature should be extended
for all WWW interactivity.
=FE QUICK SEARCH FOR WEB WEAVING