In his PhD dissertation, Cybertext, game studies scholar Espen Årseth argues that the linearity and interactivity of a literary work have little to do with whether it was realized in print or on a computer. His most conspicuous example is the millennia-old I Ching, which is both non-linear and interactive. Årseth also showed how hypertext could be more linear than a regular paper book: it’s possible to skip around in a book, but in hypertext, we can only follow the links that the author has set out for us. As I became more comfortable with what was initially a challenging concept, I began to think about what it is, then, that makes hypertext interesting.

What hypertext is good at

Let’s imagine a story, idea or argument as a concept map, where the bubbles are concepts and the lines between them are some form of analogy. We can call this a representation of a conceptual topology. If you’ve ever done one of these exercises, you’ll notice it doesn’t take long before you lose track of the bubbles and the lines start to crisscross. Hypertext was explicitly conceived as a way to manage the complexity of such a structure.

I’m tempted to claim that hypertext empowers us to represent more complex conceptual topologies than older literary technologies, but I’m not completely convinced of that myself: consider the subtlety, nuance, and explosive range of interpretation embedded in your favourite poem. It’s more accurate to say that hypertext enables complex conceptual structures to be explicit—baked into the artifact, rather than emerging through reading. A print-era analogue to this concept is that while you can debate up and down what an author meant by this or that word in the text, it’s a lot harder to argue whether or not chapter seven comes after chapter six. The links in hypertext, likewise, connect any part of a work to any other as clearly and unambiguously as adjacent chapters.

Following a hypertext link is an ergodic process—in this case, an interaction with a text which is over and above the everyday act of reading. To examine a text’s ergodicity, Årseth introduces two units: the texton and the scripton. A texton is an arbitrarily-sized segment of static text, and a scripton is a permutation of a (sub)set of textons. For example, each word of a fridge magnet poetry set is a texton which can be arranged to create millions of viable scriptons. In contrast, the entirety of Moby Dick, being a contiguous story, is both one texton and one scripton.

A texton has a definite orientation—i.e., beginning, middle, and end—but a scripton can have as many orientations as the factorial of its component textons—a potentially enormous number, though likely made smaller if we remove the permutations that don’t make any sense. The remaining scriptons may or may not vary the meaning of the overall work, but they will almost certainly vary the reader’s experience. And that is what’s so fascinating about hypertext.

We should, as Årseth does in his dissertation, be able to evaluate a (hyper)textual œuvre in terms of three things:

  • textons,
  • the scriptons their arrangements produce, and
  • the alternate interpretations we can derive from the results.

Using text with a high ratio of scriptons to textons, but low variation in meaning, we can notify, instruct or persuade readers without demanding they invest more effort than it takes to get the point across, while leaving an avenue open for further exploration. At the same time, as an author, you can remain confident that what they’re reading is what you wrote.

The web is a peculiar strain of hypertext

It’s inaccurate to call the web an innovation in hypertext. If anything, it’s an innovation in everything but hypertext. The web trades off behaviours of earlier systems, such as enforced backlinks, arbitrarily short textons and an entire ménagerie of exotic link types, for an open protocol that works across the entire internet, which can be deployed by anybody, using familiar tools and concepts, for free.

The web was largely cobbled together from parts that were lying around, and using it entails dealing with the biases of those parts. The document format, for instance, was adapted from one whose lineage was in print publishing. The method for locating resources is tied strongly to the hierarchical file systems of conventional computers, which considerably influence the size and layout of textons. Since links can cross administrative jurisdictions, there is no way to enforce their bidirectionality. To date there is no widely-adopted standard mechanism for transclusion—the embedding of one texton into another—which enables the reuse of content. Finally, there is considerable downward pressure on the number of links within a texton, since at this time there is no convention for managing the complexity they generate.

The development of the web has clearly satisficed to create and sustain not only a new way of sharing information but a new way to do business and live life. Two decades in, however, and what’s hot? Books and apps. How decidedly un-hypertext-y.

I want to retrofit how we work with the web

What’s nice about the web, though, is all that stuff about it being free and open and workable with ubiquitous—even primitive—equipment and techniques. This makes it cheap to bring the web closer to some of the wild visions of hypertext from the past. If we can tease HTML out to the point of supporting full-screen video games, we can certainly give the rest of the web‘s architecture a gentle massage to realize its true potential as a platform for written communication.

Where we got stuck

Our industry seems to have perfected a formula, the evidence of which is written across the top of virtually every website in the form of its main navigation. How this comes to be, as far as I can tell, is not so much an issue of the technology, but of how expertise is divided, projects are managed, and deals are struck.

The process of making web has gotten more sophisticated. Disciplines have mitosed to account for its subtleties. We have discovered that comprehensive design research beats the Procrustean nature of Photoshop comps. We’ve learned how to iterate. And yet the archetype of the website, and the business arrangement to deliver it, hasn’t evolved much past the mid-1990s: for about the price of a car, you can buy a bunch of pages bundled into sections, with a predictable veneer of graphical paint.

Where we go next

I don’t fault anybody for building a successful business implementing this formula—quite the contrary, as I’m proud of my many colleagues over the years that have done so. But I’m so frustrated with this pattern that I no longer participate. I want to make this medium—our medium—sing. I’m not asking for much, only a change in perspective. I’m certainly not suggesting throwing out methods that work, but rather to relieve them as load-bearing members. To achieve this, I submit the following two proposals:

Proposal one: pulverize the textons, emulsify the scriptons

This document is part of the problem, but in it is hopefully a glance at a solution. It’s an essay, which I am entering into a text editor which is older than I am, marking it up as I go along. I’m doing this because it’s the most efficient way I know to produce web content. I am saving this content into a file, the name of which will eventually become part of its address on the web. This file, this page, is one texton. It’s too big by an order of magnitude.

It wouldn’t make a difference if I wrote into a Word document, blog engine or CMS. As an artifact, unit of progress, and commercial deliverable it is still the same: an indivisible atom which is either ready for consumption, or not. Why we put up with this condition is obvious if you’ve tried the alternative. A few years ago, I had a grandiose vision of producing a treatise on the web as the web. It was to be a literal brain-dump: a densely connected labyrinth of ideas that flowed in and out of one another, an exhaustive map that exhibited the complex interconnections it required, served up in portions small enough so as not to overwhelm my audience. It turns out that managing a hairball of tiny documents with a huge set of links between them is something of a challenge.

Semi-lattice tree diagram
It took Christopher Alexander 17 pages to explain the value of higher complexity in artificial systems and how to deal with it. I’m not going to try to abridge his treatment.

By my account, it is currently considerably easier to create pages and organize them into sections. Everybody understands the method: content strategists, information architects, visual designers, project managers, and of course, clients. You can chop them up into milestones and get paid on delivery, which is certainly handy. A good chunk of the work can be done with a word processor, spreadsheet, outliner, calendar, and Gantt chart app, some subset of which just about everybody has.

This process, however, leaves a telling thumbprint: if you take a typical website, strip off the navigation and common elements so that only the main content remains, and exclude links to and from other sites, you get a lot, and I mean a lot of orphans—pages that were only connected to one another by the navigation itself. That means we’re missing out on the fundamental opportunity of hypertext: the ability to present information how brains—not books—work.

At their best, hypertext links are a hint of something, a foreshadowing. A document that bristles with them is like when a storyteller dangles a juicy detail in front of us, only to reconcile it much later in the tale. Imagine every link corresponding to one of these friendly goads—like when the world spent years rabidly addicted to JJ Abrams’s Lost. Similar narrative acrobatics have been harnessed to explain the complex historical dramas that culminated in the invention of world-changing technologies, as in James Burke’s Connections. If those two can do it for television, I don’t see why we couldn’t do it for the web.

If we’re going to explore the alternative of bite-sized content densely linked, though, we’re going to need to make it the easier way, not just to pull off, but to get paid for.

Reconcile with reader and client

Whether you’re writing or reading, it is heinously difficult to sense how close you are to finishing a work of hypertext—hence the title of this article, named after Chapter 4 of Årseth’s book. While we may experience this problem in our projects with individual artifacts, we typically surmount it at the larger scale by prescribing the project’s structure. For many of us, the page is the current base unit of work product. The section, or aggregate thereof, is a common milestone for a payment schedule. Breaking out of the prescriptive site-section model entails shopping for a new way to illustrate both structure and progress for our readers and our clients.

So I end up making things like this

What you’re looking at is a set of textons: in this case, the published articles on my site, with the newest at the top left and the oldest at the bottom right. The lighter rectangles represent the bounding boxes of the text in each article, preserving the same aspect ratio in which they’re rendered online. They are juxtaposed against the longest document, which can be found here somewhere near the middle, to compare to the size of the document you’re currently viewing. I co-opt the history mechanism of the browser to indicate which documents have already been viewed. This kind of image is useful for demonstrating progress to the likes of readers and clients, as its overarching purpose is to provide a web equivalent to looking at the spine of a book to gauge how much reading there is to do.

There are other uses for this visualization. This particular image omits the 300-plus unfinished and/or unpublished articles sitting in my site’s project folder, but I have another one which includes them—along with my original hypertext experiment. Part of my motivation was to create a meaningful overview to help me identify those articles and finish them, chop them up, or kill them. As such, I suspect editors and content strategists could use this kind of device as well.

As an artifact like this pertains to demonstrating progress, let me draw some inspiration from Dr. McGonigal and friends: there is little more satisfying, after a hard day’s work, than seeing another little box appear at the end of the stack. Except for lots of little boxes appearing at the end of the stack. I’m not deluded enough to think that an indicator like this is enough on its own, but I just might be suggesting, roughly, to gamify both navigation mechanisms and client relations just a little.

Work product versus viable product

In the model I propose, the basic unit of work is no longer the page, but the texton. Representationally, it’s identical: it can just as easily exist as HTML or some precursor thereof, in a file or database. The difference between page and texton is all in how we perceive them.

First, we make textons short. Like one-paragraph short. Certainly no more than a few hundred words. Second, we stuff them with links to other textons in the neighbourhood. Finally, we abandon all care about their situation in the site’s URL path, because we organize textons in terms of what they say rather than where they live.

A texton has meaning, but not enough meaning to convey a complete message. We’ve succeeded in grinding up the unit of work product, but that doesn’t make it fit for consumption. For instance, as I was writing my hypertext treatise, I took to using links to remind myself about an ever-expanding set of useful-yet-parenthetical topics that I nevertheless deemed important to cover, similar to what goes on when we link to nonexistent articles in a wiki. In an effort to provide even minimal coverage, I found myself holding back releases until my scriptons were complete, but every new texton risked birthing at least one more. Finally, I just gave up and went back to essays.

The problem with writing in textons rather than pages is that the workload quickly explodes out of control. My solution is to promote links to first-class citizens, and use the resulting structure to restore authorial sanity and spot candidate scriptons for publishing.

site path diagram
Site paths showing links between textons

With an overview of all the links between our work, we can spot clusters of unpublished textons which link to each other, but nowhere else—with the possible exception of those which we already published, or an outside site. Clusters like these form the basic unit of hypertext publishing: a complete scripton, or rather the complete set of all possible scriptons, for a set of textons we determine to be closed.

As for those sections

We can also use the inherent properties of hypertext to detect the aggregate composition of a particular work. This entails either grouping the textons most strongly linked to one another, or cutting them apart along the axes which are crossed by the fewest links. The result is a set of sections that even the most skilled information architect would never think to produce. As strategies go, they’re subtly different but ultimately similar. There’s a mountain of research on the subject dating back to the 60s, and frankly I’m not sure why we don’t put one or the other to work more often.

My increasing suspicion, anyway, is that sections aren’t nearly as important as we purport them to be. The proof would no doubt emerge after successfully decoupling them from project management. It’s probably why Wikipedia has gotten away with not really having them, at least not as first-class objects: the rhizomatic nature of its production process.

Proposal two: dissolution is the new relaunch

Of course, none of this instrumented awesomeness matters if we can’t get our material into the brains of readers. Here we look not to the innate characteristics of hypertext, but those of the web.

Most people in the market for a website already have one. What they’re looking for is a newer, better site that will solve all the problems they had with the old one. Chances are that the old one’s got a structure and a visual design and it runs on top of some arcane CMS. Adding more stuff to the existing site will only create a mountain of soul-crushing work and cost for something that will ultimately be thrown out.

Furthermore, the platforms and frameworks we’ve become accustomed to using are greedy. Most operate under the assumption that they account for the entire site—or at best they can be sequestered to a particular folder. They ignore one of the coolest and most woefully underutilized ideas that has been part of the web from the get-go: the fact that the protocol doesn’t give a whit about where stuff is, and that you can mix and match back-end platforms over an arbitrary address space—even if those back-ends are on other sites—without anybody noticing.

What I’m suggesting is that we create an instrument which will, from the user’s perspective, seamlessly interleave new content in with the old, until the old can be supplanted completely. This piece of scaffolding would enable us to deploy disparate elements of new content and functionality as they become ready, instead of waiting for a mythical state of completion. Of course, you can still have your launch, but with most of the new content and functionality already online, it will rightfully be more PR party-times than nail-biting terror.

Reverse Proxy diagrams
Reverse proxy in practice, roughly

The instrument to achieve this result is called a reverse proxy. There are plenty on the market, both open-source and not, but none that I am aware of designed specifically for this purpose. Part of what would make it special is its ability to plaster the original site’s template over the new content, as well as bridge the authentication system if necessary and make modifications to the existing navigation and other relevant elements. After configuring the proxy to serve content from both the original site and its replacement, you’d just point the client’s domain name over and nobody would be the wiser. As you produce new work, you whittle out parts of the existing site until you’re ready to launch, then simply point the domain to the new server, effectively taking the proxy away.

All of this is easy

None of what I’ve mentioned above is technically very difficult. Most of the changes I’m suggesting are paradigmatic. I believe this is a better way to produce superior web experiences and greater, more immediate value to clients, with lower risk exposure for our own concerns. There is nothing barring us from working this way. We just have to want to do it.