Wikis and What to Watch For

“Yeah, we need to do a Wiki,” says the boss.

Sound familiar? Those who have been in the biz a while can remember instances where similar phrases were uttered, except instead of “Wiki” it was “website,” or “social media,” or “Sharepoint.” And way back when, you probably responded internally with the same question: “What does that really mean?”

Janet Swisher was on hand to address those very questions about Wikis with her presentation at the STC Austin program meeting, Jan. 21 at Tech Ranch. Swisher, who creates developer documentation for the Mozilla Developer Network and also documents for open source software, said Wikis can be an effective solution in a number of scenarios. Internally, a Wiki can be used to capture knowledge, manage projects, perform strategic planning, and workgroup coordination. Externally, Wikis are best known for facilitating a growing customer knowledge base, and for customer documentation.

To the last point, Swisher dismissed the fears that technical communicators have that the community -- via the Wiki or other forums -- will replace our profession. Not so, she says. Jakob Nielsen, in his book “Participation Inequality,” states that 90% of users “lurk” (a term to affectionately refer to those who read only and never contribute), 9% contribute very little, and only 1% contribute regularly. So guess who still has to write content for the Wiki and update it? “Somebody has to be that 1%,” Swisher said.

Once it has been decided (by you or for you) that your organization will develop a Wiki, Swisher pointed out several things to consider:

* Will your Wiki be printable? If so, which tool will you use? Confluence PDF Export or the MediaWiki PDF Export extension were mentioned as options.

* Who stands behind the content on your Wiki? This is particularly important if you publish warranty-type information on your Wiki. This should be locked down as read-only and not open for user contribution.

* Who owns the content? The simple and PC answer is that users own the content. Yeah, that’s nice, but what about when said user who owns certain pieces of content becomes disgruntled with your product and wants “their” content back? Not only would you have to recreate that content, but because of the somewhat unstructured architecture of this format, locating all of “their” content would be very difficult. For this reason, any Wiki site needs to have explicit and irrevocable terms and conditions for contributors.

* How will you manage varying content? In a user doc scenario, some of your users might be on version 1.0 of your product, while others are on version 2.0. How can you control this? Depending on the differences in versions, you might be able to get away with inline explanations of the differences for a while, but eventually you will need a way to cordon off content for specific users. In this instance, you would need to look at solutions that use something like a DITA-based content management system that could output to a Wiki-like format.

* How will your editorial review process work? Like any other publishing effort, your organization needs a clear understanding of how the review and approval process will work. Key things to consider here is when content will be reviewed (before or after publishing, which depends on balancing the needs of timeliness vs. accuracy) and who must review and approve it.

* Is an external Wiki even feasible for your business? Depending on what’s at stake with the proper use of your product (such as the procedure for launching a missile), you need to consider that not all documentation updates should be left in the hands of the community.

Once these issues and others are solved and the Wiki gets created, the next task will be to figure out how to get others in your organization, and perhaps the community, to become part of that “1%.”