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:
- 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.
- 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.
- 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!
Subscribe to Grow Your Wiki
Related Posts:
- Web Content 2008: A Great Conference Gets Even Better
- François Nonnenmacher Continues the Milk and Wikis Theme
- Create a Participatory Knowledgebase on a Wiki
- 4 challenges to wiki adoption in organizations: #3 experience outside drives adoption inside
- Create and share flashcards with new tool from ProProfs.com
RSS Feed
Updates by Email
4 Comments, Comment or Ping
Sherif mansour
When we first introduced our Wiki, we found we were getting a lot of question on how this could possibly replace our Intranet. That was not our intention. Our intention was to solve a problem: Collaboration between teams across the enterprise.
So what we did to encourage people to still use our corporate intranet is create shortcut macros that link to some of our corporate sites. These macros allowed end-users to create content in our Wiki, and easily link to our other corporate sites. This seems to have worked quite well.
Apr 9th, 2008
John Tropea
I really like the idea of pre-publication to collaborate on something like a journal article.
Besides the collaboration you can leave comments on wikipages, have a notes wikipage, have a links and resources wikipage.
In the end it becomes a portal or scrapbook as well as the actual writing board…some wikis like PBwiki even have conferencing and forums.
I’m really thinking this is a power use case for wikis
- the only problem lies in the formatting when exporting to Word.
I wonder if you can export into a Word template.
I first cam across this pre-publication process via the connected intelligence wiki which was used to write a journal article.
http://connectedintelligence.wikispaces.com/Wiki+Co-Writing+Experiment+Results
Apr 9th, 2008
Skrocki
Stewart, this helps to offer clarity and validates Sun’s approach to leveraging wikis.sun.com. Thus far, the wiki has been very well received — especially by the folks formally on the hook for writing content.
We currently have nearly 13,000 users who have created 5,711 pages that have been revised 37,544 times — this tells us they are indeed using the wiki for iterating content as opposed to posting formal, polished, product marketing docs.
Apr 10th, 2008
Reply to “When to wiki? When not to? 4 Tips to Consider”