TechEssence.info

This post is meant to complement the TechEssence white paper on wikis.

Wikis are really hot right now. It seemed to be all people were talking about at Computers in Libraries this year. People are starting to use wikis in libraries to encourage staff collaboration and to encourage patron participation online. Many people often become skeptical of "hot technologies" because they can get to be so over-hyped. However, I can confirm from experience that, when used properly, wikis can harness the collective intelligence in unprecedented ways, and have tremendous potential for use in libraries.

I have created a lot of wikis for the profession, though it was not originally my intent. Initially, I'd wanted to create a Web guide to Chicago for the ALA Annual Conference. I'd been so completely lost at my first ALA Conference and had found very little helpful information online. However, having only lived in Chicago for about two months at the time, I didn't exactly have an encyclopedic knowledge of the area. So I started thinking about how I could get other people to add their knowledge about the Conference and about Chicago to my Web guide. Although I'd never used a wiki before and hadn't ever considered it, it seemed like the right tool for the job. Thus was born the ALA Chicago Wiki, a guide to the conference that is filled with knowledge from hundreds of people. What better way is there to gather knowledge from large groups of people?

If you have a project for which collaboration is essential, a wiki may be a tool to consider using. When editing a policy document, you could send around the document via e-mail and run the risk of different versions floating around with edits from different people. Reconciling all that that can be incredibly frustrating. With a wiki, the document is in a single location on the Web and you can actually track the changes made and who made them. Wikis often have discussion sections where you can talk with your committee about possible changes before actually implementing them.

However, wikis aren't only useful for collaboration. In some cases, the main benefit is ease and speed of use. Wiki doesn't mean quick in Hawaiian for nothing. In many libraries, there is one person who knows HTML and they have to deal with all of the changes people want them to make to the Web site. With a wiki, anyone can make those changes. Wiki syntax is very easy to learn, and some wikis are designed with an interface that looks a great deal like Microsoft Word. When you make a change to a wiki, there is no Web editing software necessary and no FTP-ing involved. You click "edit," make your changes, and click "submit." It's that easy. Wikis can be used to develop certain parts of the Web site that require more collaboration and updating, such as FAQs and subject guides. They can also be used as your Web site's entire content management system, as is seen in the case of the University of South Carolina, Aiken's Greg-Graniteville Library. It may look like a regular Web site, but if you look at the bottom, you will see that it is powered by PmWiki.

The third reason why people might use wikis is for findability. Chad Boeninger's Biz Wiki at Ohio University is a perfect example of a wiki that is not used for collaboration, but still benefits from the inherent features of a wiki. Chad's wiki was a combination of three subject guides that he had created for his business students. While he'd hoped (in vain) for faculty and students to add to the wiki, he found that the wiki was still a lot better than his static subject guides. Most wiki software allows you to search, which means that if students are looking for information about SWOT analyses, they can just search for SWOT and find all of the entries that mention it. With MediaWiki, the software Chad used, you can assign categories to pages, which allows you to build a topical hierarchy. You can assign more than one category to each page to make it more findable. This way, students can either search the wiki if they know what they're looking for or browse the categories if they're not 100% sure what they need.

The possibilities for what libraries can do with wikis are endless. The key is to use wikis to fill a need, not to find a need for a wiki because you want to use a wiki. Don't put the cart before the horse. Staff will likely not use a wiki unless they see that it is meeting a recognized need at the library. They may not think it's quite as "hot" as you do.

People often talk about the negative aspects of wikis. They can become disorganized if people don't create some sort of structure early on, but that is easy to fix if people are paying attention. With every wiki I've created, I developed a structure on the front page of the wiki and as people added new headings, they added them to the front page as well. It only becomes out of hand it you let it. Spam can become a problem if you're not vigilant about it. You need to find a spam killing plugin that works and keep an eye on the wiki for when the spammers get smart enough to get through the plugin. Then you find another plugin. If your concern about wikis is that they're too open and that you don't trust people, then perhaps a wiki isn't the right tool for you. You have to trust your community to make it a success – though you can limit wiki access only to your community. However, with all the wikis I've created, I haven't had a single act of vandalism by an actual human being.

A wiki administrator essentially needs to be a gardener. They need to keep their rows of flowers (pages) nice and neat and organized. They need to keep constant watch on their garden to keep the weeds (spam) at bay. The more they make their garden a good environment for growth (of ideas), the more growth they will see. If you do a good job as a wiki gardener, you will eventually see the fruits of your labors.