LIBR 246-04/13 Web 2.0 (Spring 2010)

This week, you'll be learning about wikis and social bookmarking, but this is something we'll be exploring in greater depth in the subsequent two weeks as well when we explore internal collaboration and collecting knowledge from our users. Both tools are instrumental for those tasks. I plan to cover social bookmarking and tagging in depth in my lecture two weeks from now on user-generated content, so this week I will focus my lecture on wikis.

Why Wikis are Amazing

One big positive that wasn't really a factor when I wrote my book is that a lot of wikis now come with WYSIWYG editors. This means that instead of having to learn wiki markup, editing a wiki is just like editing a Word document. It's just like in Drupal, instead of using HTML, you can just click a button to make something bold or to create a link. Not all wiki software comes with a WYSIWYG editor, but it's often possible to install one on top of the wiki if you have someone with a lot of technical expertise. While it will work, installing a WYSIWYG editor that isn't made to be integrated with a software package can sometimes lead to bugginess. However, if you have a population that wouldn't be comfortable with wiki markup, it's absolutely worth the bugginess to get staff or patron buy-in.

Most wiki software options out there are free and many are also open source. Open source is a very good thing if you have someone on staff with programming skills who can customize the wiki to meet your needs. But even if you don't have a programmer, to get a very basic wiki, you shouldn't have to pay anything. There are lots of expensive “enterprise” wikis out there, but I really don't believe that libraries would need the features they offer. Even companies like Motorolla and IBM use open source wikis like Twiki and MediaWiki.

For the many libraries out there whose servers are controlled by rigid IT staff, the good news is that there are wiki options that are hosted by another company. Some of these are free and offer bare-bones features that are usually enough for most libraries' needs. Additional features, like the ability to customize the look of the wiki, usually cost money. Some free hosted wikis are supported by ad revenue, though a number of companies will keep the ads off if you say your wiki is for educational use. Definitely an important thing to look into since you probably don't want ads on a wiki you're creating for the public.

Version control is the brilliant invention that keeps wikis from becoming a free-for-all and that makes the wiki novice feel safe in the knowledge that they can't break the wiki. With version control, every individual page on a wiki has a full history of every change ever made to that page. That means that you can see every revision going back to when the page was first created and can also roll the page back to a previous version if the content is vandalized or otherwise damaged. To go back to the immediately previous version of this page, it's as easy as clicking the link that says rollback.

Wikis are an amazing tool for knowledge management and this is something so critical to libraries and other organizations. Tell me if this sounds familiar. Someone does an important job at your library and they're the only person who knows how to do this thing. One day, they leave the job, taking all of that specialized knowledge with them and someone else has to learn the job from scratch. This is all too common in libraries and other organizations. We are really bad at collecting knowledge from our staff, when, really, that is one of our greatest resources. Wikis are a great tool to collect employee knowledge.

I used to be the webmaster at my library on top of many, many other responsibilities. When I was asked to update a page, it was rarely my top priority because I had a lot of other tasks to do. So it had to wait until I had time to do a whole big batch of changes. Webmasters often become a bottleneck in institutions because they are constantly asked to make tiny changes. Believe me, they don't enjoy it any more than the people waiting for their page changes do. The alternative is that librarians don't update their subject guides as often because they don't want to bother the Webmaster with small changes. This isn't a good solution either. Because wikis are so easy to use, other people in the library can get involved in the task of web development. This leads to a more distributed web development where each person can update their own content. Wikis also allow for very quick editing. Instead of firing up Dreamweaver, making your changes to the HTML, FTPing to the server and transferring the modified file over, you are just clicking edit, making the change, and then clicking Submit. That's it! Therefore, it's much easier to make those small, cosmetic changes that can build up over time.

Wikis are an amazing collaboration tool. We are so used to a world where each Web space has an owner who controls what does and does not go into it. With a wiki, anyone in a community can add to and edit the wiki. The community can be you and your friends, it can be patrons at a library, or it can be anyone on the Web. It just depends on how you define your community. This openness allows a community of people to contribute their unique knowledge and ideas to a single web space. Librarians are used to being the knowledge experts, but public wikis force us to accept that our patrons can bring a lot of knowledge to the table. We don't know everything about every topic, and there are times when out patrons' knowledge of books, public transportation or history would be quite useful. Wikis are a great tool for collecting the knowledge of a community for the purpose of benefiting the community.

Wikis in Libraries

I'm going to go over some great examples of using wikis that are not in my book. There are a lot of terrific examples in the book that really have inspired me, but there are many that have come out since then that are equally impressive. First, we're going to look at wikis that are being used to either collect knowledge from patrons or to provide services to patrons. Either way, they are publicly-facing wikis.

The first  example isn't really a wiki success so much as an example of something that could have been great if the notion of community had been expanded. The librarians at McMaster University in Ontario created this wiki to provide library information for first-year students. And it's a fine wiki with good information. The only problem is that I don't imagine students are going to visit a library wiki. They might visit a University wiki that contains vital information to them and might them stumble upon a library wiki, but it's unlikely they will seek out a wiki with general info about the library. I think the librarians at McMaster missed a golden opportunity here to create a University wiki. Imagine having a wiki with useful information from the Writing Center, Student Life, Student Dining, Athletics and all the academic divisions as well as the library. It would be a wiki that embodied the collective knowledge of the University community. It would be truly useful to new students. And, if created by the library, it would make the library's website the online hub of the University.

I wrote a lot about the Biz Wiki at Ohio University in my book. The Biz Wiki was the first subject guide wiki that I know of and it's still really one of the best out there. Chad says that he got the inspiration for the Biz Wiki from me, but I can definitely say that I got the inspiration for Norwich's wiki subject guides from him. I'd been looking for some time for the best way to do subject guides at our library. My main goal was for them to be easily updatable by the staff members who created them in the first place. After experimenting with a few different options, a wiki seemed like the best tool to accomplish our objectives. One thing I was adamant about is that I didn't want our subject guides to look like the Wikipedia, since students have been told time and again not to use the Wikipedia in their research. I wanted to avoid any confusion on that part. I also didn't want the wiki to look like a wiki, hence the design. Unless you are logged in as an editor, the only thing you see on the left-hand side of the page is the search box. There are a few real benefits to using a wiki as a subject guide and the top one is findability. You can search the wiki, and it will find anywhere where your term is mentioned in the full-text of every page. Our wiki is also browseable by subject. We have assigned categories for each of our pages so that people can click on a category and find other resources that have been similarly categorized. So, for example, they could click on Criminal Justice and find all of the other subject guides that deal with the topic. The main benefit is how easy and quickly the subject guides can be updated. If a link needs to be fixed, we just need to click on Edit this page, make the change, and click Save page. Each of the librarians is updating their own content on the wiki, which gets rid of the problem of the Webmaster bottleneck. For now, we are pretty much using the wiki as if it were a content management system. I like that we have the option to include faculty and students as collaborators if we decide to in the future. I feel that this is a tool that is flexible enough to become whatever we may need it to be in the future.

Wikis can also be used to highlight collections. The Princeton Public Library created a Book Lovers wiki for their adult summer reading program a few years back. Instead of having the patrons submit book reviews to a librarian, they could add the reviews to the wiki themselves. The library collected well over a hundred really useful reviews of books. They ended up with a great readers' advisory tool, created by their patrons, that highlights some of the great books in the library's collection. It's a win-win project!

The next example is taken from your reading this week on using the Wikipedia to highlight library collections. Whether teachers like it or not, students are going to use the Wikipedia, especially the linked resources at the end of the entries that often do lead to credible sources. This is an entry for the Tacoma Narrows Bridge in Washington state. Take a look at the bottom of the page with links to useful resources. As you can see, one of them is from the University of Washington's Digital special collections. The University of Washington has been inserting links to their collections into relevant articles in the Wikipedia. Someone doing research on this bridge may never have thought to check out the University of Washington's special collections, so this makes their special collections materials that much more visible.

Implementing Wikis in Libraries

Since I wrote the book, there has been an explosion of wiki software options. There are literally hundreds of software options. Some are viable projects with a lot of people contributing to them. Others are pretty poorly executed. It's important to critically evaluate the options before settling on a type of wiki software. If the tool is open source, look into the project. Some open source projects are just one person's pet project, and one day they may get tired of doing it and stop improving the software. Other open source projects are thriving, with thousands of people using the software and working to make it better. MediaWiki is a great example of a thriving open source project. Because it runs the Wikipedia, the software isn't going anywhere. The flip side of that is that the trajectory of developments leans heavily towards the development of MediaWiki. Therefore, the features are designed to make the best Wikipedia, perhaps not always to make the best library wiki. I highly recommend trying out the WikiMatrix's Choice Wizard. This is a terrific tool that asks you questions about your wiki requirements and then gives you a list of software that meet your needs. You can then compare the features of each of those tools side-by-side. The WikiMatrix is a great site to explore before making any decision about what wiki software to choose.

The first choice to make with wiki software is whether you are going to install it on your own server or have it hosted by another company. There are pros and cons to each approach. Hosting it yourself gives you total control. You can control the look of the wiki and how it works. You can install additional software to prevent spam or to extend the functionality of the wiki. The downside is that you have total responsibility. Installing wiki software usually isn't too difficult, but you will periodically have to upgrade to the newest version of the software, which can be intimidating for someone who's never done it before. When a company hosts your wiki, you don't have control and anything you want to do in terms of adding functionality or customizing the look will probably cost money. On the other hand, you don't have to install anything on your server or deal with software upgrades; it's all handled for you. For libraries that don't have control of their own server, this is really the only option, though keep in mind that you may have to pay to get the features you want. These are the popular wiki software options for non-hosted and hosted wikis. I use MediaWiki almost all the time because I'm so familiar with it. Twiki and PmWiki are also popular wikis that are being used by libraries as well. Doku Wiki is a no-frills option that is very easy to install on a server.

In the hosted camp, PBWorks and WetPaint are two popular options. Wikispaces is popular with the K-12 crowd, mainly because it was the first to get rid of ads on educational wikis. PBWorks and WetPaint have since followed suit.

It's a very good idea to try out the software before you commit to it. You will never see its flaws just by looking at other wikis that use the software.

So, let's say you've chosen your software. Now comes the hardest part: actually getting people to add content to the wiki. The first thing you need to do is seed the wiki a bit. No one wants to add to a wiki that has no content on it, because why waste your time with a project that no one else thought was worth contributing to? Create a basic structure, create some pages, and add at least a little bit of content to each page.
While it's good to seed the wiki, you need to avoid the temptation of doing it all yourself. When people see a wiki that has only been edited by one person, it starts to look like that person's personal wiki. That is another barrier to people adding to it. So sometimes you need to hold back for the good of the wiki.

Documentation is critical. I've spoken to people who tell me that everyone knows what a wiki is at this point, and I know from the workshops I teach that it simply isn't true. You will need to tell your community what a wiki is, what the purpose of this wiki is, and how they can edit the wiki. You will need to provide very implicit instructions and FAQs. In addition to all that, it's a very good idea to offer trainings. Not everyone can learn from reading an FAQ; some people need to sit in a room with a knowledgeable facilitator to feel comfortable enough to edit a wiki.
Even then, you may encounter some resistance that has nothing to do with your colleagues or patrons being luddites. When people are used to a specific way of sharing information, it can be difficult to change. If you're dealing with your colleagues, they are probably used to sharing knowledge via email. You need to acknowledge that and find ways to make it as easy as possible for them to add content to the wiki. For a while, maybe you want to add content to the wiki for them. Turn their emails into wiki entries. Put a shortcut to the wiki on the reference computer. Create a browser toolbar with a link to the wiki. Continually remind people and offer support. It can take a lot of gentle persistence to get people to change the way they do things. Most of all, though, they need to see some compelling reason to change.

Don't try to exert too much control over the wiki. The best wikis have a grassroots feel. A recent study of wikis in corporate settings have shown that the best wikis came from the staff, not from above. So staff wikis need to have that “bottom-up” feel.

If you're creating a wiki where you're collecting knowledge from the public, think about partnering with groups that share your mission. If you're in academia, try working with the Writing Center, with learning support, and other academic support groups. If you're in a K-12 library, work with teachers. If you're in a public library, work with local schools and other community organizations. They can help spread the word about the wiki and can help add useful content.

I highly recommend taking a look at Wikipatterns. This is an interesting site in which you can see a lot of the behaviors of people who contribute to wikis. There are definite personality “types” within wiki communities. This will give you a good idea what to expect if you get involved with a wiki that lots of people are contributing to.

Finally, we need to look at wiki management. I think this is the part that too many people have ignored. I've seen lots of totally public wikis that started off great but are now covered in spam because no one took responsibility for maintaining them. The fact is, it is not very hard to maintain a wiki, but someone needs to do it. Someone needs to watch the wiki every day. I subscribe to the RSS feed of the Recent Changes page where I can see every change made to the wiki in my aggregator. If something is inappropriate, I can just roll it back. It's very rare that someone posts something inappropriate, but how often that happens is dependent on the population. Librarians, fortunately, are pretty polite.

Spam is only an issue when you have a wiki that anyone can edit. If anyone can edit a page, spammers can insert links into the page to porn, drugs, and more. There are ways to prevent spam from ever showing up on the page. There are spam blacklists that look for specific words in the post or specific IP addresses that have been blocked in the past. There is also a tool called Bad Behavior that looks at the behavior of the entity posting content to determine if it's a spammer or not. It's the most effective tool I've seen for preventing spam, but it only works on wikis that are based on PHP and MySQL. On the Library Success wiki, I use Bad Behavior, but I also require email authentication for anyone creating an account on the wiki. That has mostly prevented spam, though I have to fix a few things each month.

Spam is easy to deal with in the sense that you know what to do with it when you find it. But what about content you just don't like? What about content that is critical of the library? When you let patrons post whatever they want, it's very possible that they will post things you don't like. It's a good idea to have guidelines about what is appropriate and inappropriate to post to the wiki. The Wikipedia and the Library Success Wiki have good examples of guidelines. You have to walk a fine line between preventing really inappropriate and keeping that free, open, grassroots feel. People should be able to criticize the library on the wiki if it's considered on-topic. If they feel like they're being stifled, they simply won't add content to the wiki.

The best way to manage the wiki is to have your community do it, but this isn't always possible. When I created the ALA Chicago Wiki in 2005, lots of people were helping to keep the wiki organized and spam-free because it was a time-limited project and had a large group of contributors. It's better to let other community members police the wiki because then it doesn't look like the library is policing the wiki and controlling it. Most wikis though are managed by one or just a few people. In that case, you are going to have to be the one to delete inappropriate content. If you do, just put a note on the discussion page explaining what you did and why. Then it doesn't look like you're arbitrarily censoring people.

This week you're going to be leaving our site for a whole other community. In your exercise, you will need to make a contribution to another wiki community. I highly recommend contributing to the Wikipedia, since it's such a thriving community and it's likely that your contribution will be altered by others after you've added it. Another good wiki to contribute to is the Library Success Wiki. This is a wiki that librarians are continuously adding content to nearly every day, and it's a knowledgebase for our profession so you probably have useful information or insights to offer. I'll be curious to hear what you think of wikis once you've been on the other side of them as a contributor.