Thing #16: Wiki Widi Winci

Egad--it's been awhile. I've been discovering yet another corollary of Murphy's Law, library division, to wit: "The classes that need the most prep are the ones the teacher wants to schedule the earliest." Being up to my ears in the infolit prep thing right now, and viewing all these wikis, it's not surprising that the first thing that suggests itself to me is their potential as a tool for instruction/reference. (The line between the two is becoming increasingly hard to draw these days.) Wide-open wikis make me nervous. Like a yummy bag of cookies you might find on a park bench--you don't know what might be in them or who might have had their grubby hands on them. Not a good idea to eat out of that bag. The kind of wikis that are created by a group, but a limited group, are more promising. Since we've been talking a lot about moving more towards subject teams, having wiki-style subject pages created by the Science Team or the Humanities & Arts Team might make a lot of sense--or even open to all the subject librarians. Many of us have wide-ranging interests that don't necessarily match the subjects we're assigned to at the time, but any of us might run across content that might be of interest to someone else. If I do this now I have to send X an email saying, "Hey, look at this cool resource; you might want to add it." With a wiki I could just add it myself. If X looked at it later and thought it sucked, X could always remove it. There weren't a lot of academic library subject pages in the examples, and the ones I saw didn't look that attractive visually--but the idea is a good one. Wikipedia itself has a very attractive and user-friendly design, so it can be done.

I was intrigued by Albany County PL's idea for a wiki of procedures. That's another good library application. Unlike policies, which ought to be relatively stable over time, procedures change all the time, and the best people to write or edit them are the people actually doing the procedure in question. As long as you have some guidelines about structure and what needs to be included, having the folks actually doing the tasks able to edit procedures is eminently sensible. That way, you could easily adapt to new software, hardware and/or wetware without having to go through a rewrite & approval process every time something changed. There should some kind of PP guru/editor who took a look now and then to make sure things didn't get way off track, but otherwise a great idea.

The biggest problem even with limited-group wikis--as with any group effort--is the "let George do it phenomenon." To put it another way, if everybody's responsible, no one's responsible. Same reason some students (usually the better ones) don't like group projects--a small group of competent and conscientious schmucks do most of the work. So again, any team or group should have a wiki-master (does that word exist? it does now...) or some such person, to make sure everyone is contributing, keep an eye out for redundancies and inaccurate or outdated info.

The "event wiki" is another good application--a conference one is good. Also, a class is like an event--it goes on for a limited time period. It would be cool to collaborate with a discipline faculty member on a class wiki. I wish wikis had been around back in 1998 when I co-taught an art history class. It would have been a lot easier than WebCT was back then!