Collaborating with Wikis, ILI2005
It’s after lunch and Rachel Bridgewater (Washington State University) and Anne-Marie Deitering (Oregon State University) are doing a tag team presentation on their implementation of a wiki for the Oregon Library Association’s Library Instruction Round Table. They first identified their community and what the needs were, then surveyed the available technology. Why are wikis so ugly? was one question that came up. Then they had to choose a wiki software and discovered there were lots out there. They picked Mediawiki, which was easy to install. Just download the software and, boom, you have a wiki. Now what do we do? Populate it with content. The community is unfamiliar with wikis, so just throwing out the page and asking for contributions would be counterproductive. Populating an entire wiki should not be done by just one or two people, need pushback from the user population.
Instruction resources, glossary, and style manual were first pieces. Put in template. Then opened up to small group of people. They wanted specific disciplines and teaching techniques.
Turned their attention to how to encourage people to become contributors to the wiki. Brought wiki to focus groups. Informal usability testing.
How wiki do we want to be?
No restrictions to entry because no one wanted to remember another username and password. Not much of a hierarchy to the wiki.
Contributors could put information wherever they wanted, which was often not where Rachel and Anne-Marie thought it should be. But they left it where it was classified.
Did some un-wiki things.
Not easy to add elements. Requires hard coding php. It’s not easy. That’s why Mediawiki wikis all look alike.
Released the library instruction wiki only about a month ago.
Lessons learned:
Customize it.
Be prepared for culture shock
Have some content in it from the start
Write a lot of help documentation
Have a specific, defined purpose/community being services
Does require maintenance
Still not sure a wiki is the best solution.