$Id: ct-old.wml,v 1.1 2000/09/13 14:58:08 tjl Exp $
lukka@iki.fi
This is a preprint of an article to appear in the Cybertext Yearbook 2000,
edited by Markku Eskelinen & Raine Koskimaa, to be published by Research Unit
for Contemporary Culture.
All trademarks are the respective trademarks of their owners.
This article attempts to give an overview of the activities of the
Hyperstructure Group at the University of Jyväskylä.
The group, founded in fall-99 is focused on a long-term collaboration
with Ted Nelson and implementing and testing
his ZigZag design and some Xanadu designs.
The most basic idea
underlying all of our work is that today's computers do not
allow the user to store and visualize most of the real structure of
his information.
An interesting feature of this problem is that it is never visible
on a small scale, with a few documents or files. On a small scale, the human
brain is able to superimpose the true structure of the data on the
structure forced by the computer (filenames and directory hierarchies).
Unfortunately, most software is only tested with small amounts
of example data in the prototype stage.
If there are hundreds of documents, modified by dozens of people,
it is easy to fall into chaos unless the true structure of the data
is used. One simple example of such true structure is that of origination(XXX):
being able to track all text across several cut&paste operations and
visualize this makes it simple to see what rearrangements other people
have done on a piece of text after having seen it last time.
Our work is based on Nelson's ZigZag structure XXXREF, introduced below.
We often use the term ``ZigZag structure''. This is an approximation:
ZigZag is in a sense a metastructure with which it is easy to model any
structure, even structures that would be difficult to model on paper
or on usual computer programs without a special program designed explicitly
for that structure - for example a family tree.
ZigZag is a new way of putting information into computers, kind of a crossing
between a database, a filesystem, a personal information manager and
many others. And even that isn't sufficient to describe it: it's simply
something new.
There are two important differences between systems built on ZigZag
and "normal" computer systems.
First of all, files and directories are unnecessary (REF paradigms).
A traditional filesystem uses filenames to refer to large chunks of
information and possibly HTML-like anchors to refer to smaller pieces
inside the files. This is a fragile way of representing the information
since the only structure stored by the system is the files based
on the names - finding which files reference a given file is timeconsuming
or requires a pre-indexing scheme.
ZigZag is a flexible hyperstructure, allowing different micro-level
connections between various pieces of information.
In ZigZag all references are two-directional and do not work through
user-visible namespaces. Rather, the micro-level two-directional
referencing is built right into the system. Changing some of
the connections of a piece of information (e.g. renaming the "file" it
is inside in the listing) will leave the other connections unchanged.
XXXXX
Second, in ZigZag, all
the information about the system will be stored in the same structure.
In Windows, there is a filesystem and separately from it, there is the
registry. In UNIX, there is just the filesystem with configuration
information for applications being represented as text files inside
the same filesystem; same tools can be used to edit normal text files
and configuration files.
ZigZag takes this a step further: all information is in the same fine-grained
structure instead of the coarse "file-grained" structure.
The same tools can be used to edit any part of data on the system, be it
metadata, configuration information, user interface bindings or a spreadsheet
or document. XXX selitä paremmin
In ZigZag, all data is in cells, much like a spreadsheet.
The only important difference is that while a spreadsheet enforces
a two- (or possibly three-) -dimensional lattice structure
between the cells, ZigZag allows the cells to be connected in
a much freer way.
First of all, the number of dimensions is unlimited.
Like on a spreadsheet, a dimension is still structured so that
each cell may have one predecessor and one successor on each
dimension, and the converse relationship "A is B's successor
implies B is A's predecessor" holds.
However, there are no restrictions between the dimensions
for the connections: for example, in the figure,
the cell A is located two steps right and three steps up
from itself (right =
To manage the potentially infinite number of dimensions,
they are referred to with descriptive strings.
The most commonly used dimensions are the three general-purpose
dimensions
The strength of using dimensions instead of names (as in filenames)
or numbers (as in pointers or references) to refer to other
information is that all references are two-directional.
This is an important feature since a large fraction of programming
errors in languages such as HTML or C++ have to
do with referring to things
that are no longer there: on WWW, moving a page or changing the
name of an anchor on a page breaks all links to that page or anchor,
because the links are strings, naming the previous location.
In C++, the references are pointers, i.e. numbers representing
memory addresses: if the object being referred to is not any
more at the given address, the program crashes.
ZigZag introduces the concept of connection
on a primitive level and obviates the need for making new systems
of referencing for each new program. XXX
There are many different possible structures with similar
capabilities. What makes ZigZag special is the beautiful tradeoff
between simplicity and complexity: each cell's neighborhood
is limited by the two-neighbours-per-dimension rule but further
away the cells can be connected to each other in a free fashion.
Given the complexity of the structure, it is usually impossible
to see it all at once. Focus&context methods (XXXREF) are
useful for simple visualizations: two or more dimensions are
chosen, and the cells near the user's focus (cursor) are
laid flat on the screen using those dimensions, as far as is
possible within the limits of the structure. Since the structure
locally resembles a spreadsheet, this visualization is extremely
navigable, especially with animation between the motions.
There are several different possibilities for choosing which cells
to place where, called rastersXXX.
The vanishing raster, for example, renders all cells
up to a given number of steps from the cursor, while
gradually reducing the size of the cells. This gives the user a good
picture of what is happening slightly further along in the structure
and uses the depth perception cues of the human eye to a great
advantage. There are also rasters based on rectangular grids,
with the two most important ones being the vertical and horizontal,
which
Examples of these rasters showing a looping structure are shown in
XXX.
Motion is performed through the keyboard or the mouse.
Many simple edit operations take directions as parameters,
so for instance, creating a new cell leftwards from the current
cursor is achieved by pressing n and then the same
key that normally moves the cursor left (l).
The basic operations include connecting and disconnecting cells,
moving the cursor, rotating the view (choosing different dimensions
to show on the X, Y and Z axes) and modifying the text in a cell.
There are also some more complicated operations that are especially
useful, such as hop, an example of which is shown in XXX.
Currently, computers are complicated and messy.
Application code has to worry about the structure of data on
disk, the structure of data in memory, and the structure of data
held by the operating and windowing systems.
All these are usually different and cause applications to
translate between each other, making the application overtly
complicated.
ZigZag represents all this data in the structure: the structure is
persistent and unified.
Just as with virtual memory,
the program does not need to care whether a cell
is in memory or on disk. The logical structure
is the same. Of course, to retain an acceptable level of performance,
solutions such as transient cells or saving only every n
seconds have to be devised but these are optimizations rather
than fundamental structure of the application.
The unification of the structure is more difficult to explain
since it reflects a completely different mindset from the ordinary.
Ideally, the lower-level code which takes the structure and renders
it on screen will have to know only one cell.
From this cell, it uses the structure to find what windows are
where, which cells to show
in the centers (via
This greatly simplifies programming in ZigZag since all
operations can be expressed as alterations to the structure.
For example, when the user presses a key to move the cursor left,
what happens is that the callback code looks through the structure
to see which dimension is currently "left-right", then looks
for the cursor and the cell leftwards of it. Finally, the code
connects that cell in the structure so that it will thereafter
be interpreted as the cursor.
There are many other benefits as well: since all operations
are in the structure, scripting becomes trivial since everything
can be achieved simply through modifying the structure.
Unification of data is not a new idea: the original
UNIX philosophy of "everything is a file" contains some of the same
spirit. However, the UNIX APIs still force the loading of files
into memory into a different representation; in ZigZag, the cell
structure is all you need.
Another previous version of the same basic idea is the
popular Model-View-Controller paradigm (XXXREF), where a program
with a user interface is split into a model and
user interfaces (views and controllers) to that model.
This structure makes it simple to add a new view to the same data.
ZigZag takes this approach to new heights by providing a
global model which all features of the visible display
use.
Permascrolls are a concept that originated in Xanadu88 (XXX???).
The essential idea is that whenever a piece of fluid media
(i.e. text, audio, video, image) enters the system, it is assigned
a permanent identifier. After that, all references to that
piece of media go through that identifier so that it is easy to find
where a particular piece of text has been cut&pasted to, for example.
Permascrolls seem to be the most easily misunderstood part of
Xanadu88 because with today's web, confusing the physical
location and the identity of a document is easy. A permascroll
does not mean that all information should only be
stored in one place. It is not an URL, but more like an URI: it
is an identifier which is known to map to the same information
always. It is also more fine-grained than run-of-the-mill W3C
URIs, as it allows referencing any subset of the original up to
an atomic level.
Most commonly it is not single atoms in the permascroll that
are referred to; rather, the reference type is
span, which is a reference to a single contiguous piece
of a permascroll.
XXX SELITÄ VSTREAM HETI
In the permascroll paradigm, a particular version
of a "document" is represented as a vstream: a list
of spans. Editing a document then consists of adding a new
span, splitting existing spans, deleting existing spans and
rearranging spans.
ZigZag supports permascolls by allowing a cell to contain
a span (a reference to a single
contiguous piece of the permascroll).
A rank of cells on a dimension (usually
To reiterate, a permascroll is not a place:
it is a state of mind, in which you keep track of what all
information copied or cut&pasted originally was.
For example, it is planned that in a future version of GZigZag
the user will be able to send an email with some cells
as well as the parts of the permascroll that is referred to
by those cells. The recipient's computer can then
store those pieces of the permascroll and notice if any other
references to them exist.
In fact, permascrolls are excellent candidates for caching since
the identifiers to the content are indeed permanent, unlike
on WWW where the content of a cached URL can change at any time.
Another application where permascrolls show their power is
comparison: most utilities used for text comparison (e.g. the
unix
It is possible to overcome some of this problem by writing
more and more refined algorithms for finding similar texts but
once we get to phrase-level elements, they become useless since
the same phrases can occur again and again in a document.
With permascrolls, rearranging a text file is not about moving
the text content - it's about moving pointers to the
content. So two different revisions, the latter of which has
been rearranged, still point to the same spans of text in the
permascroll. Now, visualizing the differences becomes easy:
all that is necessary is to point out to the user which pieces
of text are stored in the same place in the permascroll.
See Figure XXX below, where this is demonstrated.
This feature may seem like unimportant but in projects with more
than one worker and much rearrangement of the manuscript
it can be truly invaluable for finding where a certain part of the
previous version of the manuscript ended up.
Although interesting, the above structure and visualizations
would fit most applications rather poorly. However, given the
basic ZZ structure it is simple to define new visualizations.
Taken together, a visualization and operations are referred
to as an applitude,
as opposed to the traditional term application
since all the data is still in the same structure and other
operations can be used to edit this data and these operations
can be used to edit other data.
For example, a vstream is a kind of an applitude: there is a
clearly defined internal structure and special operations for
the vstream for inserting and deleting characters.
There is also a good visualization of a text vstream: simply
the characters in a paragraph (formatting capabilities will
be added later).
The default cell-based visualization and the natural vstream
visualization for a small piece of text is shown in XXX.
Note how the colored cursor is shown in both panes.
The interesting thing about applitudes is that they can be designed
to be connected to each other in a more fine-grained fashion than
current embedding frameworks such as Bonobo, KParts, or OLE/COM.
In this section, we'll look at some functioning applitudes.
As explained in the previous section, the strength of ZigZag lies in that
all these applitudes can be used together fairly easily since all the data
is stored openly in the ZZ structure.
One important function that GZigZag provides for all applitudes is
animation. This works by associating a cell with all "things"
that are rendered on the screen.
When two "things" in subsequent keyframes (i.e. the fully rastered frames)
are associated with each other, the system generates as many interpolated
frames between them as the speed of the host machine allows.
The time between keyframes is estimated from the interval between
the user's keystrokes: the system attempts to be ready 100ms before
the user strikes the next key. This gives the system a fluid, responsive
feel while allowing smooth, slow animation if the user is moving slower.
An example of such animation can be found in XXX ANIMATED GIF ON
GZIGZAG PAGES
One of the points Nelson has made in several talks (XXX??? on paper?)
is that the term "cut&paste", as used in the computer field, is
a really bad choice of words. Originally cut&paste meant physically
cutting a text into pieces, rearranging the pieces and glueing
them together. This seems a little similar to what the computers
do.
However, there is a crucial difference: in physical cut&paste,
the text can be cut up into as many pieces as desired;
all the pieces are visible all the time; the pieces can be slowly
rearranged into the optimum order in a parallel fashion.
Indeed, when the text is cut up, the actual data model
of the text
is changed from the single text stream to a cloud of text
fragments.
Most current computer programs (XXX Exceptions?) force the user
to stay within the formal one-stream text model all the time during
editing, except for a single piece of text cut onto the "clipboard",
which is not seen.
This is why several people (REF: private communication) seem
to use a second window next to the main one to hold fragments.
This, of course, has several disadvantages: the fragments are
stored separately from the main body of text, the fragments still
have to be stored in the one-stream text model and the system is
rather clumsy. Of course, some people are able to write near-perfect
prose in near-perfect order.
One of the interesting differences between this system
and the dominant paradigm is the way of selecting text.
In most current systems, selecting text is performed by
painting, i.e. pressing the mouse button at one end of the
span being selected and releasing the mouse button at
the other end. In the TextCloud demo, text is never really
"selected" in the same way: instead, the user can make any
number of cuts into the document using the right
mouse button. Then, when the user presses the left mouse button
on some text and drags, the text is separated at the neighbouring
cuts to allow the user move a single piece of text.
Already Nelson's original mockup pictures about Xanadu
(see XXX (pic on WWW))
include transpointing windows, i.e. windows which show the
connections of their respective contents graphically.
These connections can be either transclusions or links. In this
article, we concentrate on transclusions.
GZigZag is probably (XXX???) the first system to implement such
transpointing with beams: an earlier Xanadu client Pyxi by XXX
shows transclusions by colors but does not do transpointing.
The TextCloud applitude is a good place to see the transpointing beams
in action: simply copying (i.e. dragging with Shift-MouseButton1 instead
of just MouseButton1) a vstream creates a transclusion and the
beam appears. Then, when editing one (or both) of the streams by
cutting&pasting text the beams remain
connected; this is because the beams are really connected to the actual
text content, not just the external object.
The TextCloud is a simple model and its current implementation clear
limitations: all text must be stored in this one area and the size
of the text cannot be changed.
Also, it does not interface well with the other parts of the system.
It is simply one step on the way towards the full system, in order
to test one user interface aspect of it.
A different way for editing longer documents is through putting
vstream fragments of the documents in ZZ cells which are then rendered
in a raster. All the structural capabilities of ZigZag are
then in use for rearranging the pieces.
This being ZigZag, note that "putting fragments in ZZ cells"
does not a literal inclusion but an interpreted inclusion:
the view has a special raster which knows how to look for
the vstream to include in a cell.
When the space is being rastered,
Unfortunately this demo is not yet finished so we cannot offer
a screenshot.
Hypertext has come to mean "WWW-like" in many places:
a paradigm where the user is presented with one lexiXXX,
performs a selection, for example clicking with the mouse,
and is taken to another lexiXXX.
GZigZag makes it possible to easily create a wealth of flexible
visualizations that do not use such fixed screenfuls of text.
This is because GZigZag is built in a modular fashion and makes
it easy to describe a new visualization.
For example, let's start with a text model that contains
simply paragraphs of text, one after another.
In this section, we come once again to a problem which
does not exist for small data sets. If there are
only 10 messages in
a mailbox, it does not matter in the least how incredibly
bad the mail reading program is:
humans can still manage since they can remember
and overlay the true structure on top of the rigid and unnatural
structure imposed
by the mail reader program.
However, consider the linux-kernel email list or
corresponding high-volume newsgroups on the usenet.
Most programs for reading news or email are based on the assumption
that the reader wants to read all or most of the incoming messages -
a natural assumption stemming from the original volume of the forums.
However, with time the number of messages in a forum has grown
unmanageably yet programs mostly offer only rigid pre-selection systems
such as killfiles which remove all messages with a given subject
or sender from the view.
ZigZag and FloatingWorld provide an interesting alternative
which we have so far had time to only scratch the surface of.
When a mailbox or a newsgroup is incorporated into the structure
correctly, it is simple to write interesting visualizations
that show some of the emails.
The structure underlying the email applitude is described in
FIGUREXXX.
The first, simplest visualization FIGUREXXX
is simply the traditional
mailbox visualization, offered by many programs such as Pine, XXX.
This simply shows some of the most relevant header fields of
messages on each line, arranged vertically in the mailbox order.
Already here ZigZag has several tricks up its sleeve. For example,
a message may be stored in several "folders" (lists), either
by using different dimensions for different folders or by
cloning the headcell of the
message onto different ranks on the same dimension.
Another trick here is that it is easy to see which folders
a given message has been connected to, since all connections are
two-directional. This is an advantage caused by the fact that ZZ
considers the message to be an entity rather than a stream of
characters that can be copied but has no identity
(like emails in normal email folder files).
Sorting the emails is of course possible, either by presorting
and making a rank of them and using that
or by post-sorting at each time they are shown.
For sorting, ZZ offers an interesting user interface: when the
user moves the active cell horizontally, the list of
mails is shown sorted according to that cell.
XXX Mailboxes, many folders per email!!!!!
XXX Good argument for postsorting or cached postsorting.
XXX Notifications
Now, one interesting thing that ZZ offers is multiple windows
with different views whose cursors are bound together (using
the cursor-cargo mechanism; see the ZZ Spec XXXREF).
All the views above have one "active" cell. We can have several
useful views visible at the same time, which stay in lockstep with
each other.
The FloatingWorld model offers an alternative: messages
or icons of messages can be shown in a two- or three-dimensional
coordinate system.
Such a system is trivial to implement in a general fashion
using ZigZag since the homogeneous structure makes it simple
to specify paths to obtain coordinates through, whereas if
using a traditional programming language, it would be all too easy
to restrict the world of possible coordinates to some set
that is easily specifiable in the structure that was chosen.
Additionally, normal email programs or HyperMail (XXXREF)
-like HTML indexers treat the messages as their own, making it
almost impossible to link the discussions into the places where
they would belong: for example, linking the discussion leading up
to a particular decision in a standard (say XHTML) into the place
in the standard would be an invaluable aid to those trying to
understand afterwards how something is supposed to work.
Consider, for instance, a document such as the Kernel Traffic
weekly newsletter (XXXREF) which summarizes the main discussion threads
on the Linux-Kernel mailing list that week.
XXX transclusions, etc.
- editing trad. hyperliterature easier: visualize the STRUCTURE of
the whole work, then rendered into HTML
A long-known problem in scientific publishing on paper media is
that bibliographic references are always backwards in time, while
it would often be more interesting for the reader to
know the future references, i.e. either articles that refer
to the current one or articles that the author has deemed
interesting enough to refer to at a later date from publication.
Now, in the Xanadu model, quoting is equivalent to linking because
of transclusions.
Transclusions may seem foreign as an instrument of quoting and
responding to a selected portion of an article. However, they
are actually quite close to another widely used paradigm: quoting
when replying to an email. The only addition here is that
the quoted parts (which are somehow visually indicated) are
not copies but transclusions from the original article. Because of
this, they are actively connected to the originals in an implicit
two-way link.
The system of moderation used on sites such as
Indeed, this sort of publishing system could create a far more
interactive scientific discourse.
For example, a user can choose which links he wishes to see
when reading an article: refereed links, all links, links by certain
persons etc.
GZigZag, which is the program that is shown in all of the screenshots
in this article, is free software. It is distributed under the FSF's
Lesser General Public License (LGPL) and is available on SourceForge.
In the language of the free software community, "Patches accepted".
http://www.acm.org/cacm/AUG96/antimac.htm
This article uses many terms that are most likely unfamiliar to the reader.
We attempt to summarize the most important ones below.
This section contains rejected pieces of text that may still
have some interest.
Naturally, if desired, dimensions can be used to construct
systems analogous to files and directories: for instance,
a number of cells going down
This is somewhat analogous
to the hyperbolic visualization
for graphs (XXXREF): hyperbolic space also looks locally like
Euclidean space but there is more "room" because the correspondence
to Euclidean space does not hold over distances.
An interesting similarity between the two is the volume of balls:
in hyperbolic space, the volume enclosed in a ball grows exponentially
with the radius and the same is true for ZigZag - if
desired; ZigZag cells can also be arranged in a less complex
fashion where the growth of the volume of balls is more restricted.
Introduction
Basics of ZigZag
Cells and dimensions
d.2. The rules of the ZZ structure
are that each cell may only be on one rank along a given dimension.
d.1
d.1, down = d.2).
d.1,
d.2 and d.3 and then d.clone,
used for logical duplication of cells and d.cursor, used
for pointing. These uses are mostly a matter of convention.
Rasters and operations: the default UI
Totality of the structure
d.cursor) and which dimensions
to raster along (also via the structure).
Permascrolls
d.2)
can then be interpreted
(see next section) as a virtual text (or other media) stream.
diff utility) do a reasonably good job if the
user is simply adding or removing or changing small pieces of
text. However, such tools have great troubles with rearrangement,
exactly because of the lacking text model where only the content,
not the origin is stored. Thus, a rearrangement usually shows
up as large insertions and deletions, which is actually exactly
what it is, in the primitive text model.
Alternative visualizations: applitudes
Some Textual Applitudes of ZigZag
Text cloud - real cut&paste
Editing longer documents using cells
Hypertext without lexias (XXX?)
Email or forums with coordinates
Editing hyperliterature with nodes
Scientific publishing using Xanadu hypertext
slashdot.org
is surprisingly similar to the scientific refereeing process.
The privilege of moderating other users' comments is granted
to established members of the community (members whose previous
moderations have been approved by other members), the process
is anonymous and determines on whether users get to see the comment.
However, there are important differences:
Upon consideration, some of these points are quite applicable
to scientific publishing as well. Specifically, the "letters
to the editor" section of scientific journals seems to be the
closest that print journals can come to this kind of convenience.
The Code
Conclusions
Acknowledgements
References
Glossary
SCRATCH
d.2 can contain names
and these cells are connected on some dimension to the content
for that "file".