1. UNEXPECTED LINKING
We often assume that node-and-link hypertexts are well understood and that opportunities for innovation and research primarily lie in new and less explored areas such as spatial and sculptural hypertext. Indeed, the Web has made links ubiquitous and invisible, and it takes a conscious effort to recapture the excitement and surprise that simple link following once promised for everyday work and learning. Yet fairly straightforward and conventional extensions to familiar hypertext links remain incompletely understood, and a small change in implementation and context can create opportunities for unexpected forms of hypertextual relations that seem quite as unfamiliar as systems intentionally designed for their novelty .
Though spatial hypertext is newer and, at this time, less popular, most writers appear satisfied with the early descriptions of its rhetoric and patterns of connection.
In these preliminary notes, I point out several unexpected hypertextual relationships that appear in Tinderbox, a spatial hypertext system. These patterns of links occur in facilities that are far from unprecedented among hypertext systems, but the structures to which they give rise have not been widely discussed, nor do hypertext tools (including Tinderbox) appear to succeed very well in making these structures apparent or in encouraging their discovery, refinement, or formalization.
2. LINKS FOR A SPECIFIC CONTEXT: EXPORT AND INTERCHANGE
Import and export, the glue that connects disparate applications, are customarily regarded as secondary features, useful when adopting new products or when wishing to sell new systems. Import and export necessarily take place outside the application's data model, and so they seem extrinsic to the application's vision. This distinction is nowhere clearer than importing texts into a hypertext, or in exporting a hypertext to linear text.
Hypertext research has long been concerned with hypertext standards and interchange formats. Though we may embrace new writing and visualization tools and new media, we often desire interchange with other hypertext systems and with conventional word processors and Web browsers. Interchange would be simplified if all systems adopted standard representations and formats, but the desire for standardization has always been tempered by concerns that the standard would exclude necessary capabilities or that premature standardization would foreclose promising areas of research.
In the early era of hypertext research, demand for interchange was driven by desire to move hypertexts between separate monolithic systems. Interchange was often desired to facilitate comparison of competing features, and too often interchange was urgently required to ensure survival of hypertexts should their original platform be abandoned. (The threat of extinction may have been less urgent than it seemed. Intermedia was largely salvaged through migration to Storyspace and then to the Web. The loss of NLS/Augment, which ran on PDP-10 computers, is often cited as the definitive caution. At WikiSym 2006, Engelbart described a revival of NLS/Augment and its documents. David Durand (personal communication) has similarly revived FRESS documents through a PDP-11 emulator.) In later years, the desire for interchange formats and interoperable protocols was driven by a desire to leverage commercial word processors, spreadsheets, and graphics editors; the hypertext system was seen as providing link  or structure  services to client applications while allowing users to work predominantly with familiar tools. This "open hypertext:" effort was allied in many respects to the failed drive toward component architectures through CORBA and competing technologies. (Interestingly, an ad hoc consortium of software developers has recently implemented and deployed a simple link service, though it is not clear that the developers are familiar previous work in the area ).
Early calls to standardize hypertext interchange formats failed because even the earliest hypertext systems offered a formidable array of data models and behaviors. Whitehead's Engelbart-winning study of data models  captures the diversity of structure, and the situation with respect to linking schemes and behaviors presented still greater challenges to any effort toward standardization. Rather than declare a standard, researchers created the Dexter model, a vocabulary for describing hypertext systems. Other efforts sought to define a vocabulary of structures found in hypertexts themselves.
The unexpected and overwhelming triumph of the World Wide Web seemed for a time to have established a nearly-universal hypertext standard. For some years, hypertext research tended to define itself as redressing the shortcomings of the Web. Instead of lobbying for a standard, hypertext research found itself fighting a rear-guard action against an apparently-entrenched standard that was, in some ways, more primitive than the models discussed five or ten years before.
What was not recognized at the time, however, is that the Web is not a hypertext standard at all. What we know informally as "the Web" is, in practice, a collage of three distinct kinds of technology:
- A standard for naming resources (the URI) and for resolving unique names is a global address space (DNS),
- A transport protocol that offers a convenient and economical way to move data streams across the Internet (http).
Of these three separate components of "the Web", only the third component deals meaningfully with hypertext, and only the third component has resisted standardization. This complex of interdependent languages is growing, not shrinking, in diversity.
Consider, for example, how we might currently approach a straightforward and uncomplicated hypertext conversion task, such as moving Landow's Victorian Web from Storyspace to the Web. In principle, we know we shall want to create some new files, some of which are bound contain a dialect of HTML. In practice, though, we might easily choose a host of implementation routes. We might:
- Export a collection of static HTML files, perhaps with a set of CSS style sheets to control their appearance, ( http://www.victorianweb.org/ ) OR
- Export a collection of XML fragments that are assembled on request into HTML pages by a content management system ( http://www.tbray.org/ongoing/ ), OR
- Export one or more XML files that are parsed and served by a Flash shell ( http://nike.com) , OR
- Post data to a wiki OR
- Use XML-RPC or ATOM to post data to a remote content management system, which will own, assemble, maintain and serve the page ( http://www.blogger.com ), OR
- Export a collection of HTML fragments that will be embedded in AJAX pages, perhaps themselves assembled by a framework application such as Ruby on Rails ( http://www.basecamphq.com)
All of these approaches are in widespread use today, and all are casually regarded as equally "the Web". Other techniques can be identified as well, and additional schemes will doubtless emerge.
Because the Web is ubiquitous, almost any hypertext tool is bound to want to share data with it. But the nature of this sharing cannot be defined in advance; different applications and different users will means very different things by :"the Web". All use URI's and almost all will use http, but the language and representation of the exported hypertext are likely to vary wildly among users, and indeed from year to year.
3. TINDERBOX EXPORT TEMPLATES
Tinderbox is a hypertext writing environment for making, analyzing, and sharing notes. Tinderbox is heavily influenced by Storyspace , VIKI/VKB  , and ART , while borrowing ambitions for knowledge representation and structure discovery from Aquanet  and Agenda . Because Tinderbox is primarily a tool for writing and analysis, interchange and export are not central concerns. Nevertheless, it is clearly desirable to make it easy to move information from Tinderbox to other tools the researcher may require.
A Tinderbox note is implemented as an attribute-value list. Some attributes possess inherent semantics; for example, the value of Name is displayed as the note's title. Users are free to add new attributes.
Each note may specify a value of the attribute HTMLExportTemplate to identify a file that defines how that note should be exported. During export, the template file is copied to the output, and placeholders in the template are replaced by corresponding data from the note. For example, the template
^title ^text ^linkTo(home page) | ^linkTo(next)
exports the title of the note, followed by the note's text, and then by links to the note named "home page" and to the "next" page in the document's outline sequence.
Each Tinderbox note has an attribute to hold some text, and links may be embedded in the text of a note. As in Storyspace, additional generic links may be associated with an entire note. These explicit links are easily converted to their HTML counterparts. Implicit connections —mdash; the placement of several related notes in a spatial cluster, or coloring notes distinctly to indicate that they share some commonality —mdash; are typically not expressed in the exported HTML.
In addition, export template can be linked to other export templates, in distinct patterns of .connection. The markup elements permit export templates themselves to engage in a separate form of hypertextuality. The element.
applies an export template to any note and copies the result to the export stream.
applies an export template to each immediate child of the note, copying the results in turn to the export stream. Additionally, a specific aspect of any note may be retrieved and exported thus:
In all these cases, notes may be referenced by name, relative or absolute path, or through a set of keywords such as "parent" and "next".
generation, since they were popularized in the C language preprocessor. The hypertextual potential of the preprocessor was discussed implicitly as Literate Programming  and was treated explicitly by Friendly's JavaDoc . Template-based formatting is increasingly common in content management systems and wikis . It is interesting to observe, though, that formally this hypertextuality and transclusion of export templates amounts to a layer of contingent links — links that are manifest for a specific purpose (here export) and that are otherwise invisible.
3.1 Export Templates as Projection Functions
An export template may be considered a function E which, when applied to note n will generate the exported text string T:
For example, the export template TitleTemplate
can be applied to the root of any hypertext and generates a flattened view of the hypertext as a list of note titles. A different template SummaryTemplate
<h2>^title</h2> ^text(25)... ^if(^get(Image)) <img src=^get(Image^> ^endif ^justChildren(SummaryTemplate)
exports the title, 25-word summaries, and an optional image, These two views can be regarded as different projections of the hypertext, linearized shadows projected on the cave (or cubicle) wall.
Figure 1. The same object may be projected by different templates to form distinct representations or summaries.Markup elements may also be embedded in the text of a note, allowing function composition. For example, notes that represent that start of a chapter might begin with a table of contents:
^title^ ^justChildren(TableOfContentsTemplate) ^justChildren
Each chapter is exported twice: first, the chapters appear in summary form using a fixed template for the table of contents, and then each is exported through its normal template.
Figure 2. The same hypertext viewed in one projection yields a table of contents, while a different projection yields a text. The viewed page might be contain both projections
3.2 Export and Coastal Trade: Ad Hoc Views
Though we usually think about export in terms of data interchange, Tinderbox users often use HTML export as a form of report generator. The browser window is simply a flexible place in which to display a custom view of the user's data. Neither interchange nor sharing are intended, and the user is choosing to "export" information only to study it, reflect upon it, or perhaps to find opportunities to improve it.
ART's folding mechanism  does precisely this within the frame of the hypertext environment, allowing writers to take a linear text and fold it hypertextually in order to experiment with different organizational choices. In practice, the distinction between export and view management is a continuum: we can, for example, use an export-view-revise cycle to create an ad hoc view defined in HTML.
Our experience suggests that the utility of Yamamoto and Nakakoji's "representational talkback" - the ability of the view to suggest useful changes - depends on presenting an effective enactment of changes in the document  . ART can do this well because the visualization takes place within the environment. Tinderbox is less effective because the manipulation takes place in one kind of Tinderbox window and the linearization appears in another window. Though the windows all update as the document is changed, it is easy to overlook changes that take place in other windows and difficult for the program to direct the user's attention the enactment taking place elsewhere on the screen.
The impact of changes in the document's organization are clearest when they can be shown unambiguously as they are made. This is comparatively easy when working in some hypertextual modes, such as stretchtext. Tinderbox's naïve implementation likely provides too little context for users to recognize an enactment. When editing long linear documents, the impact of a moving a long passage may effect the text that precedes and follows its old position as well as the text before and after its new position; if the text being moved occupies a few pages, we need to enact (and understand) changes occurring on four separate pages of the document. As such a complex enactment is likely to prove confusing, the primitive "export-and-view" scheme might prove competitive with a more refined view architecture.
In Nakakoji's original implementation, structural editing and continual text are contained in the same frame, helping to establish the connection between changes. Zellweger's experience with stretchtext suggests that more detailed enactments would greatly help users to maintain a sense of causal connection between the editing change and its impact on the document .
Figure 3 - A Web page exported from Tinderbox (here http://MarkBernstein.org) is often assembled by combinging information from many individual notes.
Today, my own weblog (Figure 3) contains 20 recent notes in the main (right-hand) column. But some readers don't want to read my weblog at all; they are searching for information about someone named Mark Bernstein and want to confirm that this is the Mark Bernstein they have in mind and then to find the information they were looking for. The left-hand sidebar assembles background information that these readers might be seeking, and that also helps them determine whether the "Mark Bernstein" on this page is the person for whom they are looking and not some other individual entirely. The sidebar lists some recent projects and publications, a calendar of conferences I'm planning to attend in the coming months, contact information, and so forth. This sidebar is assembled from approximately 200 notes.
Building the page from so many individual notes allows each note to be small and specific. For example, information about this paper's presentation is contained in a note about the IVICA conference instead of being embedded in a longer but frequently-changing calendar. Short, specific notes are easier to find and to reuse. Export templates can project different facets of a note in different contexts: a text summary for a human-readable Web page, an iCal resource for dragging into a calendar, an RSS element for syndication services.
The implicit hypertextuality created by juxtaposition of elements in compound Web pages is itself interesting and merits more careful study. This juxtaposition might sometimes be fortuitous but is more commonly planned with some care. What is particularly striking here is the way in which one hypertext, the Tinderbox document, is refracted through a second hypertext (the implicit network of export templates) and through the stylesheets (which may also be assembled from the same Tinderbox file through the same export process) to create a third hypertext (the collage of the Web page). The hypertextual relations in that third page are implicitly generated by the other hypertexts, but the layout of complex pages is so difficult to anticipate that users are likely to be surprised by the actual outcome.
The introduction of the declarative CSS style language has failed to ameliorate this state of affairs, as the constraints CSS can readily impose (e.g. width: 25em) do not always match for the rhetorical constraints we might desire (e.g. "avoid having a sentence begin in the left sidebar which appears inadvertently to continue in the right column" or "try to put this note next to that one, but only if it doesn't break the layout").
3.4 Prototype Inheritance
Export templates are expressive, but they would likely prove cumbersome if each note required its own template. Storyspace  uses a single export template throughout the document; when different notes require distinct export procedures, the template behavior may be varied through conditional logic. While this has the advantage of concentrating all export behavior in a single template, the template can easily grow complex.
Tinderbox distributes this complexity by allowing notes to specify their own export template. A note, moreover, may be linked to exactly one prototype note; if an attribute - including the HTMLExportTemplate - is not specified for the note, the value is inherited from the prototype. .
Prototypes may have prototypes. If inheritance fails to find any value, a default value is defined for each attribute. Thus, by choosing an appropriate default prototype and by using prototypes extensively, many notes can share templates easily while still allowing room for variation and change.
Will people choose to use prototypes? The experience of NoteCards and Aquanet   suggested that users - even computer scientists -- would be reluctant to take time to choose a prototype. Few (if any) previous commercial products have exposed inheritance to users outside the context of software development.
In practice, however, Tinderbox users often view prototypes as a shortcut rather than a burden. Prototypes save typing. Several implementation details try to reinforce the sense that prototypes are a convenience rather than a chore:
- Because the prototype can be changed at any time without information loss, Tinderbox users are free to choose whatever prototype appears most convenient at the time, without fear of premature commitment.
- Because prototypes need not be defined in advance - any note may serve as a prototype - prototypes encourage hurried users to build new notes from existing notes, defining their small difference rather than starting from scratch.
- Because people frequently need to make several notes of a similar nature, Tinderbox offers the most recently-used prototype as a plausible default.
Tinderbox prototypes are implemented as links; a link of type prototype connects the prototype note to each of its instances. The instances, in turn, have ready and efficient access to their prototype. (Tinderbox links are directional but are stored inside the Tinderbox file as external links [H.C. Davis. Referential Integrity of Links in Open Hypermedia Systems, in The Proceedings of the Ninth ACM Conference on Hypertext and Hypermedia, Hypertext 98. 1998. Pittsburgh, PA: ACM. pp. 207-216.] to ensure computationally efficient discovery of backlinks) Representing the prototype-instance relationship through links makes the prototype relationship's hypertextuality explicit and visible. We expected that this implementation detail would help users understand prototypes and to anticipate aspects of their behavior. In practice, however, most users choose to make prototype links invisible in order to draw more attention to other kinds of links.
3.5 Prototypes and Context
Documents can propose a prototype from the new note's context. A container of Summer Reading might automatically set the prototype of notes created inside it to Book. This reinforces the implicit semantics of spatial hypertext: notes created here are books, while notes created there are ideas I want to discuss,
A container named English432 might set the prototype of notes added to it to Students during registration, when the instructor is frequently adding students; later, the instructor might let the container set the prototype to Assignment. Since the container action is applied only when a note is added to a container, it represents an initial suggestion for choosing the prototype
Though the underlying mechanism is consistent, different Tinderbox objects, when setting prototypes, convey subtly different meanings.
|note is created inside or added to container
|note is created on or moved onto adomment
|Agents (persistent search)
|note matches the agent search criteria
|Discovery and assignment
|executed periodically and always enforced
Rules are constraints, constantly enforced. Container and adornment actions, which run only when the note is created in or moved into a container, are assumptions that users can override: things in Summer Reading are assumed to be books, but users might choose a different prototype for journal articles or electronic books. Adornment actions are often used as instrumental tools; an adornment serves as a sort of factory object that stamps any note dragged onto it with a set of properties. Agents represent a conditional constraint, imposing the constraint only on those notes which meet a specified criterion; often, agents search for especially interesting cases and assign them to special classes.
The presence of contextual assignment gives rise to interesting forms of hypertextuality, where creating a structural connection (e.g. adding a note to a collection) creates a new prototype dependence (and a new prototype link).
3.6 Configuration Notes and Transclusion
We have already observed that export templates may transclude other notes, projected through other templates
and that templates may transclude specific attributes of other notes
The same elements can be embedded in the text of a note, allowing texts to transclude information from another note.
Tinderbox: $ ^getFor(/config/price,Text)
Nelson originally proposed transclusion to promote the longterm integrity and citeability of volatile hypertexts, but here it is used to preserve locality of reference. By keeping data (here, product prices) in one place, we may more readily ensure consistency among many notes.
Tinderbox also offers a simple service to update a note's text from the contents of a known URL. This enables us to transclude information from outside the document (e.g. from a pricelist exported by a different Tinderbox document), from external applications, or from services outside our control (e.g. the most recent version of our homework assignment).
None of these hypertext mechanisms are especially novel, though the implicit hypertextuality to which they give rise has not been much discussed. The deployment of these facilities in an inexpensive product, one that is typically used by people without interest in hypertext research or practice, does remind us of the extent of these hypertextual relationships and brings to the fore a number of issues regarding our understanding and representation of implicit hypertextuality.
4.1 Actor languages and the locality of logic
The combination of spatial hypertext with hierarchical outlining has proven a fertile mix, and the availability of prototype inheritance —especially when combined good defaults and tools for choosing prototypes — has led to very widespread use of prototypes, even among non-technical users. Though Tinderbox is a personal tool intended for personal and ephemeral notes, some Tinderbox documents exceed 10,000 notes. Others have several million words of text. Some include dozens of prototypes in an elaborate (if ad hoc) class structure.
Rules, agent actions, adornment actions, and container actions might all potentially act upon any given note. Because we can easily distribute constraints among these potentially-active objects, users are free to prefer simple rules. It is easy and efficient, for example, to create an agent that depends on another agents, and users often set up networks of collaborating, simple agents in preference to a single agent with a complex, conditional action.
The proliferation of active objects, however, makes debugging more difficult. The user sees that Virgil is red and knows it should be green. She changes the color to green — and then something changes it again to red. It can prove difficult to learn what made the change, especially since any agent or rule might potentially have done so.
4.2 Error messages
An early design constraint required that the user should see an error message only in conventionally critical situations. An error message is acceptable if saving a file is impossible because the disk is full, but messages regarding syntax errors and the like are the mark of programming. Many people regard programming as the sole province of professionals; anyone might cook or play cricket, but only programmers write programs and receive error messages.
In addition to this sociological constraint, we were far from confident that error messages could be made intelligible and useful. Let us suppose, for example, that an agent discovers a syntax error in its action and wants to report that error to the user. Several obstacles confront us:
- The action is likely to be complex, since syntax errors are easier to make in complex actions.
- The error might only be discovered when the agent runs and encounters unusual data. Users quickly grasp simple query optimization; since Tinderbox short-circuits Boolean evaluation, an agent's query and action may not reveal the error until it is run against live data.
- The error might involve transcluded data or an expanded macro. The erroneous text the parser sees may bear little resemblance to the text that the user typed. This problem is familiar (compare error messages that involve C++ template methods in the Standard Template Library) but knotty, even for programmers.
- Agents and rules run asynchronously. Often, a user might be typing inside note A when an error is discovered by agent B as it attempts to act on note C. Neither B nor C are the subject of the user's attention; neither may be visible on the user's screen.
- The error perceived by a parser may not bear an obvious relationship to the writer's model of the program. The user says, "I typed an ‘l’ when I meant to type a semi-colon.” The compiler may say doesn’t perceive a missing semicolon; it sees an illegal declaration, or an unexpected parenthesis, or some other fault that will appear, to the user, absurdly irrelevant.
- Error messages are difficult to write, and the need for the error message (as opposed to silently correcting the error) often demands parsing and semantics for which users may have little patience.
Though it is undesirable to bombard users with obscure, asynchronous errors, the absence of error messages leaves even the expert user with few resources for discovering the source of unexpected behavior.
4.3 Refactoring as incremental formalization
Following VIKI and VKB, Tinderbox emphasizes the importance of incremental formalization, of moving information gradually from implicit to explicit representation. In particular, Tinderbox allows notes to define KeyAttributes which are displayed along with the note's text; when inherited from a prototype and shared among a class of notes, KeyAttributes create a set of prominent slots which can be used for formal or semiformal representation of the note's information.
Figure 4 - Key attributes invite users to gradually formalize information.
While our original focus emphasized incrementally moving information from the note's text into attributes, we find an increasing tendency to continue the process by moving from a specific note's attributes to another, more general location:
- To a note's parent, when a note represents a facet or aspect of the parent note;
- To a specific named note, such as a configuration note, to facilitate sharing of a common value among multiple notes;
- To a macro, which also facilitates sharing of a common value between multiple notes;
- To an outside server, which is synchronized with a specific named note in this document
It is interesting to note the close relationship between this incremental formalization and familiar transformations in software refactoring. The first transformation above corresponds to "Raise method" and second to "sprout method" .
Tinderbox's uniform data model encourages users to associate semantic information with small but useful visualization cues. Some visualizations are created by users, others are built into the program.
In outlines, for instance, each note is represented by a small rectangular outline. The main purpose for this icon is that it provides a selection target for notes with an empty name, a name that contains only white space, or a color that matches the background color. But, in addition, we can include useful information in the 128 pixels that make up the icon without adding graphic noise.
- One or more small horizontal lines in the document indicate the presence of text inside the note. The number of lines increases logarithmically with the length of the note.
- The border color of the icon reflects that note's designated color.
- The background color of a newly-created note is bluish white. The color "dries" gradually over the course of a day to a neutral white and then gradually yellows over the span of roughly a year. Modifying a note resets the color change.
Tinderbox also tries to distinguish between tentative spatial groupings (piles and clusters), which may be emphasized by adding an adornment to set off a region of the map view, from more formal collections in which a note is moved inside another note. To emphasize the distinction, moving a note into an adornment is continuous, while a note dropped into a contained changes scale and is no longer selectable outside its container. (This distinction is not popular with users, who frequently want to move more smoothly between adornment and containment and back. VIKI and VKB may have got it right.)
The constraints imposed by agents and rules are frequently used to tie the semantics of user-defined attributes to visual attributes of the note. For example, agents may scan for overdue tasks and set their Color to red, or their NameFont to a distinctively bold font. This popular task must currently leap a modal discontinuity: the user is connecting an attribute to a visual property, but the action is described as a textual expression:
Finally, we observe that we have good spatial hypertext tools for visualizing the relationships among notes, and yet these tools do not currently avail us for understanding or visualizing the transclusive and referential relationships among notes, or to anticipate and debug the projection from a family of notes onto their HTML or XML export. Indeed, we have no good visualization of the notes that will be involved in a given export transformation.
Many related problems will occur to the reader; for example, the literature does not seem to suggest an illuminating way to represent the transitive closure of links to or from a given note. Visualizing the behavior of dynamic links, such as the interplay between Storyspace guard field  and the reader's previous trajectory through the hypertext, urgently requires a more adequate solution. Indeed, the problem of debugging declarative programs, whether networks of interacting agents or cascades of CSS style rules, remains a challenge for computer scientists even as we are increasingly expecting casual users to undertake the same work.
Figure 5 - Our spatial hypertexts already contain tens of thousands of nodes. Above: working notes on patterns of game design by Prof. Julie Tolmie (Tinderbox Weekend Paris, 2005)
Finally, we need to consider the impact of scale on our visualizations and interfaces. We now possess spatial hypertexts with tens of thousands of nodes, millions of words, and which preserve history information accumulated over many years. Little work has been done on visualizing the explicit structure of these networks. Just as urgently, the implicit hypertextual structures set up through export templates, transclusive links, and inheritance relationships would undoubtedly be better understood if only they could be adequately represented in our interfaces.