In case I was starting to sound like a naysayer in the rush to embrace new collaborative publishing methods, I thought I’d try to be positive for a change. I am positive about these technologies.
My point has always been that doing web2.0 well requires someone driving. Call this governance or call this evangelism, but don’t overlook that it takes some work.
The difficulty with much of what is written about web2.0 publishing, especially wikis, is that it makes it look like a free lunch, but the examples of the most successful are not typical and if you want to use wiki as a publishing model you might need some extra effort to ensure that some important features are in place. What’s missing in the wiki polemics are some guides to help a specific wiki in an organisation be effective, because saying ‘if you build it they will come’ isn’t always the case. Here’s what I think a wiki owner should do:
1. Encourage good writing.
Wikis are just a publishing platform for publishing pages of content, sure it’s a different model from blogging or CMS or notepad-hand-crafted websites, but the point is to produce a page and the rules about writing well for the web still apply. Make best writing guides visible to your wiki publishers, enable a process for flagging pages that don’t meet the rules (‘this page requires a clean up’). If it’s a wiki within an organisation there may be house styles within your comms group – feature links to them prominently.
2. Empower Crowd Editing.
Look at the discussion page of any controversial subject in wikipedia, you’ll find probably 10 times more written in that section than the article itself. This is why wikipedia is a great content resource. In an organisation there might be less debate and content may not be polished by this process, but it is fundamental to the mechanism that makes wikis work.
3. Test your discoverability.
Tagging is the usual method of replacing the classic information architecture process, but it needs a large “crowd” to be effective. Get stats on the most frequently used search terms (or even better, make them public on a wiki page!) test what happens when you search for these terms, create dis-ambiguation pages or sub-index pages to make sure the people using the search find the right pages.
4. Recognise good contributors.
Wiki publishing can feel a bit anonymous, but you really want to motivate people to contribute, so let them know they are doing something worthwhile. Especially in an organisation where everyone has ‘day jobs’, spending a lot of time on the wiki might look like wasting time (it’s not of course, sharing knowledge is never a waste of time!) Rather than allowing this time wasting meme to grow and fester, have a monthly prize, or a recognition email from a senior manager, or a gold star graphic on the page… Anything that gets everyone in an organisation to understand that this behaviour (contributing to a wiki) is good.
5. Manage orphans and overlaps.
Eventually this will be crowd edited, but it can be poisonous if old (wrong) content or conflicting information gets hold before the behaviour of the crowd corrects it. Things like a review flag (“nobody has touched this for 6 months, treat the content carefully”) might help.
6. It’s a Pillar, not a Silo
You don’t want your wiki to be in a little wiki ghetto, people don’t come to the wiki because they aren’t busy doing other things, but usually because they are doing other things and need some info. Connect up your wiki with other publishing platforms and applications, match the designs of other pages and generally play nicely with the other kids in the playground, because you want them to play nicely with you.
7. Measure end-use satisfaction
I say ‘end use’ but really I mean consumers of the content. These might be contributors, but they might not be – they probably won’t be initially. Like any other type of content website your wiki will be successful if its a delivery system for useful content.
So do surveys or usability studies, ask for feedback on simple measures – can you find what you wanted, did the thing you found meet your needs? If you meet those goals, the quantity and the quality of the collaboration is improved.
Well, so that’s my opinion – any comments? Anyone want to counter this, or think that some of the above are not needed in a successful wiki? Does anyone think that most of the above happens ‘from the crowd’ automatically and doesn’t need any management?
update: Much more about wiki behaviour on this site http://www.wikipatterns.com/display/wikipatterns/But+The+Intranet