How Do Blogs and Wikis Fit Together?

Although many people put blogs and wikis in the same social media category, blogs and wikis are actually quite different. Blogs are individually authored mini-magazines or journals where one author (or sometimes a small authoring group) crank out article after article (or entry after entry) usually with a common theme. After each article is published, the article is considered done and the author moves on to newer pastures, always hunting for the next story, formulating the next insight, thinking about the next post. Readers can comment and subscribe by RSS.

Wikis, on the other hand, are a platform for groups to collaborate on an information project, such as documentation, technical specs, or other reference material (e.g., Wikipedia). One author isn’t just cranking out all the information. Multiple authors are contributing chunks and pieces, linking from one page to another, making edits on each other’s content, diving deeper where necessary, and moving toward the idea of a more complete information product. Wikis are rarely ever done. They are successful only as much as they tap into the collective intelligence of a group.

How exactly do these two formats fit together? In  [amazon-product type="text" text="Conversation and Community"]0982219113[/amazon-product], Anne Gentle says that the blog can often be a conversation starter, the medium that opens up communication among people. Your blog can attract outsiders and draw them in to participate on a wiki or other involvement.

Seeing how these two formats and activities fit together provided an Aha! type of moment for me last week. We have a community projects wiki where a lot of developers, QA engineers, and others interact on a technical level, either compiling requirements, designs, or other details about the projects they’re building. The site also has a blog component, but the blog doesn’t always address the existing projects. In fact, the blog mainly consists of random IT topics written by people in our department.

I realized (not that it’s really much of an insight) that in this situation, the blog should act as a companion to the wiki. While the wiki has project details and other specs, it’s not the motivational piece. It doesn’t build trust, inspire people to join the community, or even communicate that much to those outside of the layers of its structure. Just as a charter or project requirements documents rarely inspires anyone to volunteer for the project, the same might be said of wikis. But that’s not the wiki’s job. It’s the blog’s job. The blog serves as the human-focused news stream for sharing announcements, insights, developments, stories, and other details about the projects going on in the wiki. They’re a perfect fit, and one fuels the other.

Related Posts

8 thoughts on “How Do Blogs and Wikis Fit Together?”

  1. Scott

    Tom,

    Interesting post as always. I’m going to turn your insight in the last paragraph upside down: why not use the wiki as a companion to the blog? There are cases where a firm uses a blog to deliver task-based documentation. In that case, why not use the wiki for supplementary documentation — overview and background information, user-generated content, and the like?

    1. Tom Post author

      Scott, great comment. It seems so obvious how the two should fit together but rarely do I see them paired up as they should. Thanks for the tip.

      1. Scott

        Tom,

        The great thing about technologies like wikis and blogs is that they encourage you to use them in new, different, and downright interesting ways. And a lot of the time, you’re not trying to shoehorn content or a purpose into a medium that’s not designed for that content or purpose. Finding the limits of their flexibility is half the fun.

  2. Jasmine

    Tom

    Thanks for another great article.

    I am currently selling my communications strategy to various levels of management at my organisation (a major insurance company). At its core, my strategy is built on similar concepts. We currently have an online help manual (for legislation and operating procedures), and sharepoint(where documents go to die). Neither of these tools are used very often and the content of both is the same: a bunch of long documents dumped into poorly named folders or categories. We also have two fortnightly newsletters for staff and management, neither of which are read.

    I was asked if we could replace our help manual with sharepoint and even though I was tempted by the chance to experiment with using a wiki for help documentation, I felt that it was a poor choice for our needs, and have chosen instead to build a new online help manual using topic-based authoring. I am also implementing a new information architecture and search tool.

    My main message has been that:
    1. our online help can answer those immediate questions that staff have on how to complete a task and shouldn’t be weighed down with lengthy history lessons on previous ways of doing things or every detail of the project that delivered the new procedures
    2. Sharepoint can provide document sharing but also collaborative workspaces for projects, discussion boards for knowledge sharing, and a blog to replace our emailed newsletters (using wikis and blogs for their respective strengths as per your article)

    This has been hard to sell in an environment where information is only conceptualised as being either a word document or an excel spreadsheet. Separating news from chat, instructions, and other types of information and then explaining how they complement each other is going to be tough but very rewarding.

    As they say: horses for courses.

    Jasmine

    1. Tom Post author

      Jasmine, I tried using SharePoint as my help format once. I wrote about it in my post, “My Compromise with SharePoint: What Works and Doesn’t.” In short, if you have just one audience, don’t need to translate the document, and don’t need to print it, and you don’t need to work on documentation prior to future releases, you could use SharePoint. Strangely, in SharePoint, the blog and wiki features are more similar than other platforms. (The code behind both is somewhat problematic.)

      I also wrote about my experiment here, “A Web 2.0 Documentation Idea Gone Wrong.”. In that post, I explain the problems of having documentation in fragmented locations. Users search one source only. (SharePoint’s search, by the way, is hard to configure.)

      You’ll have to keep me updated on what you do. Some solutions actually use SharePoint as a content repository (can’t remember their names at the moment — maybe DITA Studio from In.vision?). Anyway, it’s a frequent question that comes up, because SharePoint is so common in corporate environments. Let me know what you finally decide to do. I’m a big fan of centralizing documentation. Also, if your users prefer that and want to collaborate, why not?

  3. Anne Gentle

    Great post and ensuing discussion! One aspect of wikis and blogs that can be crucial difference between the two is the subscription mechanisms available.

    I see more examples of a blog set up specifically for release notes, which makes sense when you look at it from a subscriber standpoint. Subscribers want to be notified when updates happen. For wikis, there are so many subscriptions you can set up (recent changes, page level notifications, added users/contributors, and so on), which is ultimately flexible but not as crucial to many readers. Certainly those subscriptions are crucial when you are a contributor though. Just wanted to point out that another consideration when choosing the right match is the subscription opportunities that you can offer from either a blog or a wiki.

    Both blogs and wikis are sometimes treated as web content management systems, so certain features of the engine itself might influence you in one direction or another. Scott has also nailed it – the contributors and strongly-typed content may also push you more towards one than the other.

    1. Tom Post author

      Anne, thanks for pointing out the differences with subscription mechanisms. I hadn’t thought of that, but you’re right. Tons of differences there. And both being CMS platforms on the web is another good point for why they’re combined.

      I have to admit, when I think of wikis, I feel about the same as I did with group projects in high school and college. I always hated working in groups for all the typical reasons — I like to do things my way, some people in the group never contribute, it ends up being more like babysitting, etc. On the other hand, if you work with a strong group of smart people, the effect can be the opposite. Very edifying and encouraging.

      I look forward to seeing you in Austin in October.

Comments are closed.