This isn’t an “every library in the world should use a wiki post” but I wanted to share a little about our experience. Last summer, a handful of us started developing a wiki that we could use in the public service desk. I was very inspired by the C&RL News article Something Wiki This Way Comes and also Meredith Farkas’ Wiki: The Ultimate Tool For Online Collaboration.
We ended up going with editme.com primarily because it was hosted, edits like MS Word, and was affordable ($5 monthly). I wanted something that would be easy for staff to embrace without having to learn any coding. I called it Answers, hoping to build the purpose into the name.
Everyone was supportive once I provided a demo—previously we’d had some abstract conversations that didn’t go so well, but once people saw the proof-of-concept they were into it. We’re talking about 17 staff members with a vast age and tech experience range.
I wanted Answers to function similarly to the wiki at Miami University (described in the Something Wiki article) (and thats RedHawks, not the Canes) which was: 1) to alert people on desk about anything critical that day, such as printing issues, catalog problems, etc, and 2) to store information with archival value, or for the old timers, to serve as a digital vertical file.
The wiki could cover research strategies for the hot assignment of the week, or current database problems, as well as storing step-by-step guides for printing on Library computers from a laptop, or where to find blueprints for campus buildings. The potential is there for it to be a valuable tool, especially since it’s searchable.
Long story short, we launched Fall 2006 and it didn’t work. No one added anything. They’d often remark, “Brian, you should add this to your wiki” or they would forget that the answers to “irregular” questions were available to them within a few clicks, but they didn't use the wiki and instead searched through old emails. It seems I was unable to transfer the community and convenience concepts effectively, and I found myself not updating since others didn’t appear to be using it either.
I was discouraged, but I am going to make another go at it. I’m going to meet with everyone individually and spend 10-15 minutes showing them the website, highlighting the tools, demonstrating how easy it is update, and encouraging them to log-in and add/change some content.
We’ll see what happens, it’s a cultural change, but hopefully I can help them break the barrier. This was a lesson in the difference between buy-in and adoption. Anyway, if anyone has had success, please post and enlighten us all.
Sample edit screen
Sample Index (it's searchable too)
I remember trying to get people to buy into email waybackwhen believe it or not.
Eventually, we needed to force people to access it. As in "this is your job folks. no excuses if you miss out on something important because you didn't check your email."
It's a hard balance between encouraging the freedom of collaboration and requiring people to do this as their job, but this is a situation where it appears people have offered a verbal "yes" to the project. If that's the case, they should be called on to participate: as in, "I didn't pay for this thing as a personal toy. It is a device that I believe will improve the way we serve the students."
If people don't participate, you don't only lose the $5/month, you lose all of the potential productivity and service quality that ought to have been gained by implementing the tech.
If you got the buy in from the upper-ups for this project, perhaps you can get some help from them too.
You could also set some mini wiki projects in an action plan (get tasks, names and dates!). That might help get things started as well.
In the end, if people didn't want to participate, they should have said so when you did the demo.
Posted by: Ryan Deschamps | January 31, 2007 at 08:14 PM
Here is a brainstorm about what could help, the link is about pattern languages for adoption:
weblog post
Best, Mark
Posted by: Mark | February 01, 2007 at 03:23 AM