When are wikis ever successful?
- What went wrong with the wiki model
- Smart filtering can be your strategy against ROT
- I wrote a whole series of posts on wikis
- Upcoming roundtable discussion with North Bay Communicators group
What went wrong with the wiki model
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.
Smart filtering can be your strategy against ROT
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.
I wrote a whole series of posts on wikis
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.
Upcoming roundtable discussion with North Bay Communicators group
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.
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.