On Gardens and Streams

I attended my first IndieWebCamp session last week, on the subject of "gardens and streams", otherwise known as wikis and blogs. Given the current global situation, the entire thing was remote; I participated via Zoom. It was fun! I'm glad I got to meet everyone.

Wikis, and how they differ from blogs, is a topic that interests me. You may not know it, but my domain sports a wiki, powered by MoinMoin. I mostly use it to store technical notes and recipes.

I'm no historian, but it seems obvious that wikis were created mostly in order to make certain kinds of websites easier to build and maintain. In the days when "webmaster" was an actual job title and when traditional websites were maintained by an elite group of technical people, using arcane languages like HTML, wiki powered websites:

• were collaborative. Anyone could create or edit a page, from the wiki site itself, and a page often had many authors, with many revisions.
• tended not to use HTML directly, opting for their own text-based markup systems.
• made it easy to link between pages, allowing users to create sprawling, hyperlinked knowledge bases - hence the garden metaphor.
• made it easy to see who had edited a page, and what revisions were made.

Wikis, in other words, made websites democratic.

Blogs became popular around roughly the same time as wikis. As a class of website, they were not entirely unlike wikis, but were perhaps less well defined in what features they were meant to offer. About the only hard requirement of a piece of blogging software is that it had to manage chronologically ordered content - or streams of content, to use the ongoing metaphor. Blogs are basically just online diaries or journals, presenting a feed of timestamped posts to the world at large.

All other blogging software features are negotiable. Many will incorporate WYSIWYG editors, others let you use text-based markup, while still others make you write all your posts in HTML. Most let you tag a post, but some very basic ones don't. Many have online user interfaces allowing you to manage your content while others (like any static site generator, for example) do not.

Notably, blogs tend to focus on a single author. That isn't to say that many blogs don't offer multi-author features, but I would argue that this is not the standard use case. Unlike a wiki, collaboration is not a defining characteristic of blogging software.

Collapsing the Differences

Martin Fowler's main web presence consists of what he calls a bliki, a combination of a blog and a wiki. Like a wiki, it very easily allows you to throw up informal pieces of content using simple text based markup. Like a blog, it allows you to easily see chronologically ordered content.

Interestingly, he's the only editor of his own site, so the collaborative aspect of wikis is not a feature of his bliki.

And this leads to an interesting discussion on the differences between blogs and wikis when you're the only one managing the site. For many people, the whole point of a wiki is that it's collaborative. If you're the only editor, what's the point? Why wouldn't you just use a blog - albeit, perhaps, a reasonably powerful one that incorporates wiki-type features like text-based markup and easy page creation? The differences between the two, in that case, tend to melt away.

It's a good question. It's an especially good question if, like me, you maintain both a blog and wiki. Why on earth would anyone do that?

When to Plant and When to Row

As mentioned, there is at least one thing that a blog, by nature, does out of the box that a wiki does not: it displays a reverse chronological listing of all its posts. Not only does a wiki not do this, it probably doesn't make sense for a wiki to do this. But why not?

And the answer to that question cuts right to the heart of the matter. Blog posts are, by nature, timestamped. They have a publication date. In a sense, the publication date of a blog post is part of its content. Blog posts exist at a particular point in time.

Most blogging software will obviously allow a user edit a blog post after it's published (to correct spelling errors, for example) but it's generally understood, because of the very nature of blogging, that any edits to a post after the fact should be minor. One would never edit a blog post so much that the publication date suddenly becomes a lie.

A wiki page isn't like that and its publication date usually isn't a very interesting piece of information. Wiki pages, the flowers and weeds of your garden, exist outside time - outside the stream. So what kind of content fits this mould? Paradoxically, it's two seemingly opposite types: what I'll call the half baked and the perfectly baked.

Yes, this is my blog and I'll use baking metaphors if I want to!

Half baked pages are those which undergo numerous revisions. Think of personal notes, or biographical information, or a resume. These kinds of pages exist to be edited frequently and enthusiastically. The publication date for these pages are not useful, for obvious reasons.

Perfectly baked pages, on the other hand, are those that are not edited frequently, because the information in them is "timeless" in some sense. If the information in a page is timeless then, obviously, the publication date is probably not useful. An example I often use is a recipe page. No one needs to know when I copied my preferred recipe for Cranberry Orange Buttermilk Muffins to my wiki. They just need to know how to make them (and you should make them; they're delicious). A non-food example would be my Certificate Management Basics page, which I use to remind myself how basic cryptography works.

This, then, is the reason I have both a blog and a wiki. In essence, I use my wiki for notes and as a personal knowledge base, a purpose for which it excels. My blog wouldn't be an appropriate place for this kind of content; the world doesn't need to be notified when I've added a barely coherent guide on how to use x11vnc, nor does it need to know when I've recorded a new chili recipe.

Further Exploration

So where to go from here?

Well, for one thing, I'll admit that my wiki is getting a bit long in the tooth - it's just kind of ugly. The IndieWebCamp session dropped some interesting new pieces of software to try out, like TiddlyWiki, so I may end up trying some of those. We'll see.

The session also just dropped some interesting use cases for wikis, like second brains, commonplace books and mind palaces.

Anyway, lots of food for thought!