When to wiki? When not to? 4 Tips to Consider

Linda Skrocki recently asked When to wiki? on her blog:

In the wiki arena, one of those grey areas is when should a wiki be used vs a traditional corporate webpage? Certainly, the two should compliment & not compete with each other. A good wiki will “…appeal to a niche that isn’t entirely satisfied elsewhere” (via How to make a successful wiki).

We chatted on Twitter about the post, and Linda asked what other pointers I could share on the wiki vs. traditional website content question.

Here are four:

Complement; don’t replace

When a new tool like a wiki comes along, the early adopter excitement surrounding it can scare other people into thinking it will completely replace what they’re used to using.

Do everything in your power to stop this from happening. Seriously. Those of use who are introducing the newest technology in organizations have to make sure people feel at ease about it, or they will resist trying it.

Be very clear that the wiki isn’t here to replace the website.

Website: Good for basic information, introducing people to your product or service, explaining how to try or buy it, etc.

Wiki: Good for sharing additional information people likely need after they buy your product or service, building a community where customers & clients can share their experiences & tips, support each other (which lowers your support burden by resolving small issues faster), and getting feedback .

Flow vs. Finished

In the realities of the business world, there are plenty of finished documents that need to be made available as finished, polished products. Product brochures (PDF), White Papers (PDF), and Data Sheets (PDF) are three examples – you want to pass along certain information in these documents that needs to stay stable. I would advocate using a wiki internally to produce the content of these documents – it makes information gathering and document assembly much easier for a team. But when it’s time to make these available to customers, analysts, the media, etc., they should be posted in the traditional manner as static content.

The sum is greater than the parts

A smart thing to do when you make information public is to set up a public wiki alongside the traditional website, much like Sun has done with the CMT wiki for its new chip multithreading technology. This way, people who want to interact with others who are using a product, get additional information, or share tips, experiences, applications, issues, etc. can do so, and people who want the basic product information (often when they’re researching what to buy) can get that from the static website.

Wiki can be both a wiki and a website

Keep in mind that this is a more advanced one, and I wouldn’t advise organizations who are new to wiki use to do this, but it’s something to consider.

Some organizations choose to “skin” their wiki, or apply a visual theme that makes it look more like a traditional website – CustomWare is a good example.

There are three benefits to this:

1. Best of both worlds – public visitors see the polished, familiar look of a website, and employees have the simplicity and ease-of-use of the wiki to keep the site up to date.
2. Part website; part wiki – enterprise-grade wikis can contain multiple different “spaces”, so the public, skinned, website can be in one space, and other spaces can contain actual wikis for the uses described above – customer interaction, community-building, information sharing, etc.
3. Lower cost – Hosting your public website and wikis on the same platform costs less than buying wiki software for the wikis, and a content management system for the website.

So there you have it. What are your suggestions for ensuring productive coexistence between wikis and websites? Share them in the comments!