Week Six : Wikilicious

I have worked with and heard more about wikis in the last few weeks than I did in the last few years.  We have a wiki at work for our project team, I've been working on one with my group for this course, and of course, doing the readings and boning up on the pros and cons of wikis.

Unfortunately (or fortunately), when most people think wikis, they imediately think the Wikipedia.  I really enjoyed the readings this week evaluating the Wikipedia, and expounding on its failures (and successes too).  I wouldn't agre that the Wikipedia is a disaster, and even turn to it now and again when I'm looking for some obscure fact, or as a starting point for some research.  Much can be said about the Wikipedia, but that is not my purpose today - and I'm definitely no expert on the topic.

Not that I'm an expert on the uses of wikis in libraries, either, but I'm still going to talk about them.  I like the idea of a wiki, and can see the usefulness for certain applications (as outlined by Meredith Farkas: subject guides, internal communication, community bulletin boards) already in use, and many more.  As with other tools we have examined, one of the keys before starting a wiki is making sure that it's the right tool for the task at hand.  I like the idea of using a wiki as a library website, or at least connecting a wiki to the library website in a way that makes sense, like SJCPL has.  Opening up the potential pool of people who can update a site virtually guarantees more timely updates, and could be a big step to fostering a larger user community.

In my personal experience, a wiki can be a very useful tool - as I've mentioned, we use one at work to keep track of our big project, and every team member is responsible for updating content (though there are team members designated to keep on top of certain sections).  Other wikis are also in place at work, for other departments and project groups, and it's really refreshing to see this technology at work in a useful way.

On to the case studies this week - each wiki had its strengths and weaknesses, but I've picked 3 favourites: Bizwiki, SJCPL, and Bullrun.  These three sites had some features in common - like a connection to the library's main page, and other relevant pages right from the wiki, a clear and well-organized layout, search capabilities.  I liked how Bizwiki was so personalized - a picture of "my" librarian, and an imbedded meebo chat makes 2-way communication very accessible - and I also liked that it was familiar-looking (it looks very much like the Wikipedia).  SJCPL is frequently updated, and I liked the layout of the subject guide (and it's easy click-ability).  My favourite things about Bullrun are somewhat extraneous to the wiki itself, but they include the embedded worldcat search, and the ability to follow the wiki via RSS, tag it on del.icio.us, digg it, and start my own wiki just following links available on the wiki home page.  The site I liked the least is Butler WikiRef - it is bare looking, not very easy to navigate (for me), and there is no search or links back to the library's main site.

 One thing that struck me this week about the library wikis is how many of them had been created using free software, and seemed to maintained online, and not kept on the library's own servers (I'm going by the urls here, and may be incorrect in my analysis).  After our discussion on blogs and how important it is for reliability, privacy, stability, etc., that they be housed on local servers, it is interesting that wikis seem to be stored in a different way.  Some of the sites used pbwiki, or seedwiki, for their sites.  I've been playing around with wetpaint, another free wiki tool, and have been enjoying it.  I have fully enjoyed my wiki experience so far, and can see real potential for how I can use it in my professional life in the future.