BACK TO THE FUTURE:
Hypertext the Way It Used To Be

Theodor Holm Nelson and Robert Adamson Smith
Project Xanadu

 

ABSTRACT.  Others imitate paper (Word, Acrobat) and the constant 3D world we live in ("Virtual Reality").  Our system instead tries to create documents better than paper in a space better than reality.

Intellectual property notice: The following are trademarks of Project Xanadu, registered or claimed: Xanadu, ZigZag, XanaduSpace.

 

The purpose of hypertext was always to make up for the deficiencies of paper.  Paper cannot easily show connections, has very limited space, and forces an inflexible rectangular arrangement.  Hypertext, the generalization of writing, potentially offers many forms of interconnection and presentation beyond what paper allows.  But so far the mechanisms, not the users, have been put in control.

Here are mechanisms that get in the way:

1.  The simulation of paper.  Much of the field has imitated paper: in word processing (Microsoft Word and Adobe Acrobat) and the World Wide Web, whose rectangular page layouts become a focal issue.  It should be noted that these systems imitate paper under glass, since you can't annotate it.

The imitation of paper has been enforced by the motto WYSIWYG, "What You See Is What You Get"-- meaning what you get when you print the document out.  This simple propagandistic locution legitimizes paper simulation, and printout, as the proper destined objectives of computer documents.

This ignores the more important possibility: how improve on paper?  WYSIWYG seems to us absurd: by fetishizing print layout (typeset vertical strips) as the only view of a document, we penalize the user.  Any number of views-- and structures-- should be possible.

2.  The imitation of physical space.  Extending the imitation of paper, the usual approach to 3D has been "virtual reality"-- the literal imitation of 3D space, where we go beyond imitating the paper to imitating the desk, the room, etc.  This extends the same limitations of paper simulation to 3D: everything must be literal, everything must stay the same size in a constant metric.  Again, we believe this is very limiting, and has been the reason for the fading of the Virtual Reality movement.  The real issue is: how improve on conventional space?

3.  Crude links.  At least since the Hypertext Editing System at Brown University in 1968 (10), hypertext links have generally--

- been one-way
- not allowed overlapping of either source or target endsets ("anchors")
- not had types

This crude structure has been a source of regret for which some of us have apologized in print (2).  Crude links drastically reduce the types of document, structure and connection that can be represented.

4.  Embedded, inextricable hierarchy.  The web formats, including more recently XML and Cascading Style Sheets, are all based on internal hierarchical representation of structure and markup.  This further limits the forms of structure which can be represented.

3.  Simplistic mapping to files.  The standard paradigm of files, unquestioned almost everywhere, drastically affects how everything works.  One document is assumed to be one file-- a strange requirement, but it reinforces the one-way linkage restriction currently in place on the World Wide Web.  (Since the HTML file contains the links, they can only point outward.)

In this conventional file model, "metadata" can be only on files as a whole; there is no way for metadata to flag, mark or protect particular contents of files.

We believe people accept these limitations because they do not perceive them as limitations, or imagine alternatives.

People accept th

We are not just building a different kind of hypertext, but seeking the most general form of document.  The issue is how to represent all possible documents.  This means throwing away: simplistic file mapping, paper simulation, 1-way links, hierarchical markup, WYSIWYG and the simulation of fixed 3D space.

Our document structure is very different from paper (although rectangularity is allowed as an option).  A document may be divided into arbitrary units; the default visualization is a vertical strip, but very different structures and presentations are also possible.  A document may consist of any number of such pieces, which we call "vunits," or viewable units.

Text may in principle be organized and shown in such vunits as

- rectangular pages
- text stramers and "crawls"
- overlays
- flying paragraphs
- fountains of text
- rippling surfaces
- animated and changing texts

and other structures to be definable later.  (We can even call them all "pages," provided the possible variety is understood.)

These are intended not just as novelties, but as full-status content packages: all contents are

- linkable
- transclusible (showing their origins)

They may all be connected side-by-side, like columns in a book, table or spreadsheet..

We allow any number of

- links
- structural relations
- views
- interactive methods

all selectable by the user.

This is transliterary structure, discussed below.

The earliest published design for computer hypertext was a 1965 ACM article (peer-reviewed) which canonically defined our work (0).    One of the authors (Nelson) presented a sweeping view of hypertext as visibly cross-connected by two-way links and transclusions* (illustration from that article reprinted here as Fig. 1).

* I define "transclusion" as "the same content
knowably in more than one place";
therefore, any presentation which indicates
the identity or origins of media content.
There are other meanings of "transclusion"
which are special cases.  For instance,
"transdelivery" means bringing content
from elsewhere,
"transquotation" means explicit quotation
which remains connnected to its origins.

Vannevar Bush's famous "trails," described
 in 1945 (1), were transclusions, not links.

Fig. 1  Panoramic view of postulated hypertext, 1965 (fig.4 from (0))

Subsequent hypertext has been very different, based on one-way non-overlapping links, as established in 1968 (10) but clearly foreshadowed by Engelbart (11, 12).  We return now to our previous 1965 model, implementing a generalized document structure and showing it in an unusual space that offers great flexibility.  In addition, we have a presentational mechanism (the reading plane or line of fire) that makes it easy to follow connections in a complex hypertext structure.

Note that the connections in this picture are two-way.  (Light lines represent one or more links, heavy lines represent one or more transclusions-- described then as "some of same entries".)

We believe that this link-and-transclusion view is still fundamental.  It is exactly what we have implemented today in the "XanaduSpace" software, as shown by a screenshot (Fig. 2).  Dark bands in the screenshots are links, red bands are transclusions.

Fig. 2.  Panoramic view of hypertext in XanaduSpace.

These two types of connection (links and transclusions) may overlap in any quantity-- for instance, connecting a given paragraph to numerous other documents.

ANY NUMBER OF VIEWS

Instead of WYSIWYG, we may view a page or vunit in a variety of ways-- for example, rolled into loops (Fig.3).  Many more views may be added with relative ease.

Fig. 3.  Documents shown in loops (XanaduSpace).

This extensibility of views can have numerous advantages for document use and understanding.

A key problem of hypertext is colloquially called "lost in hyperspace."  To be lost in hyperspace usually means that you don't know where you came from or where you can go in a world of invisible links.  However, even when the connections are made visible, they can be hard to follow-- especially as they grow in number.

We have found a new viewing mechanism that seems to answer this problem.

We call our solution the reading plane, or line of fire.  (Fig. 4)

The reading plane shows a current page or vunit in 3-space, at center screen.  This allows close-up reading in a larger context-- showing both content and connections to vunits elsewhere. The user may select a current link or transclusion in the current page, causing the vunit at the other end of the connection to swing into position beside it.  We call this the companion page, shown here with smaller type than the current page (figs. 4, 5).

The user may switch attention to the companion page, making it the current page.

This appears to work very well.  The user can clearly read the current page and follow connections in it.  The user can also see what page is swinging into position and what pages are not current.

Fig 4: Two pages in line of fire, other pages
of hypertext visible.  (XanaduSpace.)

The line of fire is also particularly good for seeing tranclusive origins (fig. 5).
 

Fig. 5.  Line of fire, showing transclusion from companion document to current document (XanaduSpace).

The line of fire thus shows the current page and at least one connected page close up and readable, yet at the same time a whole scene of many pages can remain visible to show all the connections among them at once.
 

The documents of XanaduSpace follow the open document standard of Transliterature, or transliterary format, as defined at transliterature.org.

Transliterary structure is meant to be the fullest generalization of documents.  This means being able to represent all possible document structures, and to deal with the vicissitudes of change, versioning and copyright.

Transliterary structure is the latest version of the Xanadu project.  "Documents" are packages of content constructed by authors from new and old text, audio and video, in any arrangement and pieces and desired appearance.  And "literature" means collections of documents, with all their possible connections.

The Xanadu project has sought to solve all at once the issues of--
    - profuse links of many types
    - recognizable re-use of content from elsewhere
    - version management
    - distributed update
    - copyright (esp. through individual purchase of portions through a micropayment system)  (7)

Instead of one package of primary content and embedded links in a single file (the HTML model), we separate--
    - document model
    - content acquisition
    - simple structure (parallel strips of content)
    - overlaid structure (rearrangement, typography)
    - external structure (links)
    - history

We believe this approach can solve these many problems, and others; but it requires totally different forms of representation and methods that may seem counterintuitive and overly complex to those used to the present computer world.  However, the conventional methods require wide-ranging external methods to achieve what we try to achieve directly through these document structures and methods.
 

Imagine that everything you type is given a permanent, immutable address.  Then to refer to a given sentence, or paragraph, you would refer to its permanent address span (start, length).  This would have many benefits.

This is not the way things are ordinarily done, but in this system we simulate such permanent addresses in order to get these benefits.
 

0.  A transliterary document is delivered as an EDL, or Edit Decision List, which is empty of content--
    - a list of content to be put together (currently text, later audio and video)
    - a list of floating links to be overlaid on that content

A document may contain one or more visible units (pages, flying paragraphs, etc.) to be fulfilled with content.

1.  A client program (such as XanaduSpace) sends for the content of the document from the respective addresses of the different portions.  They may be local, remote, or both.

Addresses of content don't change, since content portions are based on stabilized addresses.  The obvious issues of availability and stabilization we see as pragmatic (5,8).  (This has been widely misunderstood in comments on our work; people have thought we would reach across the net for every instance, and that broken network connections or changed source documents break the model.  This misunderstands our broader intent.  Naturally, the material can be cached; but the logic of the system maintains its original identity and address.)

2.  Once these pages have been fulfilled with their content, they may be overlaid with flinks (floating links), which may include relations, structure and typographical markup.  Links are neither embedded nor hierarchically represented.

3.  Transclusions are not present in the data structure; the client program discovers transclusions by finding identities in the addresses.

4.  The default structure (vertical strips or pages) may be overridden by structural flinks.

Additional aspects of XanaduSpace are discussed in a current paper (8).
 

To escape from the limitations of files as we now know them, transliterary structure has been designed to obey a particular rule of combination: Division into files need not affect the structure.  Transliterary document structures may be broken into files many different ways and still behave the same way.*

* This also applies to our hyperthogonal database structure,
ZigZag, which may likewise be broken into files variously.

ESCAPING FROM VIRTUAL REALITY: (N)D FOLDING SPACE

By "folding space" we mean a pseudospace, presented to a user, whose proportions can be changed in more than three dimensions.

For example, a 3D model of a house may be squashed flat into a 2D picture, or stretched out of proportion.  It can also, in principle, be extended into a fourth dimension showing its physical changes and value over time, and other dimensions showing parametric variations among houses built from the same design.  (Note that such visualizations are tricky but doable.)

These flexible arrangements allow the presentation of ideas and relations which could never be presented before.
 

We hope that Transliterature, as first instantiated in XanaduSpace, will define a new document form allowing parallelism and unlimited interconnection, yet be easily readable, annotatable and re-usable.  This should put profuse interconnectivity and annotatability within reach of all users, and free us from the printer.

0.  Theodor H. Nelson, "A File Structure for the Complex, the Changing and the Indeterminate." Proceedings of the ACM 20th National Conference (1965), pp. 84-100.

1.  Vannevar Bush, "As We May Think."  Atlantic Monthly, July 1945; on line at http://www.theatlantic.com/doc/194507/bush
and elsewhere.

2.  Theodor H. Nelson, "Lost in hyperspace."  New Scientist magazine, issue 2561, 22 July 2006, page 26.  Available on line at
http://www.newscientist.com/article/mg19125610.300-lost-in-hyperspace.html

3.  Theodor H. Nelson, The Future of Information.  ASCII (Tokyo), 1997.

4.  Theodor H. Nelson, Literary Machines, various editions.  Published by the author; available from Eastgate Systems.

5.  Theodor H. Nelson, "Xanalogical Structure, Needed Now More than Ever: Parallel Documents, Deep Links to Content, Deep Versioning and Deep Re-Use."  Available at various addresses; canonically from Project Xanadu, at
http://xanadu.com/XUarchive/ACMpiece/XuDation-D18.html

6.  Theodor H. Nelson, "Transliterature: A Humanist Format for Re-Usable Documents and Media."  At http://transliterature.org/

7.  Transcopyright home page, at http://transcopyright.org/

8.  Theodor H. Nelson, "The Generalization of Media."  Forthcoming; draft at http://xanadu.com/XanaduSpace/xuGzn.htm

9.  Theodor H. Nelson, "A Cosmology for a Different Computer Universe: Data Model, Mechanisms, Virtual Machine and Visualization Infrastructure".  Peer-reviewed paper at http://jodi.tamu.edu/Articles/v05/i01/Nelson/

10.  Steven Carmody, Walter Gross, Theodor H. Nelson, David Rice, and Andries van Dam. "A Hypertext Editing System for the /360" in Faiman and Nievergelt (eds.) Pertinent Concepts in Computer Graphics: Proceedings of the Second University of Illinois Conference on Computer Graphics, pp. 291-330, University of Illinois Press, 1969.

11.  Douglas C. Engelbart, "A Conceptual Framework for the Augmentation of Man's Intellect." In P.D. Howerton and
 D.C. Weeks (eds.) Vistas in Information Handling, Spartan Books, 1963.

12. Douglas C. Engelbart and William K. English, "A Research Center for Augmenting Human Intellect."  In AFIPS Conference Proceedings of the 1968 Fall Joint Computer Conference.