The early years of hypertext research saw a profusion of strange new hypertext models, formalisms, and systems. The exuberant abundance of this era was overwhelmed by the emergence of the Web and, later, the field's fascination with social media. Elegies to the freedom of the classical era of hypertext continue to be heard, yet novel systems are rare. This paper proposes a simple architectural twist that embeds web components — which may include hypertext systems — inside a classical hypertext framework. The goal of this work is to enable researchers to implement useful, testable prototype systems very quickly: an exotic hypertext system in an afternoon.

CCS Concepts: • Human-centered computing → Hypertext / hypermedia ;

Classical hypertext , Tinderbox , DASH.

ACM Reference Format: Mark Bernstein. 2024. A Novel Architecture for Classical Hypertext. In 35th ACM Conference on Hypertext and Social Media (HT '24), September 10--13, 2024, Poznan, Poland. ACM, New York, NY, USA 7 Pages. https://doi.org/10.1145/3648188.3675147

Anderson and Millard's review of “Seven Hypertexts” begins by reflecting on the ACM Hypertext Conference's habit of existential doubt [3]. “Perhaps it was the advent of the World Wide Web,” they speculate, “that cast a long shadow across the wider field of Hypertext and caused such soul-searching.” Indeed, both research literature and informal discussions have been suffused with a sense that the Web prematurely foreclosed interesting and important formulations of writing with links [42, 44].

Even a superficial review of early research reveals intriguing ideas that have not been pursued because they do not readily correspond to the design of the World Wide Web [11]. Trellis explored multiwindow browsing of multimedia objects with automated reasoning about their synchronization [60]; we have more video today, but nothing like that. Indeed, much work in Web multimedia today seems dedicated to commencing and sustaining video performances that viewers do not want [20]. Scripted Documents [70] proposed user-authored, external webs (cf. Intermedia [68]), a concept reified not only by the research community [30] but also in a feral hypertexts [66] through OPML feeds and news readers. We once had hypertexts without links [65], hypertexts with multi-headed and multi-tailed links [46], hypertexts with generic links [28], and catalogs of ways to store [25] and to follow links [67].

Yet research on novel hypertext models and systems virtually disappeared from the ACM Hypertext Conference. This work was replaced by studies of social media that appeared for a time to be more directly relevant to vernacular use of the Web. Still, classical hypertext had been built on important and consequential ideas and debates about structuralism, existentialism, the perfectibility of the mind, and the nature of communication and community [18, 19]. Our studies of social media sometimes cataloged the behavior of bots and mechanical turks [5] while furthering the ambitions of villains and facilitating the surveillance of political dissidents and of women who might seek an abortion [21]. Some important knowledge was gained in the process [7], but ideas were subordinated to the profits of platform owners.

Many of the questions that classical systems sought to explore remain open. We do not know how best to write a hypertextual textbook [39] or how to assess a student's hypertext assignment [41]. We know some empirically-observed patterns found in calligraphic [12] and spatial hypertexts [16], but we don't know how to use patterns constructively or how to discover those patterns algorithmically. We know little about linking in video [58], less about linking in audio [6, 17], and still less about hypertextuality in music. Our understanding of hypertextuality in programming languages has not advanced much beyond Knuth's statement of the issue [38].

How might we find time to attack these old, familiar problems without also attacking the World Wide Web?

Creating the hypertext systems of the classical era demanded substantial resources1. NLS/Augment, a major initiative of the Stanford Research Institute, ran to 100,000 lines [9] and employed more than 25 people including 11 programmers [8, 26]. Brown University's IRIS, the home of Intermedia, employed about twenty researchers. NoteCards had three lead programmers and an additional five contributors — all staff members at what was then the world's leading computer science lab [45]. Chandler, a hypertext-inflected email and calendar system backed by Lotus founder Mitch Kapor, failed despite a team of twenty-four programmers, several of them legends [56]. Resources on this scale were not easy to acquire or retain, making the early systems vulnerable to changing priorities or managerial whim. Smaller projects had to manage with whatever time their initiator could spare, or whatever volunteers the initiator could recruit [49]; the importance of personal charisma to early hypertext research should not be overlooked.

The need for prodigious resources derived in turn from the primitive state of contemporary computers, the rudimentary condition of software development, and from the wartime heritage of computing. The Xerox Alto — a high-end workstation — had a memory capacity of 512K and a 5.9MHz clock speed. An Apple Watch today has 100,000 times as much memory, and a $15 Arduino Nano has more processing power. No one used version control: Subversion 1.0 debuted in 2004. Software patterns, refactoring, and test-driven development were still a decade away, and integrated development environments were a new and controversial concept. Almost no one used package managers, and the dream of software reuse remained elusive [31]. The scarcity of access to computers (and their Cold War heritage) made humanistic applications of computing seem frivolous [32]] even though the origins of the theory of computing had been firmly rooted in the humanities [19].

Because the stakes were high, researchers often identified with their systems. You had to make design choices with care because you might not get a second chance. At the same time, it was often difficult to assess the utility of an innovative research system because the investment required to reach an acceptable level of functionality was so great. Intermedia commissioned its own costly text engine, while NoteCards piggybacked on InterLisp-D's ground-breaking visual editor. Systems built with pointer-based languages and manual memory management tended to crash; those built in LISP and Smalltalk incurred arbitrary delays for garbage collection. Arbitrary limitations were common: early Storyspace, for example, limited note titles to 32 characters, the text of writing spaces could not exceed 32K characters, and maps and outlines could not exceed 16,383 pixels in height or width [14]. Students brought books to the computer lab if they planned to use Intermedia in order to pass the time required to traverse a link [59]. If you wanted an Undo facility or a back-button, you would have to implement them from scratch. As a result, usability studies of these systems often foundered on the shoals of adventure, and persuading even developers to use system they were building could prove infeasible [56].

Today, hardly anyone can find time or resources to build a new classical hypertext system. How might we build a system as a research prototype — unfinished, unpolished — with the time and resources we can muster? Could we build a new exotic hypertext system [13] in a week? An afternoon?

Most post-classical hypertext systems have run in the web browser2. With some notable exceptions [34, 35], these systems are not intended for research, and post-classical systems are not always well represented in the research literature (though see [57] and [43]). Many post-classical systems seek to provide constructive hypertext services for a specialized task: Anki for spaced-repetition memorization, the original Wiki for debating software patterns, MediaWiki for crowd-sourcing online encyclopedias, ZigZag for viewing multidimensional structuralist dualities [4], DBpedia for browsing RDF triples.

Post-classical systems could run on a variety of machines and required little or no installation. Yet, because they run on abstract machines and in constrained sandboxes, the performance of post-classical systems can fall short. Modern computers of all sizes, including phones, have multiple cores with inhomogeneous capacities, graphic processors, and hardware specialized for machine learning; these facilities are seldom available to post-classical systems. Specialized APIs that provide access to address books, contact lists, linguistic analysis, and entity recognition are fenced off from web applications to prevent villains from covertly stealing personal data [21], but of course these resources are invaluable to hypertextual tools for thought. The phrase “Savannah Swing” might denote a person, a playlist, or a dance; access to our contact list and our music library could help a personal assistant disambiguate them [24] but no one wants to expose their taste in music or their address book to web villains. Even access to disk files is sharply constrained for post-classical systems.

Great things have been accomplished by post-classical systems, both in research [35] and in making hypertext tools available to an audience unwilling or unable to spend even modest sums [57]. Indeed, some classical systems such as NoteCards (and the entire InterLISP environment3) and Smalltalk [37] have been crafted inside the browser. More could be done. It might be interesting, for example, to reimplement Trellis, which represented hypertexts as a Petri net, in an environment with sufficient computational resources and abundant media assets [60]. Chandler was never finished [56]; if we built it now, might we learn something? If we put a modern interface on NLS, what might we find out?

Rather than implement a classical hypertext system inside a Web browser, we might instead place individual Web browser panes into a classical hypertext system, putting them atop the visual representation of each hypertext node. In Figure 1, we see a Tinderbox map [15] with two notes; the second note happens to hold a live instance of NoteCards.

A screengrab of the Tinderbox application, in Map view, showing 2 notes. The right-hand note has image content and is in fact hosting a live instance of the NoteCards app emulated in a web page.

Figure 1: A Tinderbox map view with two notes. The larger note on the right has a poster running an instance of NoteCards.

4.1 Tinderbox

4.2 Tinderbox Posters

Any note may ask to have a poster, a WebKit-based view that appears above the poster note's customary representation. This view, in turn, may receive its data in two ways: by fetching it from the source designated by the attribute PosterURL, or by generating it internally by applying the template designated by PosterTemplate to the note itself. The latter is what chiefly concerns us here, as it allows a poster note to collect and visualize data from other notes. For example, in Figure 2 a poster note marshals data from a container that is linked to it and presents it as a histogram. The demonstration of this affordance of DASH at Hypertext 2019 is the inspiration for the present work [64, 69].

Figure 2

A screengrab of the Tinderbox application, in Map view, showing 4 notes. The left-hand note is a poster note shows a graph rendered using the Plotly JavaScript library and using data drawn from notes in the container shown the right of the screen.

Figure 2: A rule in the Poster note locates a container linked to that note whose name contains “data”, retrieves data from the contents and passes it to the Plotly4 library. Plotly draws a histogram in the requested style on the poster's canvas. Since rules run frequently, changes to the data are immediately reflected in the displayed visualization.

If the notes from which the poster receives data happen to change, the poster will redraw itself to reflect the update. This facility lends itself to ad hoc dashboards for keeping track of complex tasks. I might want to know, for example, how much progress I'm making on a book. In the early stages, the rate at which I'm making new notes is a plausible proxy for velocity, my rate of progress [10]. Word count of notes in the current draft of the book may be a better metric late in the game, though that may swing from a target I hope to meet to a barrier I somehow must find cuts to reach (Figure 3).

Figure 3

A screengrab of the Tinderbox application, in Map view, showing two different poster notes and their source data notes.

Figure 3: Poster notes lend themselves well to ad hoc dashboards.

Though many posters accept slowly changing data (such as the text of a work in progress) and present occasionally changing visualizations, posters may be more active. We may, for example, make a poster note what takes text from the Tinderbox note, runs it in a language we want to learn such as Turtle Geometry [1, 55] or Processing [53], and then animate the result (Figure 4).

Figure 4

A screengrab of the Tinderbox application, in Map view, showing a poster note displaying an animated tree graph rendered using Processing.js.

Figure 4: A note that takes a program for an animation in Processing and displays the animation in its poster.

Note that the poster architecture need not create a dependency on any specific package. Figures 2 and 3 happen to use plotly, but they could just as easily use another charting library. Figure 4 uses Processing, but we might use R [62] instead. Switching libraries typically requires modest changes to data formatting. Efficient JavaScript [23] engines have given rise to myriad libraries which accept data in the form of a JSON payload and either return an HTML object ready to insert into the DOM or write into a designated canvas present in the document. In effect, the Web, in making this functional mapping f(data) ⇒ [rectangle in page layout] or f(data,DOM) ⇒ [revised DOM], has been the occasion of the first real success of software reusability.

Finally, the poster may ask its note to perform a Tinderbox action by posting the action to the TinderboxAction object, or it may request information from Tinderbox by setting a Tinderbox attribute to a JSON string. In this way, Tinderbox controls the poster but allows the poster to control Tinderbox, forming an intriguing knot. A poster about the invention of the compound bow might, when selected, rearrange the map view that contains it to bring alongside other notes about the queer ways in which people resist innovation [30, 63].

Though notes using PosterTemplate are more interesting, we might briefly observe that posters loading their contents from a PosterURL are not without interest. We might use such posters, for example, to bring together student assignments in an advanced Web Design seminar or, indeed, in any course where the work product is hypertextual (cf. The Victorian Web [40] or hypertext-based art education [61]). To support the small compass of the poster, users can inject additional CSS rules to reduce font sizes or to eliminate extraneous elements. The poster may then be surrounded by commentary, pointing out design apparent errors and exploring alternatives. Posters lend themselves to an ad hoc, localized style of adaptive hypertext; for example, style objects for each poster may refer to a configuration object that reflects user preference or competence.

4.3 Posters As Open Hypertext

Posters are not tied very tightly to Tinderbox. They were not difficult to implement, and most of the work took a week. The uniformity of the Tinderbox data model, in which every attribute is defined for every note, is helpful here. A more formally-inclined system like Aquanet [46] or a duck-typed system like Chandler [56] might pose additional challenges when the poster controls the host. Some actions in these systems can only be applied to certain notes, and determining whether a given note is eligible or not might require additional work.

Browser views were designed in the expectation that one or two windows might be displayed at any time, but a map view in Tinderbox or related tools may hold hundreds of notes. This can cause some difficulties; even idle or hidden web views may create worker threads and allocate buffers to prepare for their eventual activation. Tinderbox obviates this by instantiating posters on demand, and by removing posters after their notes scroll offscreen.

The communication channel between host and poster may not be efficient. To pass data to a poster, the host may need to assemble HTML, CSS, JavaScript and JSON which the poster immediately breaks down to component structures. On the way back to the host, results are typically compiled into an XML or JSON payload from which Tinderbox extracts pertinent nuggets of information. This seems quite a lot of work, though we have not yet experienced actual performance issues.

The mutual permeability of host and poster present potential security issues, especially where the host is a research prototype. It is not apparent that these issues are in any way greater than those incurred in normal use of the host. Some web sites, however, are conspicuous targets for attack, while a novel research system is unlikely to attract the attention of nefarious or villainous attackers.

While preservation of hypertexts is, of course, eminently desirable, we may have lost sight of many of the concerns of early hypertext systems, questions which were not fully resolved in the classical era and which the Web seemed to have foreclosed. Late classical systems, for example, were often deeply concerned with richer, more elaborate, and more expressive links [28, 47, 51]. After the Web, we knew that a link was (and would always be) whatever Microsoft Explorer® said it was. Or so it seemed. A neoclassical system might let us quickly prototype novel links — say, links with multiple destinations — while otherwise retaining the facilities of the Web and the facilities of the classical host.

In some of the examples above (Figures 2 and 3), a poster receives its data by examining its inbound links, selecting a linked note that has the characteristics expected for a data source, and then fetching data either from that note or by iterating through its children. While pumping data through the hypertext link network is far from unprecedented, it is uncommon, and has tangential interest to the first of Halasz's seven issues: query in a hypertextual network [33].

A notable facet of the neoclassical architecture is that poster notes are literally blank slates that invite inscription, and yet at the same time offer a powerful computing environment that will be familiar to most students of computing and to many end users. One of the most impressive demonstrations of DASH was the final meeting of a course at Brown University, taught by Norm Meyrowitz and Andy van Dam: “Hypertext/Hypermedia: The Web Was Not the Beginning and the Web Is Not the End.” Undergraduate students in this course, working in small teams, extended DASH to support new note types such as timeline views. I've been building hypertext systems for a long time and I work to keep my codebase clean and simple, but adding a new note type to Tinderbox, with its 200,000 lines of C++, ObjC and Swift, might not be a reasonable term project. Building and demonstrating a novel poster note, on the other hand, should be entirely manageable.

From the earliest days of hypertext research, we have discussed scholarly notebooks and workbenches [22, 27, 29]. Notebooks have always been tricky engineering artifacts [36]. For example, a key aspect in the popularization of paper notebooks in 13th-century Italy was the observable fact that writing in ink on paper was indelible, whereas writing on the older medium, parchment, was not. This made pocket ledgers a credible and — soon — an indispensable resource for doing business [2]. At the same time, paper was sufficiently flexible to allow diagrams and artists’ sketches as well as text. Providing this combination of permanence and representational flexibility has been a challenge to crafting notebook systems; the neoclassical architecture may not make this easy, but it might make it possible.

This proposal does not impact good ideas like link servers [47, 52] or structure servers [50]. Discussions of architecture often lead to architectural astronautics, the tendency to abstract out the detail that makes a problem notable while leaving behind a plethora of boxes and arrows. Yet many questions from the classical era remain open, and some questions that seem to have been closed may have been decided prematurely. Hypertext once had big ideas, and smaller, more easily built (and discarded) systems might let us return to them.

Marc Nanard, Jocelyn Nanard, and Randy Trigg were the interlocutors whose advice at Hypertext ’96 led me to discard my own inferior design; their approach made this work possible

1That this account of the economics of classical hypertext systems is anecdotal is regrettable but inevitable. The finances of early hypertext development were inextricably bound up with those of their host organizations, not to mention government and foundation grants whose ultimate sources were, in some instances, state secrets [32]. There is, moreover, no uniform method to account for the contributions of unique individual talents. How does your general ledger account for the presence of Richard M. Stallman or Bill Atkinson?

2An important exception of particular interest to the neoclassical hypertext endeavor was the effort to construct component-based open hypertext systems (OHS) [54]. Early hypertext systems had built their own viewers and editors for text, images, and videos. This was expensive and distracting; OHS promised to augment whatever editor the user preferred to use with a hypermedia-enabling wrapper which would, in turn, communicate with middleware servers in which the semantics of links (including collaborative links among user sessions) would be managed. OHS was deeply interested in a principled separation of concerns embodied in the middleware layer: a spatial server, a navigation server, and a collaboration server might all be expected to engage the same client, perhaps at the same time. This also provided a practical separation of concerns into chunks commensurable with the size of a doctoral dissertation.

3 https://notecards.online/main.

4Plotly Technologies Inc. Collaborative data science. Montréal, QC, 2015. https://plot.ly.

5This design decision is, perhaps, not completely unprincipled. Tinderbox's prototype inheritance is used heavily in Tinderbox and therefore must be fast. A complex map view might require tens of thousands of attribute references, and composing an HTML export can require millions. That's a lot of backend queries.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

HT '24, September 10–13, 2024, Poznan, Poland

© 2024 Copyright held by the owner/author(s). Publication rights licensed to ACM.

ACM ISBN 979-8-4007-0595-3/24/09.

DOI: https://doi.org/10.1145/3648188.3675147