--- title: "When Wikis Succeed and Fail" date: 2012-05-23 description: "$( document ).ready(function() { // Handler for .ready() called. $(" canonical_url: https://idratherbewriting.com/2012/05/23/wikis-are-dead-other-options-for-collaboration/ --- # When Wikis Succeed and Fail Although many of us may have different job titles, most attendees strongly identify as technical writers of one sort or another. This common ground binds us together and gives us a lot to talk about (in ways that the Confab crowd lacks because their roles are more diverse). ## Why just one session on wikis? Because I helped review Summit proposals, I stood for a couple of hours at the registration booth to answer questions. Few people actually come up to the booth, but during this time I had the chance to talk with Paul Mueller, the program advisory committee conference chair. (By the way, if I'm ever talking to you and you don't want me to ever blog our conversation, you need to let me know.) I asked Paul why there was only one session on wikis this year, compared to numerous sessions in years past. Paul has worked a lot with wikis. As a consultant for WebWorks, which Alan Porter once noted was a wiki-driven company, Paul has a lot of insight and experience with wikis. Wikis are an outdated technology, Paul said. Paul noted that in some situations, wikis make sense. When you have a group of people who are expected to collaborate, wikis work well. And internally, wikis are still popular because they provide easy collaboration for employees. In fact, Paul noted that the STC Summit committee uses a wiki to collaborate. So wikis still have a place and purpose. But if you just have documentation geared *toward end-users who are not expected to collaborate or contribute*, wikis aren't the right tool. ![When you need a wiki, and when you don't](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/collaboration_on_wikis1.png) Paul's explanation made a lot of sense to me. Wikis that are working well in companies are wikis intended for developer-author communities or wikis where many technical authors are collaborating on the same platform. For more common help authoring situations, when you have tech writing teams creating help for end-users, wikis aren't needed. In fact, Paul said that when WebWorks switched their end-user documentation away from wikis toward Reverb, a more online friendly format, user satisfaction shot way up. ## End-user experiences with wikis I know that I have written a lot about wikis on my blog. Wikis have many compelling elements that make them ideal in some ways. Wikis are web-based, fit well with agile software methodology, allow information to continually evolve, enable easy collaboration among authors, empower users to participate in documentation, make it easy to update documentation on the fly, and more. However, unless you're writing in an environment where many users are expected to contribute, giving people options to edit the content often just confuses them. For example, I recently received an e-mail from a concerned user yesterday who thought there was a security vulnerability because he could edit page content. Another user recently asked how we establish whether documentation is authoritative given that anyone can edit it. Many other users make edits to the pages that show they have no idea what they're doing, such as noting bugs or glitches right in product descriptions (rather than in forums or discussion boards), and more. I like the idea that documentation is never finished but always keeps evolving to a more complete, accurate state. While this idea of information evolution, which underlies the philosophy of wikis, has conceptual appeal, it turns into a kind of never-ending babysitting of documentation. ## Instead of wikis, multi-device authoring Rather than focusing on collaboration, it seems the trend now is to output to or adapt content for multiple devices. The ability to adapt content for mobile, tablet, and other devices seems to occupy the most attention right now, and only becomes more of a priority as devices proliferate. I actually won a Kindle Fire from [Writing Assistance](http://www.writingassist.com/newsroom/) at the Summit, so now I'm carrying a laptop, iPhone, and tablet device with me, making the need information for to be compatible across devices ever more apparent. It's hard for me to admit this, but I think wikis are kind of dead as a platform for non-collaborating end-users -- even if you use the wiki *hoping* that the users will begin collaborating. Unless you work in a highly collaborative environment, where lots of different people are *expected* to write on a collective canvas, don't use a wiki. Instead, use a help authoring tool, if you're a lone author, or a content management solution, if you have enterprise-level needs. I say this even though I literally have more than 100 volunteers in my community who are eager to help me with writing tasks. Even in such an environment, wikis aren't necessarily the right tool. Volunteers are much more comfortable writing in Microsoft Word and sharing files through Dropbox or JIRA. It's hard enough to get people to write at all; teaching them wiki syntax and asking them to publish is another step that many writers are uncomfortable with. Most volunteers want you to edit and review their writing before it gets published anyway. Additionally, if you do have an online community, engaging volunteers *to write* isn't always the best strategy, since so few people can actually write professionally. It's often better to engage volunteers in other tasks, such as verifying the accuracy of instructions, doing usability testing, tagging content, doing research, sorting metrics, highlighting trends in feedback, and so on. You don't need a wiki for these collaborative tasks.