💾 Archived View for soviet.circumlunar.space › rwl › gemlog › 2022-02-07-nelson-on-hypertext.gmi captured on 2023-05-24 at 18:39:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
I have been reading Ted Nelson's book Literary Machines, in which he describes his vision for a system of hypertext documents which sounds in many ways like the Web we have today:
Literary Machines at archive.org
I've found it really interesting to see that Nelson's ideas from *1981* (and earlier) have more or less been realized in the modern Web. The Web has links between documents, and to parts of documents, for example. It has the idea of browsing and building up a stack of documents you've visited, with a back button to pop one page off the stack. Nelson even sort of predicts the arms race between ads and ad blockers, concluding "it is not clear that [an] advertising subsidy is feasible".
There's so much there, so far ahead of its time, that it makes Nelson's ideas about the things that we *haven't* got yet more interesting, too.
So far, the idea I've encountered that seems most important to Nelson but which hasn't been built into the modern Web is the idea of versioned documents, where you can basically see the document at any point in its history.
You can of course put documents in your version control system of choice today, but that isn't Nelson's idea. His idea is more like treating a document as a whole git repository, in which "the document" at any particular version is assembled from pieces in the repository. In the interface Nelson envisions, you can scroll from the beginning to the end of the assembled version have, but you can also scroll back and forward in time for any given piece, display different historical versions of a piece side by side, request different pieces, and so on.
As far as I know, no one has built an interface for versioned documents in this sense. But something like this *could* be relatively easy to put together today, if you built a new frontend for git.
In git, a commit object points to a tree object, which ultimately points to a bunch of blobs of data. Usually, those blobs are used to model the contents of individual files, and the trees which point to them model a directory in a filesystem; but a tree could instead model a single document, containing pointers to the blobs of content in it. A commit would point to a sufficiently interesting tree, a "snapshot" of the evolving document.
Programs like pandoc already represent documents as a labeled tree. One could map this tree to git's storage, and then build an interface for making commits and assembling documents from their pieces on the fly, in roughly the way Nelson envisions. So:
All that's missing is the right "porcelain" atop git, and then we could live in the document dream world that Nelson envisions, right? We're so close! Yet no one has built such an interface, as far as I know. Why not?
There may be some good reasons. First of all, what are the pieces? Breaking documents up into pieces smaller than a whole file requires being able to parse and reconstruct the file, which immediately ties you to a specific syntax for the document (or as many syntaxes as you're willing to parse). And for this parsing to actually be useful, the pieces have to be meaningful enough to make sense as semantic units; but understanding the semantics of documents is hard.
In particular, different ways of slicing documents into pieces make sense for different purposes. As an author, I probably mostly care about tracking changes at the sentence or paragraph level; blobs smaller than a sentence would make for cumbersome diffs and cumbersome "scrolling through time". But as a reader, editor, reviewer, or commentator, I probably care about arbitrary word strings: I may want to see earlier versions of, say, the second half of this sentence, which might not correspond to any particular blob in the repository, or of the entire fourth section, which corresponds to many. (Nelson himself envisions a system in which each *character* in a document has an address, for this reason. But few people care to see the history of documents at the granularity of characters; so this just puts the hard decisions off.) There are *many* difficult-to-impossible decisions to make if one wants to provide a nice interface for a versioned document conceived as a tree. I suspect that the need to make these decisions might mean it's too hard to build a workable system.
A system of versioned documents might also just not be that useful. This is a hard judgement to make, because it's easy to dismiss new technology when you can't yet envision the changes it will enable in your work. But it's worth asking: how often, as an author, do I want to go back and read the older versions of a sentence, or paragraph? How often, as a reader, can I jump around in a document's history without getting lost and confused? As someone who does a lot of writing and reading, my answer is: nowhere near as much as Nelson wants to make possible. I suspect there are fairly tight cognitive limits on our mental representations of a document that prevent us from making much use of such features. Storing and making the complete evolution of a document accessible to an individual writer or reader might be too much work for too little gain.
On the other hand, I can imagine versioned documents being *incredibly* useful when it comes to collaborative authoring, and this of course is where git is already being used very successfully. When other people are editing parts of a document without knowledge of each other, getting an overview of the changes, being able to revert them, and making adjustments elsewhere in response to them become crucial operations. Browsing and understanding the history becomes essential, because the history is not the product or property of any one author's brain.
I wonder if it could be equally useful on the consumption side. Could there be something like "collaborative reading"? I've never heard of anyone talk about this but I'm sure it must happen. I bet it happens a lot in the legal field, for example, or in engineering teams: some laws or design specifications are too long for any one person to read and understand, so different people become experts on different parts of the document and then inform each other about them on a "need to know" basis. It's hard for me to say, but maybe Nelson's ideas would make such collaborative reading easier, in a way most of us can't even imagine yet.