Hunting The Muse

Weblogs, Wikis, and Comments

Weblogs have always frustrated me because of the limitation of their form. What's important is getting our thoughts and reactions down. The whole creation-date reverse-chronology thing is kind of arbitrary, though.

Aside from being arbitrary, though, I think it is limiting. The ephemeral nature of our weblog thoughts gets in the way of heavier analysis, and serves as an obstacle towards building on our earlier thoughts. Furthermore, the comments on weblog entries could channel the input of the comment-givers in a more useful manner.

I'm planning on abstracting out some of the functionality of my own weblog / wiki combination, and I think I have the plan nailed down.

A weblog entry and a wiki entries are the same thing - a collection of text that is about something. Both of them have added features beyond that. Wiki entries are usually, but not always, editable by other people. Weblog entries usually, but not always, have comments afterward. Wiki entries usually, but not always, have revision history.

I believe both styles of entries should have all of those capabilities. (I personally prefer to use my wikis as way to update living documents of my own - I'm not so attached to the group-authorship part. But I like having the option.)

They are the same thing. A wiki entry may or may not be able to be edited by anyone. A weblog entry merely restricts its entries to be edited by only certain authors. But it doesn't have to.

A weblog displays in reverse chronological creation order. It doesn't have to, though. A wiki doesn't, but it could.

So, that's the first step - to see them as the same thing. We'll call them nodes.

Revisions

Nodes should have revision history. This is common for wikis - it should be common for weblog entries, as well. Some of our weblog entries are long essays, that require a lot of effort and work. We might want to revise them and update them.

I've already written a Revision History plugin for Movable Type 2.x . It works well, and you can see it working at the bottom of my revised weblog entries, or over in my "Living Entries" sidebar.

Revision history is already common for wiki entries, because of the chaotic group authorship. But, it is useful even for single-authorship environments.

Comments

A node is a collection of text. The node can elicit comments. Since there are multiple possible revisions for a node, these comments could eventually be incorporated into the node itself. These comments could be tracked, so as they are incorporated, they are checked off. If a comment is checked off, it would not display underneath the next revision. It would continue to display under the older version of the node.

It is true that group-authored wiki nodes already have comments put right in the node by their many authors. But there are advantages to having the comments be separate from the node - plus it enables comments by multiple users while the node itself may only be authored by a smaller set of authors.

So, comments would be attached to a revision. Each time a node is edited, someone can choose to resolve, hide, or promote a collection of those comments. Going back a version can let someone see the old comments, and if they want, address them or unaddress them as of that version.

A comment is attached to a revision of a node. When created, it stores what revision it was created against. And it has a "resolved" attribute that can be set or unset at someone's whim.

Flow

Imagine firing up your blogging tool (I use Ecto), and creating your node. You assign it a WikiWord, and you publish it. It's now a wiki entry. But you also click the checkbox to say that you also want it displayed in your weblog view, which displays your chosen entries in reverse-chronological order, by creation date.

You would also specify if, in the weblog view, you wanted it to always statically display the version you are writing now, or instead always display the most recent version.

It would be the same through the web. You're reading an old wiki entry, and you come across a WikiWord with no entry. You click on it to get the edit form to create the new entry. And like before, you choose whether or not to display it in the weblog view.

You could also select whether or not to allow this particular node to only be editable by yourself, or by others.

And, when editing old nodes, you would tell it whether to update itself in the weblog view to its most recent version. And, you could tell the weblog whether you want it to redisplay your node by your edit date. You would tell your weblog whether to display this node by its original creation date, by the date of its most recent edit (causing it to disappear from its old chronology and reappear in its new chronology), or even both.

The node would have revision history, and comments. The weblog view is just a way to view multiple nodes in reverse-chronological order.

Bundling Nodes

Finally, a node can contain other nodes. Why not? Perhaps you want one node included that has an ever-evolving definition of a term, inside of another node that discusses that definition.

The inner node could be a simple link, or, with a flag, could be set to display itself inline. I have already written a movable type plugin that does this for Kwiki wikis.

There are two ways to handle this, both of which require some disciplined coding. One would be to only one allow n levels of nesting deep, usually one.

The other would be to allow multiple levels of nesting, or to require the node to keep track of what nodes are being referred to.

Either would be necessary to eliminate the possibility of infinite loops.

---

I think the combination of these features would enable a far deeper level of analysis and collaboration among webloggers. Right now our weblogs are very biased towards ephemeral thoughts and reactive commentary. But if we stir in the ability to allow weblog entries to:

• become more of living documents like wikis
• continue eliciting commentary through the reverse chronological view
• refer to other weblog entries for added life and wisdom-building
• track isssues and suggestions in a rudimentary fashion through incorporating revision-based comments

then we will have a much faster-evolving community, in terms of both participation, and wisdom.

Posted by Curt at June 22, 2004 09:42 PM