Krzysztof Kowalczyk makes an argument for bundling a wiki with a blog. I agree wholeheartedly with his endorsement of wikis. I've used a few, and installed two of them myself, and I think they're terrific. But I don't think that wikis should be bundled with blogs (especially WordPress) by default.
First, blogs and wikis serve different puposes. Wikis can be used as a publication engine -- see the Wikipedia as a perfect example -- but the kind of thing you'd publish on a wiki is fundamentally different from the kind of thing you'd post on a blog. The power of wikis is the interconnectedness of all the data: you're only one click away from any other page on the wiki. That's why a wiki makes perfect sense for an encyclopedia, or a knowledge base, or random notes collections. Blogs have a certain interconnected-ness, what with trackbacks and pingbacks, but blogs impose more continuity ... my comments here will be linked to Krzysztof's site; but if someone else blogs their response to my comments, the connection won't be passed on to Krysztof automatically (unless the blogger specifically elects to trackback or pingback him as well as me). If someone uses my comment form below to comment directly on this post, Krysztof will never know unless he comes to visit. Blogs have a linearity to them that wikis don't.
Second, blogs have an implicit power structure that results from the limited selection of authors. A blogger chooses who posts top-level entries to his blog, restricting everyone else to mere "commenter" status. Commenters rarely get the ability to edit their comments; the blog administrator(s) have the sole power to edit or remove comments. The power structure ensures that a blog's readers are always in the position of respondent, and never initiator. In order to initiate, one must control their own blog. Wikis are completely different, though, because (usually) anyone can post and edit. Wikis level the playing field a bit, because any visitor can create new directions for participation. Visitors can correct their own comments, as well as correct the comments of others. Instead of one-to-many communication from a blog, wikis support many-to-many communication, where all participants are authors, editors, and readers. Although the wiki administrator still has absolute power, and wikis can be configured to restrict who can post, constraining wiki operation in this way vastly limits the utility of the software. If you're denying wiki features to people, why use a wiki at all?
Third, wikis lack much of the distribution conveniences of blogs: syndication feeds, trackbacks, and pingbacks. To really use a wiki, participants need to go to the wiki. A blogger can read aggregated blog entries in a feed reader, then post replies to an entry on her blog and alert the source that she's responding (trackback or pingback) without ever visiting the source blog. Blogs allow conversations to be carried out while maximizing each participant's convenience because blogs are predominantly one-to-many publications. Blogging in aggregate approaches many-to-many communication, but there's a lot more infrastructure involved to support that. Wikis gracefully support many-to-many communication by constraining the necessary infrastructure: the wiki is the hub through which all conversations are routed.
Integrating blogs and wikis probably doesn't have much appeal to too many people, since blogs and wikis really serve different purposes. The kind of people who want to use a wiki will largely be able to do so (or figure it out) for themselves. Integrating wikis within a blog package unnecessarily complicates the core package, increases support requirements from the development team, and may possibly bloat the package with features that people don't use.
(hat tip: Blogging Pro)
I've got a blog. My wife has a blog. My friends have blogs. We all have email. Some of us use instant messaging. But each one of these mechanisms requires the use of a discrete program, which uses its own protocols and conventions. At least with email there's some standardization, but the blog-commenting business is totally out of control. Some blogs have comments, some don't. Some blogs want people to comment, but only if that comment is coming from the commenter's own blog -- a thing called trackbacks.
Trackbacks are one way for people to link blog-based discussions together. When I "trackback" someone, I'm telling their blog software that I wrote something about an item on that blog, and it should create a link to me so that their visitors can follow along at my blog. Got that? Then there's pingbacks, which are kind of like trackbacks, but sufficiently different (and of course completely incompatible). As I tried to explain it recently: "Pingbacks sound like they're for creating reciprocal links, while trackbacks are more of a limited content distribution deal."
In the same conversation that I made the comment above, I also said "I'm frankly disgusted that we have so many discrete tools for communicating, and each is functionally incompatible with the other." I'm not the only one thinking about ways to better integrate all of these communication mechanisms. There's a whole new language for the internet -- s'cuse me, the Semantic Web -- that is attempting to deal with this stuff.
I'm not a luminary in the blogsphere, but I think I've got something to contribute to this whole discussion.
What I want is to lower the barrier to participation in online conversation. I have a blog (a forum, actually, that I'm using to blog), and I have an email account. Why must the two be seperate? Why can't people use whatever tool they want to participate in the conversations they find stimulating or valuable? Why do we need to juggle two pieces of software and have seperate, discontiguous conversations?
I would like for people to be able to subscribe to various topics such that new posts are sent to their email address. My big beef with blogging is that it's a "pull" process for the end-users: they need to visit a site to determine if new content is available. RSS synidcation is one way to make life easier for the reader, with the aide of an RSS aggregator; but that's still only one-way: from me to the reader. If the reader wants to comment, they need to fire up their email client to shoot me an email, or fire up their web browser and navigate to my site to post a comment (or their own site to post a comment, and then trackback to mine). Too much work! I want people to be able to email their comments to me, and have my software automatically integrate their voice into the conversation at the proper place. Further, I want my software to allow people to participate with whatever tool they want -- or are required -- to use. If they normally use their email client, they should still be able to participate through their web browser by posting directly. And my software needs to be smart enough to keep track of which conversations they've looked at while visiting and refrain from emailing those to them -- no sense sending the reader an email full of content they've already seen (unless of course they specifically enable that kind of duplication, so my software needs to pay attention to that, too!)
The problem I have with trackbacks is that it breaks archiving. When I link to a trackbacked item, I'm not (usually) retaining any of that content -- I'm only keeping the link to that content. So if the trackbacked item's author changes the content -- or removes it entirely -- there's a gap in the record of our conversation. Yes, this same argument applies to my forum software's permission to edit and delete posts. With my forum though, or any locally-controlled repository / archive of content, I can take point-in-time snapshots and back those up. So if someone edits their post, I could post their original so that the conversation is "preserved".
The problem with maintaining local copies of all these trackbacked items, or having a catholic archive of content, is that it makes it hard for people to correct themselves. One of the greatest advantages of the published interent is the ease with which one can clarify or remedy miscommunications by editing the content. It's not always pracitcal or adviseable to make a new entry for clarification purposes. Further, if everyone keeps their own local copy of the conversation, we have a lot of duplicated content! Sure, disk space is cheap, but there ought to be a more elegant solution. Obviously, it's this issue that trackbacks attempt to address.
So I've got some hacking to do. Who wants to help?
home / contact / flickr / github / keybase / linkedin / twitter
The contents of skippy are licensed under a Creative Commons Attribution 4.0 International License.