Main Page Content
When Wikis Go Bad
Over the last few years the use of wikis has become really popular. For every wiki evangelist I have met, I have also come across as many who hate wikis. I’ve used them extensively and I too have gone through a love-hate relationship with the wiki. I’ve probably used wikis for most of the common applications: href="http://wiki.evolt.org/wiki/Main_Page">evolt.org wiki, I decided to write down some of my thoughts about why sometimes wikis are phenomenally successful, and others just never seem to work. Like a lot of similar issues, none of this is rocket science. (This is not meant to be a history of the wiki; if you want to know more about wikis go to the Wikipedia article.)
- Project management
- Documentation and knowledge bases
- News letters
- Community portals
Where can a wiki go wrong?
The answer to the above question is in lots of ways! I’ve categorised these as:- Content
- Complexity
- Community
- Corporate
Nonexistent or inappropriate content
For a wiki to be successful, like any other website, it needs content. Not just any old content, but content appropriate to the aims of that particular wiki. I’ve seen bare bones wikis chucked over the wall at a group people who have been told to use it and who, unsurprisingly, have ignored it. My approach is to spend a little time in putting some outline structure on the initial wiki and add some sample documents so that users understand how it should be used. An example is a professional community portal wiki where I was a user. The aim of the portal was as a reference site to assist with professional and career development within this particular company’s organisation. The idea being that it would promote a sense of community and users would be able to look at job vacancies, find out about training courses, and ask questions in various forums. It didn’t work. Once you got past the fancy front page, many of the links lead to pages that wereunder construction, or held out of date, and even incorrect information. Initially, there were a few comments added to a few pages, but these rapidly became
Hello, is anybody there ?Sometimes wikis are wildly successful, with lots of content, and then suddenly the usage drops. Often the cause of this is that there is just so much content, and so many links and pages, that the information you want can’t be found. OK, there are search engines in the wiki, but these often aren’t sophisticated enough to be of much use. Now, all of the above is not unique to wikis, but just as applicable to any website. The trouble is that people have been told that this fantastic wiki thing will solve all their problems, and when it doesn’t deliver, it’s that wiki that gets blamed.
Too much complexity
A wiki should be simple to use and navigate, and should grow organically. Most of the successful wikis I have seen have used simple open source products, with a lightweight structure put in place to organise the information, and with lightweight moderation to manage the site. One of the unhappiest wiki experiences I have had was when the company I worked for bought an Enterprise Wiki product. It was a great product, but it had an orchestra of bells and whistles that you could use toenhance the wiki experience. We were using it for documentation and we had a globally dispersed team, centred on a small UK based core who would write the bulk of the content, and the other folk around the globe could edit the pages to add in the text for their part of the project. In theory this should have worked well, but for the fact that the manager who ran the site was a techy and used every possible gadget in a set of templates embedded within other templates, that made editing anything a complete nightmare, even for the wiki-literate. The rest of the team did not stand a chance of getting to grips with it and as you might expect did not add content to the wiki. The target did users did not use it either, because it was either incomplete, or out of date. It looked pretty, though.
So the moral of this, is KISS.
Managing the wiki community
Understanding, and educating the target community for the wiki is really important. Some basics:- There needs to be a sysadmin person who is wiki-literate and can act as a moderator for the wiki.
- Is a wiki the best answer? Wikis tend to be regarded as a solution for many problems, maybe some other solution like a blog would be better.
- Does the community see the benefit of using a wiki? Sometimes they work surprisingly well. I used one on a globally dispersed agile development activity, where time differences meant it was difficult to schedule daily review calls. The wiki was used as the core of the reporting for the agile activities. So, if the call was timed to suit the West Coast USA, people in Asia could update the wiki with progress and issues, instead hanging around for a conference call at some anti-social hour.
- When people are new to wiki concepts, it takes a real mental gear change for them to understand that anybody can edit a page, or add a new page. It takes a while for them to understand they can make changes themselves instead of emailing the author or moderator, or leaving comments, asking them to make changes.
- Once they are up and running they still need a wiki champion they can go to, to ask questions - usually the moderator
- It's a popular misconception that wikis run themselves. The wiki moderator has a really important role. Looking after the user community, keeping the wiki tidy, monitoring page usage, maybe adding direct menu links to popular pages, looking out for orphan pages, and generally looking after the health of the wiki.
Corporate control
I worked for a large global company that has a massive intranet. It had an enterprise wide product licences for Content Management and also Document Management, all controlled centrally and there were corporate edicts that thou shalt use them - or else. Unfortunately there were huge bureacratic hoops to jump through to even start using them, and when you did they were real pigs to use. Suddenly wikis started popping up all over the intranet, and these were being very successfully used instead of the approved corporate tools. So Corporate Central does a software evaluation exercise, buys an enterprise wide wiki product license and gets a contractor to install it. An edict is sent out saying that all wild wikis must move onto the corporate wiki farm and henceforth only the corporate wiki product should be used. So what happened next?- The corporate wiki had lots of nice features and some neat tools to help migrate onto it so quite quckly wikis migrated onto their own wiki nodes on the wiki farm.
- Then the trouble started. Firstly the sysadmin person was only doing the role as a kind of a hobby - there wasn't any dedicated resource to keep pace with escalating demands for wikis. Wikis were the new tomorrow, everyone wanted one.
- Suddenly wiki performance ground to a halt as all these new wikis started flogging the server. By this time there was a full time sysadmin, and althougth the wiki farm was on a highly scalable virtual server, the sysadmin could not get the sysops to allocate more server resources as there was not enough budget in the budget code to which to charge the costs.
- Users are screaming at the sysadmin, who by now has run for the hills, so one of my colleagues took it as a personal challenge to sort it out - which he did after a couple of months. Got a full time sysadmin team, enough budget to support the servers the remainder of the year. Everyone was happy again.
- Then the Security Directorate took an interest. They went apoplectic when they discovered that anybody could edit any page or even add new pages. So they ordered the sysadmins to turn off these features. Goodbye wikis ....
cock-up?
