Wiki or Blog? by Ron Lichty

What are wikis good for?

Knowledge collection.
Collaborative documentation.
Brainstorming across geos and timezones.

How is that different from a blog?

Blogs are good for single-author (or at least single-author-at-a-time) point-in-time reports, comments, personal insights, and so on. Most blogs are set up for readers to leave comments. But they can't edit the author's commentary. And they can't start new blog items. Only the owner can do that.

On a wiki, everyone can edit. Ownership is pretty much shared.

Let's take this Architecting Community and Collaboration Solutions event that's coming up Wednesday night. I'm going to be sorta busy on event night, but nonetheless I'm hoping, once I've introduced the panel, to sit in the front row, flip open my laptop, and write a few notes. I'm hoping a few other people will do that, too.

And where will I post my event notes?

Here on this blog.

And other people will put their notes on their blogs. (And they'll probably leave comments to my blog entry pointing to their blog entries, so someone who wasn't able to attend the event can click around and read all the commentaries.

On the other hand, if a group of us wanted to create a single document representing our combined notes, thoughts and comments, we'd start a wiki. If none of us had access to a wiki server via our organizations, we might go to a free, password-protected wiki provider like PBwiki (the PB stands for "peanut butter", which using it seems as smooth as, or something like that). It takes about a minute to create a wiki (maybe two your first time, but it's just a matter of naming it), PBwiki emails you the password and URL for your wiki, you use it to log on, you click "change password", they send you a second email with a unique URL to a new page set up just for you to change the gnarly password to something you think your team can remember. Total: about 3 minutes. You get on the wiki yourself to add your own notes to start the collaboration off. You might add them to the home page, or create another page; you do that by clicking 'edit' and entering a "word" with a capital in the middle, like EventNotes. When you click 'update', EventNotes is highlighted like a URL (because it is a URL); click on it and you're on the new page; click 'edit' on that page and you can add your notes and click 'update'. Another two minutes. Then you send the wiki URL and the password to your team to they can interweave their notes with yours (and edit, correct, and improve your notes as well, by the way). If I'm not mistaken, you can track which teammate made which additions and changes; that's certainly true of many wikis.

My co-chairs and organizational sponsors and I have just used a wiki to share writing of the description of an event we're planning, SDForum's Web Architecture Summit Sept. 14. We're collaborating on the agenda on another page of our wiki. And we're sharing writing chores for panel descriptions, and brainstorming panel members. It's useful.

I have a programming team at Avenue A | Razorfish in San Francisco that inherited tens of thousands of undocumented lines of client code. Every time any of them meet to discuss the project, they pull up the wiki where they've been slowly assembling their discoveries over the past two years into documentation.

I don't have any personal big-ROI stories to tell about wikis, but they've sure been useful to us over the past few months!