When Wikis Succeed and Fail

by Tom Johnson on May 23, 2012
categories: technical-writing

I am currently at the STC Summit in Chicago. One of the reasons I love the STC Summit so much is that it feels like home. I know so many people at this conference, and it's great to chat with them. People like Sarah Maddox, Ellis Pratt, Janet Swisher, Arnold Burian, Matt Pierce, Todd Deluca, Mark Lewis, Kirsty Taylor, Joe Gollner, Gina Wadley, Kai Weber, Kit Brown, Alyssa Fox, Tommy Barker, Larry Kunz, Rahel Bailie, Richard Hamilton, and many more.

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.

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 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.

Taking a break from wikis, not from collaboration

For now I'm going to take a break from wiki authoring and revert to a more traditional help authoring tool (either Author-it or Flare -- we have both). When I floated this idea to Janet Swisher, who works at Mozilla in a highly collaborative environment, she agreed that you can still collaborate with volunteers without having a wiki platform (though she was sorry to see my abandon the wiki format).

I asked Sarah Maddox, author of Confluence, Tech Comm, Chocolate, for her opinion, and she noted that maybe the lack of wiki use isn't due to a dwindling trend, but rather because wikis are an innovation not yet adopted by the majority. Certainly some organizations, like iFixit, are doing amazing things on a wiki platform. But they seem to be rare exceptions rather than trends.

Am I wrong about wikis being dead? Maybe. But collaboration and community aren't dead. And here's where I'm conflicted. All the really interesting developments on the web involve community -- Wikipedia, YouTube, Facebook, Flickr, Google, the iPhone App Store, Android Market, Amazon, Craigslist, Twitter -- the list goes on and on. The community is what drives the innovation and makes the site/platform/service interesting. When you subtract community from the equation, all of those platforms become b-o-r-i-n-g.

In fact, the web itself could be thought of as a giant wiki, with each new page on the Internet similar to a page on a wiki. The web/wiki continues to grow, morphing into a more and more intelligent body of information.

Given that community platforms are the most interesting innovations on the web, why would I want to move away from such an endeavor? Why is it that wikis don't seem to leverage community contributions in the same intelligent way? Perhaps I'm giving up too early, moving on before giving the wiki platform a full opportunity to transform into what it wants to become.

On the other hand, the wiki is not new technology. Wikis are almost as old as the Internet itself (the first wiki appeared in 1995). After 17 years, wikis have seen a lot of variation (there are about 100 different wiki platforms). But have they really caught on?

Wikis are founded on the right ideas, but ...

My suspicion is that wikis have continued as long as they have because they're founded on the right idea -- user empowerment, participation, interaction, community, knowledge evolution, and so on. But perhaps the model needs some adjustment. There may be a better way to encourage collaboration and community. I doubt that reverting to a static help authoring tool is the solution, but the collaboration model needs to evolve in a way that gets compelling results.

In Sarah Maddox's presentation on wikis at the Summit, she noted that when her Confluence team had a comments feature available on their wiki pages, they received so many comments that the pages became extremely long. They became so long, in fact, that users began to complain about the length, and so Sarah said they removed comments from pages and instead linked to forum threads where people could carry on discussions. (Sarah seemed a little conflicted about the decision to remove comments.)

It seems that a feature to show/hide the comments might have solved the length problem, or a better threaded expand/collapse widget for the conversations. But just hearing the success of the user interaction with the content was encouraging. Commenting features on pages actually work -- whether it's blogs, wikis, product reviews, or some other format. Capturing comments does harness user input, participation, interaction, and collective knowledge.

The reason users find commenting so natural and easy is because leaving a comment is natural and easy -- it's a standard convention on the web. Whereas one rarely is presented with edit options to change the actual article content, the ability to comment is ubiquitous. And it's also easy, because you can jot down your thoughts in a quick, unplanned manner and move on.

If we're going to encourage user collaboration, providing a comments feature is probably more useful than using a wiki.

Which leads me to the final advice Paul gave me. As I confessed my deliberation about platforms for help, Paul suggested that I look into using WordPress. WordPress allows users to comment below articles, giving the benefits I just described. But WordPress also gives users an edit button for those who need authoring capability. The edit button only appears for those users who are logged in with the right role.

Hmmm, WordPress. I have heard of that software once before, I think.

I probably won't be migrating to WordPress for a variety of reasons (namely, lack of an XML output that translation memory systems can parse, lack of print output, lack of content reuse, etc.), but I like the way the direction this conversation is going. We can look for collaboration in ways other than wikis.