Publication Architectures: The Federated Wiki
Back in 1995, Ward Cunningham invented the wiki. The basic concept—a web page editable by its readers—was inspired partly by Apple’s HyperCard authoring tool, by the practice of index-card sorting, and by Ward’s notion that a community of people could be collectively in charge of a writing project.
Card Sorting – via GravityFreedom.com
Over a decade and a half, wiki has succeeded hugely, and not just on account of Wikipedia. The tool has been implemented countless times in different contexts and organizations, and remains the simplest and most flexible content management system ever created.
Wiki is a radical technology, though, and continues to challenge traditional thinking about authorship, editorial management, copyright, and the assumption of completeness and finitude of written works. By radically decentralizing the writing process, by sharing it among an indeterminate number of participants, and keeping the process open for an indeterminate period of time, wiki is a major leap forward into a digital literary future.
But Ward Cunningham wants us to re-think that now. Claiming that making the original wiki a centralized, self-contained system was a mistake, he has recently released code for a new take on wiki: as a “Federated” collection of wiki servers, one for each of us. The Federated Wiki is an even more radically decentralized system, for now it exists in multiple places across the open web, rather than being hosted in a central locations (like Wikipedia). Each participant in the Federated Wiki now maintains his or her own pages, but the magic of the system is in the relational interlinkages and content re-use between participating systems.
It’s quite a conceptual leap, and it takes a little pondering in order to get one’s head around it. Helpfully, there are a growing number of videos that work through the ideas, including a talk from TEDx Portland.
Smallest Federated Wiki – A Prototype
Cunningham’s Smallest Federated Wiki system is a more robust client-server application than the original wiki; the server side maintains content and its history, and manages links between servers. The client side, built on top of jQuery, handles the display of pages and facilitates editing. Communication between the two sides is largely asynchronous and transparent. All the writer sees is content and links.
One of the loveliest features is that SFW eschews the page=document paradigm that we’ve taken for granted on the web. Rather, the basic user interface provides a sliding view of multiple interrelated ‘pages,’ while editing happens not to pages but to individual paragraphs. A page view is the culmination of the history of its paragraphs. Each page view also allows the reader to see all the changes that have been made, including where content has moved between wiki servers.
There is so much right about this approach, it’s hard to know where to begin.
Orienting editing and change-tracking to the paragraph level, rather than the whole document, makes enormous sense; in fact, we brainstormed this same concept years ago for the OMMMM project at SFU, though we never figured out exactly how to implement it. Paragraphs are a natural unit of writing; conceiving a page as a superstructure of these historical units is much cleaner than trying to keep track of the internal changes within a larger and more complex unit like a whole document.
On the other end of the spectrum, reconceiving the web interface as not a single page but a collection of panes, amongst which content can be shared, copied, linked, is much more interesting, and much more like the process of sorting cards on a table than looking at a single page at a time:
Content is stored, as simply as possible, as JSON, while jQuery in the web browser takes care of showing it, navigating it, and allowing each paragaph unit to be edited and tracked. That’s smart… much smarter than heaping code into the server side of a wiki to manage more and more features.
It’s hard to see exactly how this might be adopted and the effect it will have on writing and sharing processes. But then it was also hard back in the 90s to imagine how the original wiki might turn into an encyclopedia, or the shared memory of a workgroup, or a place for a book’s fanbase to collect their ideas. The federated wiki seems to push in all the right directions, though, so I’m bullish on this, and plan to try this one out as soon as possible.
Wired Article: http://www.wired.com/wiredenterprise/2012/07/wiki-inventor/
SemanticWeb article: http://semanticweb.com/ward-cunninghams-smallest-federated-wiki-paves-road-to-our-curated-future_b27267
ActiveState article: http://www.activestate.com/blog/2012/08/making-home-smallest-federated-wiki-stackato