The other day I had an email exchange with someone about wikis and scenarios where wikis might work well. I haven’t talked much about wikis on my blog lately. But a few years ago, when I working in Utah in a community environment with a lot of contributors, I did use Mediawiki for a couple of years. In some ways the wiki worked well, and in other ways it did not.
The main problem was that wikis allow anyone to contribute junk content with no responsibility to maintain it. As a result, wikis quickly turn into content dumpyards (full of redundant, outdated, trivial content, or ROT), and it’s tough for a content overseer to care for the content when it’s not clear who authored what, when, for what purpose, how long ago, whether it’s still needed, by whom, and who might be the point of contact.
At the start, wikis seem ideal because they remove the publishing barrier and allow everyone to contribute. The problems don’t crop up until the wiki is full of junk and no one can find anything. At that time, someone decides to put a content steward in charge of the wiki, but there are already so many pages to sort through, the content steward basically has to start under a mountain of junk. It’s too suffocating to make any progress.
When I worked on the wiki at my former company, there were 1000+ pages that I couldn’t account for. I just ignored them.
One basic strategy, according to Mark Baker, is that the Internet works this way (it’s full of junk content), so don’t worry about it — instead focus on refining your filtering mechanisms. Case in point, Google smartly filters up only the most relevant and informative content. The others it buries deep in the page results. So what if there are 1,000+ pages of junk on your wiki. Theoretically, a smart filter will only surface what you need.
Splunk is one company that is probably doing wikis well, and if you have a distributed authoring use case, there’s nothing that really replaces wikis. Splunk even forked Mediawiki into their own tool (called Ponydocs).
Overall, though, I think wikis have seen their day and other models are being implemented.
A few years ago I wrote a series of posts describing my journey to and from wikis. You can read it here: My Journey To and From Wikis: Why I Adopted Wikis, Why I Veered Away, and a New Model.
I noted that I could probably offer some strategies about how a wiki might be run successfully, but ultimately I haven’t had what I feel to be a really successful wiki experience. As a writer who enjoys tight control over the content I create, I like having ownership and responsibility for the content. Sometimes when a community member would make edits, I’d want to rewrite it or remove it — but doing so discourages contributions.
Anyway, this conversation led to my upcoming participation in a roundtable with the North Bay Communicators group. The title of the evnet is API/Software Authoring Environments. Here’s the description:
Join us Tuesday, August 11, 2015 in Petaluma at 6pm for a round table discussion on API/software authoring environments. Topics may include discussions around the effective use of lightweight environments such as Google Docs and Wikis, or how (or if) certain authoring environments are more suited to specific types of APIs.
Anne Gentle (www.justwriteclick.com / @annegentle) and Tom Johnson (www.idratherbewriting.com / @tomjohnson) have agreed to join in remotely to offer their perspectives and experience, but this is a round table, so we look forward to input from all!
If you can’t make it to Petaluma, you can join a Gotomeeting (I’m not sure what their limit is…). At some point, the discussion about wikis took on an API documentation dimension, which actually does fit quite nicely, since you usually empower engineers to contribute in developer documentation environments.
If you’re interested in learning more, add the event to your calendar and join us.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.