Alternate Vision

Mike Caulfield writes in "Smallest Federated Wiki as an Alternate Vision of the Web" that after three weeks of using our reimagining of the wiki (and really, of the web) that we undermine some of the basic premises of the web; and how good that feels. post

It’s been 20 years since MOSAIC and over 50 years since since Ted Nelson invented computer-based hypertext and we are still not writing in hypertext. See Project Xanadu

We think we are writing in hypertext. But look at what Nelson is talking about. Does the composition process he was trying to create sound like what you do when you compose? Are you constructing “spatially”, in three dimensions?

In all likelihood, you’re not. You’re linking pages to one another, but you aren’t doing anything like And you really can’t. Because the dominant paradigm of the web is that you are on one page at any given time.

You don’t go into WordPress and work on three pages at once, fluidly shifting bits and pieces until a multi-page networked structure emerges.

Rather, almost all web writing begins with an idea that we are going to write Page X. And Page X can absolutely drop into a web of links to page Y and Z. But we are never invited to change Page Y and Z as a response to the existence of Page X. Or to write a concise and specialized version of Page Y uniquely tuned to the context of Page X.

That’s using links, but it’s not the spatial composition that Nelson is referencing. And strangely, it’s less than we had with some of the Hypercard variants of the 80s and 90s.

As Nelson himself said, the current web is FTP with lipstick. It’s a works cited page with hidden links to other documents. But it ain’t hypertext.

Smallest Federated Wiki solves this through a focus on allowing page-refactoring across entire sites, along with features that make a pass at Nelson’s dream of a pool of reusable bits.

We call links internal to a page “jump links”, but really all links are jump links.

Worse yet, they are “blind jump links”. You’re reading along in a page, there’s a link to another page, providing (supposedly) additional context.

But when you click it, it doesn’t provide additional context. It provides a *new* context. And if in that new page there is yet another link, you are whisked again into a new location, usually reading text only marginally related to what the link was supposed to provide.

Every page, because it is a complete and total page (or as Nelson would explain, because it is essentially an FTP’d document) can’t truly supplement context. It has to own the context. Instead of connections, we get teleportation.

If you want connection — if you want to supplement context rather than replace it — you need parallel pages.

Parallel pages — or, in the case of SFW, pages laid out in columns — allow us to read spatially. New pages open to the right, while preserving your current context.

HTML is at heart a publishing format, one that does very well with static text. It’s a great format for a snapshot.

But when we add data to text, we either lock it into the document as an output (a chart or other output format) or, if we want to keep it editable, we embed it from a third-party application.

In other words, the process of publication becomes a process of freezing our data in place or exiling it elsewhere.

SFW has an elegant solution to this: everything becomes data. Your paragraphs are a little nugget of JSON, with a wrapper that tells the page “This data should be displayed as a paragraph.”

One of the big sticking points people have with the SFW interface is the bottom bar of revision history.

Each icon represents a specific action in the page history. Click any edit, and it opens up a copy of the page at that point in time.

That’s pretty standard for a wiki. But here’s where it gets pretty neat. First, a quick scan of the set of tiles shows you the history of the page concisely.

You can see the sequence and amounts of adds, edits, and deletes. If the page has had multiple editors, you can see how it was passed back and forth, and who did the bulk of editing, or even which editor tended to add, and which to delete, all at a glance.

Hovering over the edits gives you an even more detailed view of the sequence of changes. As you hover over each icon, each parallel page scrolls to the edit in question and highlights it.

It’s perhaps weird that I would cover the federation aspect of the Smallest Federated Wiki last in this article. But I have two good reasons for that.

The first is it is really hard to grasp what federation looks like in wiki-land without trying it.

The second is that federation is really a smaller idea in a larger vision. The core problem addressed in Smallest Federated Wiki is how to make a wiki that resists calcification.

Parallel columns, draggable elements, and revision features make reorganization cheap and attractive.

The JSON basis prevents fossilization of data elements, and allows an easy route to bring dynamic third party material into the site.

And federation’s secret weapon is diversity as an evolutionary strategy.

But this is perhaps enough of a post for today. The point here is to just try it. Explaining why you’d want to do this stuff is like explaining why you’d want to browse web pages in 1993.