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.
As Avi, our experience with wikis has been quite different from yours. We have page owners, indexes ("navs"), name spaces, procedures for adding pages, etc. Just a little structure, so little that it is not even noticeable to the average user, goes a long way towards going from a dumpyard to a library.
Hi Tom,
For one answer to your question, see Nitza Hauser's talk at LavaCon this year on implementing Every Page is Page One in a wiki: http://lavacon.org/2015/spe....
But let me ask if this is a fair restatement of your question: "Is ungoverned distributed authoring every successful?" Ownership and maintenance issues are symptoms of an ungoverned distributed process, not specifically of wiki technology. One could ask similar questions about the Github distributed authoring model.
The real challenge for any kind of distributed process seems to be to find a model that is governed but not directed. (It the process is under central direction, it is not longer distributed in a useful sense.) In other words, the challenge is to come up with an effective bottom-up governance model.
That can be difficult in a traditional corporate environment, but content creation is not the only field struggling with it. One of the ongoing issues with implementing agile is just this: how to balance co-ordination of the development effort with the autonomy of each developer.
The issue is serious, because directed development takes a lot of creative power and intelligence offline. The point of a distributed process is to allow individual contributors to make full use of their creativity and intelligence, while still contributing effectively to the good of the whole project.
That is seriously not easy, and it tends to require architectural changes as well as culture changes. Loose coupling is key, and that requires high cohesion in the individual pieces. For a wiki, that means people need to learn to write in an Every Page is Page One fashion.
When are wikis ever successful? When they implement Every Page is Page One information design and implement a workable distributed governance model.
Could a more structured approach help with the governance, and with maintaining the EPPO model? Absolutely it could.
My experience shows the exact opposite. In several organizations that implement wiki as a key tool of communication, each page has an owner. The page is open to the general public and everyone is welcome to contribute. However, we always get back to the owner and hold the owner accountable for the completeness and accuracy of the content.
As a side note, I wanted to implement a wiki back in 2005, and was refuse because I did not know how to resolve the ownership issue.