Factors for a successful wiki
Fra Harald Grovens wiki
Question
- This is an edited version of an enlightening discussion on the Mediawiki-L list November 2006. Participants: Frederik Dohr, David Gerard, Ricardo RodrÃguez, Fernando Correia, Hans Voss, James Sullivan, JTAutry, MHart
After reading quite a lot about Wikis, mainly for a university paper, I'm convinced that our project team could greatly benefit from employing a wiki. I've already convinced the project manager that we should at least give it a try. Mainly by stating how it won't cost a dime. However, predictably, many of my colleagues are quite skeptical - and to be honest, so am I to some extent.
Purpose of web site
The aim of a corporate wiki is, instead of oh, Bob did that for two years, but he left last week . . . I wonder how he did it, to be able to say Bob did that for two years, he left how-to notes on the wiki."
Who are not sick of sending MS Office documents back and forth?
Wikis are supposed to be everyone’s collective notepad. Many work places have several internal wikis. Mostly they work per group. I write up something on any process, procedure or in-house application I have to use a lot, as notes to *myself* and others. You know how a lot of people start a new job by getting a notebook and writing everything in it?
Companies are constantly in the process of centralizing all technical documentation of our organization to the wiki, for use by several departments of the company. The idea is catching on and other departments are exploring the idea of using the wiki to document their knowledge and also to publish documentation to customers.
Content especially useful for wikis:
Meeting agendas Lists of ongoing issues for said meetings Change requests - the canonical CR is a particular version from the history, but those working on a complicated CR can edit it as they go documenting what actually happened, which is very useful for the next similar CR Local jargon file. The big use we put ours to was training new starters very quickly. A local jargon file was a particularly good use. Also: An academic paper could be co-developed via a wiki page quite well - start from notes and end up with a coherent and clearly-written paper.
When not to use a wiki?
A wiki is a great tool, but it isn't the right tool in every situation.
Do you need/want active collaboration?
- If the answer is no, a wiki isn't for you.
Are you creating information that will be used/referred to over a span of time? - If the answer is no, you probably don't need a wiki.
Are you primarily looking to have a conversation or build an information repository? - Wikis have a built-in mechanism to support comments (the Talk page) but if you place more importance on the conversation than on the documents sparking the conversation, a wiki probably isn't the best fit for your project. Consider a forum or a blog.
Is process central to your project? - Wikis are generally process-less, which means they aren't the best way to manage a process. If you care about tracking status and issuing alerts, consider Quickbase.
Motivation for using the wiki
How can I motivate my colleagues to at least try it out - and hopefully realize that it might actually be a great help to them? How is your office culture? If you have a secretive office culture - where people guard knowledge through fear - a wiki won't fix that.
Many web administrators have no way of handing out motivators of any kind - let alone making use mandatory. Even getting everyone to just enter their name and position (to make them take a look at the wiki) is quite a challenge. . . And the project leader wouldn't be willing to take any such steps before he sees that the wiki is actually working - kind of a catch-22. . .
Should the Wiki act as a kind of knowledge base rather than a collaboration tool? (Although, of course, the one doesn't exclude the other. ) The individual employee usually doesn't really have much of a stake in such a knowledge base (what does he care about a possible successor. . . ? ). So why should s/he contribute (if there's be no obligation to make use of the wiki)?! Therefore I'm trying to convey it as a tool that makes collaboration a lot easier.
People are busy and they will only put their knowledge on the wiki if they perceive some value in doing it. Some will do it because it is their job to share information (technical writers). Others because they need to communicate information to others that use what they develop. Others will use it as a personal notepad and share the information.
I think peer recognition would also be a powerful motivational tool. It would be great to see some ways to reward people that make good contributions, like giving them some stars. It is a little difficult to do this because in a wiki articles don't have owners. How can you judge the value of each individual contribution?
How to make an organization’s web site work as an environment for collaboration?
Why should people spent their time on a web site experiment? Rather: Use the wiki to solve a problem. If the employees share the problem, they have an interest in solving it.
After some months trying to propel the use of a wiki environment within a couple of research teams, I have concluded that a top-down approach is mostly required. I mean, when the head of a team asks team-members to discuss a contribution she/he has previously entered in the wiki by using the wiki, you will be successful for sure: there is not alternative to use the collaborative environment!
Some content could act as a trigger for participation. In my case these "useful contents" have a clear end: a paper sent to a publisher.
Most often, the office culture is not secretive (for the most part), but people are quite busy with their regular tasks and thus reluctant to take on new ones (like documenting their work).
One of the best keys to getting a wiki used is to use it as a better substitute for a group whiteboard or something. As I said, it's good for notes on common in-house business software and how to install it and get it to do particular things. Essentially: find some function that a webpage anyone can edit would be a decent solution for.
When people ask you for info, point them to the wiki article about it. If there's no wiki article about it, create one and THEN point them to it. I've actually had people email me about something on the wiki that needs to change. I just email them back and tell them "It's a wiki, dude. Change it yourself. "
I understand that I am trying to use a tool created for free creation/free access of contents to developed proprietary knowledge. But this is the way things work in a huge number of places and to cope with this situations the only way to promote the collaboration, share of knowledge and production of freely accessible information/knowledge.
Organizing a Wiki is a job for one or more persons who are enthusiastic about wiki and know something about the content and will actually once in a while go through the wiki to bring the order and organization to things. Once users see the new organization (and if it is one that works) they will bring in new documents to that structure.
Workshops showing wiki work basics by using the wiki environment will also encourage people to follow the thread. Even probably you must be ready to suffer criticism and skepticism for a long while!
How to implement the wiki within the organization
Start with a simple template for the interfaces to and from our system. It is fairly easy to fill a template article, so the knowledge on how to use the wiki can be very little. Small steps in the beginning. Then a couple people should find it interesting or rewarding to work in a wiki. Encourage that and help them solve their problems. people talk with another. Teach the use and the possibilities of the wiki. Half a day is short but a good starter. Make the wiki mandatory for certain types of information. Mostly it is limited time of the workers, to put down that information. have someone help them with it. Wikis need a champion - and that's YOU right now. Start using the wiki for yourself, documenting projects, figuring out article structure and classification. I would highly recommend getting a decent search system on it - if you have a Google appliance in-house, use it with one of the extensions documented on the Meta site.
In order for the wiki to succeed you have to first and foremost have the stamp of approval by someone with authority. They don't need to be 100% sold on it, they just have to allow you to use it and to give others access to it. That should be an easy sell.
Second, you have to put relevant useful content on the wiki that people need access to. Pay attention to docs that people are always looking for, modifying, etc. You can find that by looking at the web server logs. For example, we currently have no way to track individual projects here, we're a small shop and most things just get done in a couple days, no big deal. So when I setup the wiki, the first thing I did was setup a project template and put everything I was working on at the time onto the wiki. I setup a project status page that had rolled up info on all the current projects. When my boss or his boss wanted an update, I told them to check the wiki. They were blown away by the thought of having a quick snapshot of what everyone was working on, documentation, links to folders on the network for source code, production directories etc.
To sum up, make a case for the wiki to get approval to use it. And then use the heck out of it. You'll have some early adopters that will see its usefulness to the organization as a whole and use it, not everyone has the 'what's in it for me' mentality. Those that DO will simply be forced to use it once it becomes integrated into the standard practices of the org.
What's required in terms of basic structure?
Certainly some help pages for explaining the wiki syntax (though I'll probably link to Wikipedia rather than create it from scratch), There are a couple of other things to increase acceptance and participation. Due to the large variety of projects people here are working on, it would be very hard to create a comprehensive basic structure right from the start. So I'll have to rely on the users/colleagues try to create a kind of self-organizing wiki
However, people that think wikis are self organizing quickly realize that the initial hopes was actually quite naive. . . .
You need to give some direction in the beginning. And you need to have some kind of means to force people to use the wiki.
Different wikis require different structure. Best to create a basic structure that you think works and let it evolve. Don't be afraid to create multiple "landing" pages and see which one works best.
That is what I see is the problem. Where I work, small groups set up a wiki and learn to use the wiki as a group with few problems since the wiki admin is typically in the group. But when an enterprise-wide wiki is set up many come to it and have trouble determining first of all that it is a wiki and they can add content, then have trouble determining how to create a page, then how to place it within the wiki's structure. We use categories in one of our enterprise wikis and a Main Page that is nothing but instructions. I've concluded that designing a wiki is as much if not more complicated than designing a web page. But like a web page it needs to stand on its own and users will rely the Main Page to guide them.
The best way I've found for designing a useful wiki is to look at other wikis. Wikipedia is an awful example I think. But its so famous that people who want to add content are motivated to learn it. That is not the case in most offices. But there are many other wikis to look at and get ideas from. One of my favorites is www. cookbookwiki. com. They state at the top of the Main Page that it is a web page that you can edit. On the sidebar they have a "Resources" menu with links to setting up an account and creating content. If you follow the "Create Content" link there are instructions on what to do to create content, including searching existing content first so you don't duplicate. Its handholding but I think that is what needs to be designed into the wiki pages to guide the helpless new wiki users along and make adding content easier. Otherwise you will end up with a small number of contributors to your wiki and their content scattered randomly in the wiki, lots of orphan pages with duplicate content, and I have one of our earlier wikis to prove it.
So, in short, use other well designed wikis you find as guides and before releasing your wiki, have some novices try to use it. This user testing should show where problems are and where improvements can be made.
Just like its sometimes hard to get people to start using a web page full of documentation or other information. That's why I think the design challenge is similar for both web sites and wikis. You need something compelling to draw people to it and to use it, and in the case of wikis a reason to hit the edit button. This is more in the realm of art (or worse, marketing) than technology.
Which publishing tool to use to create the web page?
The actual wiki software hardly matters. MediaWiki is very easy to use and install, but a bit heavyweight for a small team; it also doesn't even try to do access control. My work has various installations of MoinMoin, TWiki, MediaWiki, UseMod, Trac . . . my group uses MoinMoin because it uses flat files rather than a database, and it's only used by ten people, so MediaWiki was a bit fat for the job.
User interface
- Most of the team-members arrive to the wiki from a WYSIWYG (like ms-word) environment. In spite of this fact, most of them are now using Mediawiki without problem. I'm trying to decide if the use of a WYSIWYG environment with the wiki is a must or could be avoided. As far as I see by reading this list entries, Mediawiki people philosophy are far from these two concerns. So they are from access control. And I can get their point! But at least in the kind of environment - WYSIWYG wikitext editors make simple things simple and hard things impossible. - But most of the people arriving to the team come from a Windows based environment. A slightly more featured WYSIWYG environment should ease the transition.
As for a WYSIWYG interface, I'd agree that while this might erase the initial obstacle, its (current?) limitations would likely lead to frustration further down the line. I'd consider WYSIWYG if advanced users could just turn it off, but it seems that all available solutions/extensions change the way contents are saved, creating an either/or situation. (This might also lead to complications when trying to export contents from the wiki for use in some other medium!?)
