Differences between blogs and wikis, and why you might need both
At work I have often grumbled about the fact that we have both a blog and a wiki, and that content shared between them sometimes seems redundant and unnecessary. However, I have since come to realize how well blogs and wikis fit together. I think it makes sense to have both -- at least in my authoring scenario.
In short, wikis are suited for information that doesn't expire in a short time, while blogs are better for short-lived news. The wiki is perfect as an ongoing encyclopedia of information that accrues in a larger and more useful, interconnected, comprehensive way. The information in a wiki is meant as standalone, long-term informative articles. You might expect to browse a wiki's contents without regards to the dates each article was published. Of course there will be exceptions. All information has some time variable to it and will become dated -- but not like information on a blog.
Blog posts are intended for more timely news. Although I cringe to write this, I know that as soon as blog posts slide off the homepage, they pretty much slide into the trash can. People are more likely to read old blog posts as they are likely to check out old newspapers from a library. Blog readers thrive on reading what's new. They love to consume information that is of the moment, just published. Information that's even a couple weeks old feels stale, as far as blogs go. Readers check out old blog posts only when they arrive at them through searches, if they are researching a topic.
Here's an example of how blogs and wikis complement each other. Let's say you have an upcoming release for a software application. You prepare informative release notes. Put the release notes on the wiki, since the release notes will be helpful to users for months to come (depending on the frequency of your releases). But since people don't generally review the list of most recent changes to the wiki, you also post a note on your company blog about the new software update. The blog post is brief -- just a summary or extract of the information contained in the wiki page.
Here's a real example: LDS Maps release notes contains about a thousand words detailing what's new in the application. But the blog post, LDS Maps version 3.0 released, contains only the first paragraph of the wiki article release notes, and a list of the new features. The blog post lets readers know there's new information; the wiki provides the substance. Without the blog, you wouldn't have a news mechanism for publicizing the information of the wiki. Without the wiki, you wouldn't have a permanent source to store the product information.
About Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.
I think the admin of this web site is in fact working hard in support of his
web site, since here every material is quality based material.
@DiSc,
are you part of the Dutch Atlassian user group? If not, it's a good group to join.
I'm based in Oosterhout, near Breda. Maybe we should get together sometime and compare Confluence notes. I'm happy to come up to Amsterdam. :)
Cheers.
Hi Mick,
No, I am not part of the Atlassian user group. As much as I would like to participate in professional activities more, two little kids, a wife, sleeping and being at the office use up all my time.
And I am afraid I do not have many Confluence notes to share: we got an onDemand installation only a couple of months ago and, as I wrote above, it is barely used. The Documentation user space right now says "Hello World!".
I would like to meet up sometimes though. It is always fun to meet other tech writers, especially other expats. And I see we are both ISTC members!
Should I ping you on LinkedIn?
DiSc
Yes, good idea. The UG meetings take place in the day, ie, office time. I enjoy the day out! :)
We're working on something similar, the goal being to add a blog to our wiki-based Knowledge Center. I'm using a blog template that I can plug into my doc system (I'm using Mindtouch TCS, which is based on dekiwiki), so it's certainly worthwhile to see if something similar exists for mediawiki. Of course, I moved away from mediawiki because I couldn't find extensions that I needed, so I wish you the best of luck!
And after that, we want to step in take over the monthly new features webinars, and tie all of those together.
Doesn't having both a wiki and a blog increase information flows beyond an organization resources?
I mean, most companies are not really interested in documentation and many writers work alone. They already have plenty to do if they just "broadcast" information with little or no feedback.
Doesn't shutting the documentation door wide open create too much feedback for writers to handle? And I mean, wikis and blogs are networks, where relationships can increase exponentially, in potence.
Sure it is nice to have a conversation with your readers, but how much of that conversation can a company really afford to have?
DiSc
In my experience, it's much better to keep that door "shut wide open," as you put it. Career-wise, I've been in trouble when the doc team wasn't visible (pushed off in a corner somewhere), because it's bad when people making decisions don't appreciate the value of documentation and don't really understand what you do. It's more work, but engaging with your audience (both internal and external) is key to long term success.
Well, I do not know. It is probably because I work for a fairly small company, all relevant people are within a 25 meter range and our customers are few (but large), so using wikis and blogs to have "conversations" with them does not feel quite right.
I have been thinking about this for a while, and while I would like to add some "social" features to our old-school web help, like the possibility of posting comments and adding tags, I think leaving the trusted DocBook for a wiki + blog is a bridge too far. Note that I really like Confluence, for what it is worth.
Anyway, I frankly cannot picture myself going to my boss and saying: look, I need a few hundred (thousand?) euros a year for a wiki/blog.
Learning how to use it and installing it will take about 40 hours of my and my colleague's time. There is no guarantee it will do what we want it to.
After that, I will need a few dozens hours from Marketing, Consultancy, Infrastructure and yourself to figure out how to use the sofware to fit the organization goals. Or rather, to adjust the organization goals to the software.
Having "conversations" with end-users will take up a lot of my time, so expect to be hiring at least another person in the foreseeable future.
And yes, it can break, it can get out of control, we might end up writing things that hurt the company somehow (for example Marketing cannot constantly look at what I am writing, I cannot always know what they have promised the customer).
About the visibility thing: we do testers workk, we disseminate knowledge internally, we help out Customer Support, UX, we report bugs...
I do not think spending a lot of company time and energy on something of, for now, dubious use will increase visibility in a desirable way.
DiSc
For a year, I was the only tech writer in for a 150-200 person company. I recently hired a second writer, so I think our situations are somewhat similar.
The company had some documentation on a couple of mediawiki servers when I arrived. I updated those for a while, but then moved everything to a hosted wiki (Mindtouch TCS), which moved all of the setup and maintenance out of my hands (and our IT department, although it was mostly my responsibility).
Our product is completely web-based, so we don't need to deliver a set of PDFs with each release, and it makes sense to rely on online help in some form.
We're getting good usage numbers, but I only wish I had a problem keeping up with customer comments! I might get one a week, for a help system with about 1200 topics. Some comments point missing information, ask for more examples, or are annoyingly cryptic ("This topic needs more information"). I fix what I can, and although that does take a portion of my time, it's not excessive, and these comments are (usually) helping me learn what our customers want to know.
Because I went with a hosted system, the learning curve was small. Having a WYSIWYG editor also helps when I ask other people to contribute to the docs (product managers, professional services, and customer support agents have all created topics).
My conversations with Marketing came down to what colors and logos to use for the site. But Marketing doesn't drive our product or documentation development, so that sounds like the big difference between our situations.
Obviously, I'm in favor of this solution because it has worked for me. I need a documentation system that allows for people outside of the Docs department to be able to contribute. The annual cost makes sense, because I'm not paying for a suite of doc tools for these contributors (or training them to use those complex authoring tools). Mindtouch also integrates with our support system (Zendesk), so our Customer Support team can search the docs while they're answering tickets, and pull that information into their responses to customers.
(I haven't used Confluence, but I've heard good things about it; it just didn't fit our needs quite as well.)
Neal,
Thank you for your comment, lots of information there. From what you write I can see the value of wikis as authoring tools (no need to build the docs), while the value as a user platform seems more limited.
I can relate to that: we use Confluence internally on a limited scale. Developers write documents and use cases, and we fish content from there for the documentation. But collaboration is really limited: one person writes the document. That is it. If someone has comments, he usually speaks to the author, who then changes the document.
I think it has to do with the small size of the company: it is easier to just step by and discuss things. But then again: we are based in Amsterdam and have some colleagues in the United States, who could maybe benefit from online collaboration, but they do not use the wiki at all.
Even the wiki articles that do get written are often token efforts to please management, they are rarely kept up to date, they are rarely complete.
And when people will start using the wiki, I am afraid it will degenerate into an unstructured mess. At a certain point, I think the signal-to-noise ratio will not be worth it anymore.
So, as much as I am a fan of Confluence (and Dokuwiki) as an authoring tool, I am not so sure about its value as a real collaboration platform. I am probably afraid of getting my feet wet with social tools, so I am going to first introduce "lesser" social features, like comments and tags, and take it up from there.
Comments - A Quick Guide to not being Overwhelmed...
yes, that's my experience too, few and far between but always helpful. How do you incentivise people to use them?
How about the page rating system? I found that almost no one used it. One of the downsides to using a wiki is that the people using it have to be almost as engaged with it as those like us who user it all day long and are responsible for it's design and implementation. Which isn't going to happen...
But one day they will be! :)
Tom,
Thanks for your article, you've given me an idea about how to get updates out to clients without making a song and dance about it. And I can do the same thing for internal use too, assuming there's a need.
My idea is to create a blog in the user information area of our wiki, and just update it every morning with things that I've done the precious day - things that are useful to clients. I could also mention things I'm thinking about doing and see if any get a reaction.
Nice, I'm going to think about how this might work (mainly from a functional/set up POV) and then go right ahead and do it without seeking permission from anyone else.
Cheers! :)
PS, I agree with your definition about blogs being short-lived while wikis are forever. And that yesterday's blog is soon forgotten.
Actually what I did was to use one of the built-in macros that shows the last 15 updates for the space it's added to, then put that in a box with some text explaining the data the macro calls.
It looks very good and I don't have to do anything more as he data is refreshed whenever the page is opened or you press F5. The data names the edited page, who did the edit and when, and has a link to a page that shows you what was edited. Gotta love those Atlassian macros. :)
I totally agree on your recommended split. In many cases, something shorter than a full blog entry does the job in terms of alerting users about new content on the wiki that may be of interest. If we could use Twitter, I'd use that. We can't, but we have Jive, which is like Facebook for the enterprise. It's easy enough to post a status update on a new wiki topic, or write a bit more of a blog post for a new feature.
The comment about Tiki (evidently used by the STC's Tech Editor SIG) was of particular interest to me because it — in part — addresses an issue that's arisen lately.
That is, Wikis seem to break the single-sourcing workflow. IF one needs to develop a body of structured non-Wiki content for documentation purposes, AND one also wants to make some content available on a Wiki, THEN how can content be shared between the two dissimilar formats?
Because there is no standard "Wiki language", any interchange process would presumably need to speak one or more Wiki dialects. But in addition to exchanging information, there's the problem of addressing: How can content be directed to or requested from a specific part of a Wiki?
It appears, based on my initial and so far superficial investigation, that there's no clean solution to the issue of having both structured documentation content and unstructured (or at less generally structurable) Wiki content.
Any ideas?
Riley, you're right about there being no conversation between the two things. I'd suggest having a wiki you can blog from. And you can do that in Confluence.
You can also nick content from one page and add it to another using 'excerpts', and you can use page includes to use whole pages on another page using a similar macro. Is that the sort of thing you meant?
Cheers.
Thank you Tom for posting this thread. It has been a hobby horse of mine that long term content gets put on a blog and then cannot be found by those needing it. What a waste of effort.
I'll bet people would change if they were paid $1 for every time content got viewed.
I work in an open organization where lots of people blog about their work. My frustration is with people who blog information that is is not particularly time-sensitive, which really would live better on a wiki. On a blog, as you say, it slides off the home page into the trash, and even if it's found through search, the information rots as the rest of the world changes. If it were on a wiki, the author and others could keep it up to date and relevant.
So I follow as many coworkers' blogs as possible (we have a feed aggregator, which has its pros and cons), and ping them to say "Great article! Would you mind putting it on the wiki?"
Sounds like what you really need is a better tool -- a CMS that allows you do present the content any way you want (instead of forcing you to use Mediawiki for your wiki http://tech.lds.org/wiki/LD... and Joomla for your blog http://tech.lds.org/blog/47...).
Here's another real example:
The STC Technical Editing SIG (http://www.stc-techedit.org) uses a single CMS (Tiki) that allows
- The home page to appear "blogish" (chronologically listed items that publish/expire based on dates)
- Us to easily reuse any content anywhere on the site -- with no redundancy -- because everything is wiki
- Authors to have a single user interface for entering content
- Visitors to have a single user interface for browsing the site (this is especially important for having a unified search mechanism
Sometimes, "all in one" is better than "best of breed"
Rick, I think you're right. I will look to see if there are blog extensions for mediawiki (the wiki we use). Having multiple systems for the content isn't really ideal at all.