June 22, 2004

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.


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.


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.


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


I wish you would either quit writing things that I want to read, or would write less often. Too much to think about.

Anyway, the past few months I've been thinking about all these free authoring tools out there in the world. Weblogs, wikis, forums. Seems like they do essentially the same thing... take in data, store it, and spit it out. Great things have been accomplished with the spitting out of data, but when you get down to it, all of these systems lock you in to a single paradigm where data and input are concerned.

Seems like you want to break out of the single paradigm... as do I. Someday, someday.

I want a system (a simple system that even I could use) that would let me define the records I want to input, and the interfaces I use to input that data as well as the output... without all these complex workarounds that I'm too lazy to implement.

And then make it where people could import and export these interfaces, data structures and output templates so they can be shared, and possibly even dropped into stand alone applications (ala Ecto.) And all this has to be open source, or free for me to use. Oh yeah, and it has to be extremely efficient.

Maybe I want too much.

Posted by: Robert Waugh at June 23, 2004 02:59 AM

We started building something like this on TWiki (adding weblog like pages and displays and creating a comment page for every page) and the combination was nice to use. We stopped and switched to MT because developing tools wasn't our goal.

I like the idea of comments that associate with versions and can be marked as resolved. I'd like to be able to comment on a paragraph level as well as a node level but I think that's tricky to do unless you control the editing tool (keeping the comments with the right paragraph even when someone edits the original text).

Posted by: Roddy MacFarquhar at June 23, 2004 09:08 AM

Very interesting points. You touched on one issue that a lot of software users miss - data is data is data. It's how you interact with it that changes.

The one thing most blog tools are missing is the revision history that a wiki has. To handle linking between pages via a WikiLink wouldn't me too difficult, but creating the ability to track changes as they happen to provide a history would be an altogether different thing for many blogs.

It's definitely more than doable. Once the shift in paradigms is complete, I think some of the tools coming out in the next year or so will be unbelievable.

Posted by: Travis Swicegood at June 29, 2004 07:50 AM

I'm implemented a cms system with a very similar vision to what you described here: check out http://rhizome.liminalzone.org -- the info here's pretty technical and the UI is immature but the potential's there -- it has pretty everything described in the comment by Waugh except for the "extremely efficient" part.

A bit more on the vision is decribed here:

Another product that has much of these capabilities is SnipSnap.

Posted by: Adam Souzis at June 30, 2004 04:31 PM
Post a comment

Remember personal info?