{"id":233,"date":"2005-09-11T23:08:24","date_gmt":"2005-09-12T04:08:24","guid":{"rendered":"http:\/\/UnhinderedByTalent.com\/Phi\/?p=233"},"modified":"2005-09-11T23:08:49","modified_gmt":"2005-09-12T04:08:49","slug":"wikis-four-years-on-some-thoughts","status":"publish","type":"post","link":"https:\/\/UnhinderedByTalent.com\/Phi\/archives\/2005\/09\/11\/wikis-four-years-on-some-thoughts\/","title":{"rendered":"Wikis four years on: Some thoughts"},"content":{"rendered":"

\"Ward's<\/a>
\nIn a comment<\/a> on a previous post<\/a>, DesertDonkey asked my opinion on the feasibility of a wiki for the development of an internal knowledge base. I started my reply as a comment, but it grew beyond all sensible proportions and I decided that it really needed to be a post of it’s own. It’s pretty long, so I’ve put the bulk below the fold.<\/p>\n

The short answer? Yes, a wiki can be an excellent choice for building an on-line knowledge base. There are, however, some pitfalls that you’d want to be aware of going in. The enthusiastic may also find my “Why wiki?<\/a>” write-up from a few years ago helpful.<\/p>\n

<\/p>\n

Arguably both the biggest advantage and the biggest risk is the lack of any inherent structure in the wiki. This is nice because it frees you up to do whatever the heck you want, but it also means that you really need to design and maintain some structure if you want to be able to find anything.<\/p>\n

After a few years we found that our CSci wiki<\/a> had become this enormous unorganized blob of (often useful) stuff that was very hard to navigate. We’ve made improvements in some areas, such as a major refactoring of our our knowledge base<\/a> by a few students 2 or 3 years ago. As part of this, they also created some new tools for adding content to the knowledge base that increases the odds that that new content is “hooked in” to the organizational structure and therefore more readily findable. Another reasonably organized (if hopelessly incomplete) piece is the curriculum area<\/a>. This has a certain clarity because most of it was put together by a single person (Rob Faux) instead of built up over a period of time by a large group of people. (But, of course, the great advantage of a wiki is the ability of a group of people to collaborate in building up a knowledge base, so…)<\/p>\n

Unfortunately there are other large areas that are pretty much a mess, including the “front page<\/a>” which still lacks any sort of reasonable roadmap and is cluttered with way<\/em> too many old course webs that we really don’t need to display there. None of this would be uber hard to fix, but it would take time and I haven’t had\/made that time, so there it sits :-(.<\/p>\n

I think the huge<\/em> win for us has been in courses with group projects (especially those with groups of 3 or more). Here the wiki tool has been extremely<\/em> successful as a means for students to organize and document their group’s efforts. The strange (but wonderful) thing is that different groups of students tend to use the wiki in very different ways. Thus the tool molds to fit the inclinations of the users instead of forcing them to do it a specific way. When you’ve got technically competent users with some sense of what they want to do and the motivation to make it happen, then a wiki is a glorious tool. With more novice users, however, like my FYS<\/acronym> classes, it confuses and distresses them. They want\/need more structure and find (in my experience) something like Moodle<\/a> less baffling because it gives them a more structured experience.<\/p>\n

In DesertDonkey’s original query, he points out that “all [their] servers are Windows 2003” and wonders if that’s a problem. I suspect that depends a ton on which wiki implementation you want to use. There are a lot<\/em> of wiki tools out there, and anyone looking to implement one would need to do some homework to see which had the features you want and can be easily run on the platforms you’re using.<\/p>\n

I installed our CSci wiki<\/a> in the late summer of 2001. I’d discovered Ward Cunningham’s wonderful wiki<\/a> shortly before leaving for sabbatical the year before and spent part of the sabbatical looking at various tools (including wikis) that we might want to try at UMM<\/a>. Kristin Lamberty (then still in grad school at Georgia Tech, but happily now a new CSci faculty member here at UMM) encouraged me to seriously consider wikis based on her positive experiences with them at Georgia Tech.<\/p>\n

\"TWiki<\/a>
\nI did a little homework at the time, and decided to go with the TWiki<\/a> implementation of the wiki concept, primarily because it was written in Perl (which was popular in UMM’s Computing Services universe) and had excellent authentication and tracking. The first was important because I hoped that others might take an interest and thought that might go more smoothly if I was using a wiki implementation written in a language Computing Services was comfortable with. In retrospect, this was silly for reasons which I’ll explain shortly. The second was important because I knew that my fellow computing faculty would be very concerned about using the wiki in courses if there wasn’t clear authentication and tracking.<\/p>\n

TWiki’s tracking has worked really well and met our expectations nicely. My concern that be written in Perl turned out to be misplaced, however. In retrospect, I think I made the mistake of assuming that what suited us in Computer Science would be the “right” tool for everyone else as well, instead of simply trying to promote the idea<\/em> of wikis and then letting other people (including Computing Services) figure out what would work for them. That said, I don’t regret choosing TWiki, and certainly it’s use of Perl has never been a problem for us; it’s just clear, though, that the “requirement” that we use Perl was really a red herring.<\/p>\n

We’re now (finally) at a point where UMM’s Computing Services is seriously looking at installing a wiki tool for general use on campus. They’re using a different tool (don’t remember which), and the current plan is to use the U of M’s X.500 authentication system so it will be immediately available to the entire UMM community, but closed to the rest of the world. As much as I’ve been an advocate of wiki-ness over the years, I’m not entirely convinced that this is going to work terribly well for two reasons. First, I think that a large unstructured tool will lead to a large unstructured blob, especially given how completely inexperienced the UMM community will be at dealing with such a thing. If Computing Services has time and the tools to help educate the UMM community on how to use and organize this space then it could work, but without that sort of guidance… My other concern is simply the closed nature of this approach. I would at least like people off campus to be able to read<\/em> the wiki pages, and that may in the end be possible, but as I’ve said before<\/a>, this sort of closed, inward looking approach seems fundamentally at odds with the goals of an open educational institution such as ours. None of this is done and public yet, though, so my concerns may be premature.<\/p>\n

Back when we installed TWiki there were already a lot<\/em> of different wiki implementations out there, and now there are tons more. I’m not<\/em> an expert on what’s out there, and can’t make any concrete suggestions other than to say that TWiki has served us well.<\/p>\n

There are also quite a few more “special purpose” versions of the wiki concept out there, as well as wikis integrated into other tools. Kristin really likes the wiki tool they used for personal pages at Georgia Tech (I don’t remember the name, though). Moodle<\/a> now has a fairly nice wiki module. Mike Anderson and I are currently using the Trac<\/a> tracking tool, which integrates bug-tracking similar to bugzilla into a wiki tool with code version browsing and a few other bits thrown in. This seems to be working quite nicely for documenting and tracking CSci lab issues (of which there are always way<\/em> too many), and the integration of a wiki feature makes it easy to augment the bugzilla-style ticket tracking with discussion of broader plans and issues. (Trac can also use the same htpasswd file that our TWiki implementation uses, so when we “go public” in a few weeks we can make it seamless for our users to use Trac without giving them another password to remember, etc., etc.)<\/p>\n

A final warning (which may or may not apply in DesertDonkey’s case): Public wikis are increasingly subject to the same form of spam that affects weblogs, namely people who are plopping links all over things to crank up their page rank. Our CSci wiki requires authentication to change things and isn’t terribly robot friendly, yet we still get some. Not the oceans that I’m subjected to here, but definitely some and it’s a nuisance. In theory the community works together to find and remove this sort of thing, so that no one is overly burdened by it. If, however, there are a significant number of “static” pages (e.g., pages from past courses in our case) then there’s no active community keeping an eye on them, so the admins have to look after it. A private wiki presumably won’t have these problems.<\/p>\nNo tag for this post.\n\t

Related posts<\/h4>\n\t