When Ted Nelson originally imagined stretchtext, a type of hypertext, he appears to have been thinking of an almost analog control, a sort of information faucet or dial regulating the overall amount of text displayed. "Stretchtext" on the web today, however, usually only employs a tree structure similar to directories on a hard drive, with users clicking on icons or links to expand individual items.

The big exception here is Slashdot with its adjustable "thresholds" which specify minimum criteria for comments to be displayed. This seems more like an emergency measure, though, since reading all the comments would be beyond human capacity. Because of this overflowing abundance of disinformation, the thresholds are only sluggishly interactive: you always have to wait for the page to load after adjusting it, you can't manipulate the thresholds like a volume dial.

Perhaps the wide spread of tree structures with individual node expansion can be explained by the dominant paradigms within programming. Any webpage trying to implement instantly responsive stretchtext will have to use Javascript, which means everyone writing stretchtext will have minds at least slightly shaped by the thought patterns of programming. The web grew up as object-orientation with class hierarchies of inheritance became the big thing. This, and the directory structures used by all modern file systems, might explain why tree structures have become dominant in people's minds.

E. W. Dijkstra's famous argument against the use of 'goto' in high-level programming languages in fact celebrates the dependability of designs on paper:

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

Writing "source code" for HTML yields a similar mental divide between the situation in which a page is written and the situation in which it is viewed. e.g., writing this page I would flip between my text editor and my browser to see how it looked like in motion.

Though, I dare say Nelson wasn't entirely above being influenced by the dominant paradigms of his time. His controls for scrolling text and regulating the amount of information recalls the Roald Dahl short story The Great Automatic Grammatizator of the previous decade. In the story, a Difference Engine-like machine is constructed, for writing novels: the operator steps on pedals to control the different aspects of the story, like pace and sentimentality. Both Dahl's and Nelson's visions bear striking resemblances to cars; perhaps they came to mind because they had the most complex common interfaces in the fifties and sixties.

But enough with the talking down at other forms. What's Nelson's stretchtext good for?

One obvious possibility would be that different levels of a stretchtext probe deeper into a matter. This is however taken care of in print pretty well already, with introductions and footnotes. Though many books have footnotes that could become a book on their own, placing them inline in an online text they'd probably look best as individually-expanding nodes.

Levels could find use in showing different iterations of a text. Incomplete drafts by known fiction authors usually only get published after their death; for instance, the posthumous selection of texts by Douglas Adams which became The Salmon of Doubt — just to be on the safe side, the selection contained an article where he defended the publication of P.G. Wodehouse's incomplete novel: his argument was that it gave an insight into the working method of the master. Considering Adams' own interest in new media, it's a shame we couldn't have an interactive insight into his process.

Mark Twain was better prepared for posterity: the source material for his Autobiography is forty years of notes and extensive transcripts from his deathbed. Twain himself elected to release parts of the material on time delay, hence there are three different versions of the book.

Another possibility: even popular science has a tendency to present evidence contrary to a theory immediately after that theory has been explained. This is of course good in that theories should be questioned, but it tends to hinder learning: most people find it easier to let the glue harden on a concept before they start trying to take it apart. Scientific papers usually get read more than once; could not stretchtext find an application in hiding the more complicating matters on the first reading?

This very document demonstrates another application for Nelson's stretchtext: by letting the user toggle the display of digressions and sarcasm, it becomes a spectrum of more and less personal (or amateurish) writing.

If nothing else, it could be a good placebo for the author: killing your darlings becomes much easier when they're not actually banished to the void, just relegated to another level of the text. It's interesting that the possibility of someone reading it makes a big difference even if the number of people who actually do so approaches zero.

Let me try to find a more radical explanation for why Nelson's hypertext forms have seen little use, by applying theories such as are being popularized by Seth Godin: that people relate to everything they encounter by inventing stories about it, through an unending mythologization.

If we consider a web browsing session, it's symptomatic that users tend to follow just one link from a given page, only using the 'back' button on special occasions — typically when they're confused. I don't believe I'm being very controversial by claiming that user satisfaction on average will be in inverse proportion to how often a user has had to use the back button — that is to say, a web session is more satisfying the more it forms a coherent story. Supporting this is the fact that 404's which mention the back button often seem jarring to me, as if they're breaking the fourth wall.

Artifacts explicitly called hyperfiction for web browsers (e.g. [Burne 1996]) tend to be laid out as nodes with one or a few paragraphs of text describing what happens at this junction, then posing a choice to the reader towards the end. As such, they're closely related to the Choose Your Own Adventure hypertext books.

Looking at another of Nelson's hypertext variants, hypertext with two-way links as demonstrated by CosmicBook, might shed light on why hypertext has been popularized in a much more limited form than Nelson originally conceived of. As we know, today's web browsers have a "history" you can step back into using the back button; if you've just stepped back, you have a "forward" button. However, if you rewind the session's history and follow a link on one of the pages, the "future" disappears — that is, it's no longer easily available by a single keypress, but becomes a thing to be unearthed by calling up another interface. This is oftimes frustrating; it may have stayed with us through ten years of phenomenal growth in WWW because the alternative, a visible chain of pages, would be too difficult to use — or it doesn't fit the narrative metaphor.

My claim is this: having two-way links weakens the parallel to a narrative, reduces narrative drive. Instead of events in sequence where one thing leads to another, the link winds up saying "these two things are related." It's symptomatic that CosmicBook's example texts mostly consist of (sarcastic) side-by-side comparisons: two-way links tend to invite moving your head from side to side, not coming to rest on either of the sides. There's also the problem of linking from several points to one single point, such as is routinely done on the web; neither popping up a menu of possible targets or opening all of them are satisfactory solutions.

Limited two-way linking between independent authors does exist on the web today as "TrackBack", even if it requires some cooperation between the two pages. The telling difference between TrackBacks and CosmicBook links, however, is that TrackBack links always appear after the article, and contain excerpts from the context in which the article was quoted. The subtext is that of telling what happened after the article was written; it establishes a chronology as in a story.

The problem of web browsers' "disappearing future" may stand uncorrected because it works within the metaphor: it's like going back in a story and changing a choice. If you have a storyteller at your disposal who's extravagant enough to grant such a request, you'd be pushing your luck to ask him to keep track of several possiblities at the same time.

If narration comes from verbal explanations, it's perhaps best suited to the role of scapegoat in the conflict between the tradition for explaining complicated thought structures with linear words, and non-linear structures which might fit better into associative thought patterns but have few reference points for how they might be read. Presumably this is the source for the "fetishization of 'pages' and 'websites'" which Nelson laments.

Perhaps the strongest reasoning against hypertext is that, when it's not used to reinvent the encyclopedia, it merely makes structures explicit which have been implied adequately by conventional texts. In fact, that making these structures explicit yields no gains. Peter Whalley (in [McKnight/Dillon/Richardson 1993]) claims that linear media already create highly non-linear structures in readers, and that explicit link/reference structures only makes it more difficult to grasp the author's meaning: also that there's no increase in comprehension or effectivity in "strong" students, while "weak" students are lost to confusion. (Quoted from [Kommers 1991] and [Mandl 1991]) Unfortunately, no specific criteria for "strong", "weak" or "comprehension" are given in this context.

Considering the numerous authors who used to relish in overwrought language for its own sake (and modern subcultures complicating their sociolect by substituting numbers for letters) makes me wonder if tangled writing might serve a purpose besides indicating status: it could also function as a "linguistic knot" which is pleasing to untie in your mind. Correlated with theories that fun is the same thing as learning [Koster 2004], I can only wonder if it's much easier than we usually think to add too many helping structures, that a text very quickly can appear so trivial and combed-through that there's nothing more to do with it.

A telling aspect of early multimedia theory is how all sorts of animation, sounds, bells and whistles are considered improvements. No one ever seems to have considered how incredibly annoying it could become in practice.

Trial and error is probably the only way to ascertain what is a suitable flow of information. For instance, most people will likely prefer fairly distinct visual indication of links on a webpage — vain webmasters who force users to wave the pointer over the text to find links will find themselves deserted rather quickly, unless the links are superfluous distractions. It's interesting that the hyper-aspects of HTML (links visited or not) are mostly indicated by color; perhaps this is because there are hardly any conventions on the use of color in paper typography. This essay also employs (faint) color coding of digression (like this) and sarcasms like this.

"Mouseovers" could be used to indicate short-distance relations; see for instance the reference section at the bottom of this page. By moving the pointer over the "(indir.)" part, the book from which the reference comes will light up. A sort of mouseover is exploited on websites where users can be presumed to be looking in the status bar to see where a link leads; also that they don't need to be told that, say, 'nytimes.com' leads to the New York Times. This "web competence" has become widespread enough to be employed by fairly mainstream news sites.

The use of tooltips taller than a single line will usually feel like a too big intrusion. Apropos of this, it made a surprisingly big difference for this page when I added a "minimize button" (±) in the control box, even though it's only two lines tall.

Graphical user interfaces have a tendency to overload much quicker than diagrams or photos. If GUI's can be thought of as interactive diagrams, why should they obey vastly different rules of thumb than their non-interactive counterparts? Perhaps it's the fact that you have to relate to widgets as choices: if every widget can be seen as analog to someone asking you what you want to do, user interface overload becomes equivalent to too many people talking over each other.

The field that's seen the closest development towards Nelsonist stretchtext is perhaps interactive information diagrams like this which describe things developing (in this case, spreading) over time. Presumably this is because our faculties for reading images unfolding over time is better than for text, and also user interface problems. For instance, if you were to toggle digressions and sarcasms on this page, you'd have to move the pointer to the control box; this involves changing focus away from the text you're controlling. If you wanted a better feeling for what exactly the controls toggle, you'd probably have to be very exact about keeping the mouse pointer quite still over the widget while you change focus to the text and click. It's quite fiddly as it is; if the widget was any more complicated you probably wouldn't be able to perform the maneuver at all.

Perhaps text that's mutated interactively would be easier to read if it contained "anchoring" elements such as icons for selected paragraphs. (You can see for yourself by turning on icons for this level.)

Another possibility for providing easier overview could be oversized letters (as in, three lines tall) at the beginning of each paragraph; this would also encourage authors not to begin every paragraph with the same word.

As long as you're reading this essay in a web browser, you've had to click at least once after loading this page to arrive at this sentence; this sentence is something you've asked for. This fundamental property of interactive media can make a great psychological difference: at its most basic, increasing the reader's participation, giving him a sense that "he makes things happen" — because he does, even if the structure of what he's manipulating does nothing but simulate "paper under glass."

Interactive design means considering the user's process, for instance at the beginning of level 1 in this essay: the third paragraph invites the reader to experiment with the controls by turning off the very same paragraph — I could count on every reader seeing this because it's visible when the page is first loaded; once they've begun fiddling with the controls, all bets are off.

Unless you've clicked the "print" link at the upper right, this argument literally replaced the previous two. You don't have the other two visible to compare with unless you've opened them in duplicate windows, something that's fiddly with today's user interfaces. Though no letters are actually lost by putting all three arguments on a page and printing them, an interactive design as demonstrated by this page makes each level of the text stand on its own, less bound by what's come before.

As a final example, this essay has an afterword that's not available in the floating navigation box in the upper right corner: the quickest way to reach it is to switch to level 4 and find the link at the bottom of the page. This makes it more likely that people will read it last, as opposed to the more browsy feel of the main body.

It's telling that, the moment I begin talking about interactive design, I switch to more loosely defined, less formal words like "fiddly" — because there's no proper vocabulary to describe interaction and user interface.

One medium already has interaction as its basal property: electronic games. The worst thing that can happen to a videogame would be that it acquired a rumor for "having poor controls," or a cumbersome user interface, or that it's lacking in the ever elusive "playability." This all points towards controls, interaction, being their fundamental feature. Considering that the videogame market has been in a state of having to learn to swim while it's rapidly drowning for about twenty-five years, you'd imagine there'd be something to learn from their development. While most game designers seem to operate mostly on gut instinct and wrinkle their noses at theory, we should be able to glean some principles from the games that have succeeded.

A growing development in games since the nineties has been the gradual introduction of game concepts to the player; for instance, a war game where you start out with ground units and have to succeed with them before being allowed to commandeer planes — a rather literal example of learning to walk before you can run. This has become more noticeable as games have increased in complexity: these days, you're often talking tens of hours typical playing time before you've been introduced to most of the tools and techniques.

Design strategies like this have been used in regular applications: Convolver for Adobe Photoshop, designed by user interface guru Kai Krause, handed out "gold stars"(at the bottom of the screen) as you explored its various image manipulation tools. Only when you got five stars did you unlock all the tools.

This, of course, established a safer, less complicated "sandbox" environment for the beginner. Unusually, it was done by beginning with simplified tools and ramping up their complexity — unlike applications and games which feature a so-called "tutorial" in which the user apes given sequences and "learns to use" one tool after another: Convolver merely watched over which tools the user had explored and gave him more things to play with when he had expended what he had.

Could lessons from games and applications be folded back into hypertext? This essay has exploited the typical reading sequence to make it more probable that the more advanced interactive designs only get used after they've been spoken of; for instance, the next paragraph uses "tooltips" as mentioned in level 2.

Videogames, and console games especially, have a tradition for controllers adapted to individual applications (like this one, or these ones; interestingly, both are for rhythm games). Though most of the gadgets in this category are rathergimmicky, there's a broad consensus that it works very well when sufficient thought is put into it. Office PC's have also seen this effect with the recent invasion of "scrollwheel" mice which are a perfect fit for webpages.

Most videogames these days have "cutscenes", non-interactive movie sequences, and many games allow you to cut them short by pressing a button. An alternative, which might qualify as stretchfilm, would be to give a short summary instead of abruptly ejecting you from the movie. This is, however, never done in today's games, presumably due to budget constraints.

This type of design has been done, though, before speech became the norm in games, in particular in the adventure games published by Lucasfilm Games between 1990 and 1995. We'll look at one not-very-interactive sequence from Indiana Jones and the Fate of Atlantis [Barwood/Falstein 1992]. The game is adapted from a comic book, and so it tends towards a bit too much exposition all at once. Different player temperaments are accomodated by letting you press the Esc key to fast forward to keypoints in the exposition; only if you press Escape repeatedly does the sequence end suddenly.

The first sequence always ends with Indiana Jones and the female lead Sophia Hapgood agreeing to travel together to Iceland. If you've been patient and sat through the entire sequence, the dialogue plays out as follows:

(Today's games are less story-driven and often only use cutscenes as icing on the cake. Instead of inline summaries, the player is usually reminded of what goals need to be met during the course of the mission — and it usually is a mission.)

--- merore --->Les etterordetRead the afterword<<GÃ¥ tilbake til fÃ¸rste nivÃ¥Jump back to the first level<GÃ¥ tilbake til nivÃ¥ 3Go back to level 3

This essay was written to meet the requirements for the University of Oslo HUMIT1730 course on hypertext. I thought it might warrant a life beyond the end of the course since, as I wrote at the beginning of level 1, I've been hard pushed to find another stretchtext of this particular kind. (Also because I'm not likely to rework it into something less rambling in the immediate future.)

To ease implementation, the different sections of the text were made to fit neatly into set theory (I think), languages and levels being mutually exclusive of other languages and levels, digressions being subsets of levels and so on. This simplified design excludes some legitimate uses besides the obvious easter eggs: prose that contained stretchy bits had to be written specifically so it'd be easy to ensure the full stops would be placed correctly for all states of manipulation.

Making the document bilingual really brought me over to Nelson's point of view as regards his dislike for inline markup: towards the end, I was editing by looking mostly at the web browser. If you look at the HTML source, it doesn't gain much in readability even if you know both languages, and making the text trilingual would be a fearsome undertaking: already most hyperlinks are simply copy-and-pasted despite the high paragraph-by-paragraph correlation between languages (except for this level). It appears that in cases like this, the structure of HTML poses a dilemma between spaghetti-markup and copy-and-paste.

Interestingly, the biggest problem of writing effective Nelsonist stretchtext on the web turned out to be that browsers are quite poor at maintaining something like a coherent position while expanding text — the pathological case here is toggling digressions towards the bottom of the page on the "print level" that displays all levels.

The "--more--" navigation boxes towards the end of each level were a late addition when I realized that position: fixed didn't work in IE5. The fact that there isn't any navbox in the afterword made me go for the 'back' button instictively, as if I suddenly lost sight of Murray's guiding moon.