Technical requirements

Picking and choosing a wiki

Anyone wishing to run a wiki has a wide variety of engines from which to choose. In fact, no matter what your institution's computing environment, a wiki engine can run in it. Wikis have been ported to every language, operating system, and hosting environment in common use, from desktop wikis such as WikidPad (Windows) or VoodooPad (Mac OSX), to wiki engines that run under common server scripting environments such as Perl (TWiki), PHP (PhpWiki), Python (MoinMoin), ASP (Open Wiki), and even less commonly used languages such as Ruby (Instiki) and Smalltalk (Swiki Swiki). Given the wide variety of solutions available, you will probably find that the important criteria for choosing a wiki have more to do with features and stability than with the server requirements.

Downloading and tinkering with one of the desktop or 'personal' wiki engines is an easy way to get a feel for how wikis work. And if your institution has even rudimentary support for educational technology, it should not be difficult to request that they install a server-based wiki engine for you. As part of an institutionally-supported installation, you might be asked a number of questions by support staff. In general terms these will probably touch on issues of security, the duration of time you expect the wiki to remain available for use, use of available server resources, and, possibly, privacy and copyright concerns.

Installing RAP

We decided to run RAP on the SnipSnap engine after an extensive review in 2002 of open-source wikis . As part of this review, we built up a matrix of technical requirements, then compared the matrix to a wide selection of available wiki engines (see Fig. 1). For the front-end user, SnipSnap was more elegant and intuitive than the other wikis we compared: its default GUI (graphical user interface), image uploading process, and coding conventions were easy for students to master. A modular navigation bar, appearing on every page in the wiki, enabled the instructor to highlight important pages sitewide. Users could easily search the system, while SnipSnap itself offered a list of related content.

Our decision to go with SnipSnap was based largely on front-end usability and features, but on the technical side SnipSnap also appealed to us for several reasons. As a Java application its system requirements for the server that would host it were minimal, making it easy to get up and running. It was also clearly under active development and had an aggressive release schedule, which appealed to us in comparison to other packages that appeared to be stagnating. While SnipSnap did not match up with all of the features we wanted out of the box, there seemed to be good reason to be optimistic that many of the desirable features would be implemented in a timeframe that would work for us (see Fig. 2). This was a gamble that has mostly payed off for us.

SnipSnap is a fairly self contained Java application. As such it can run on most available operating systems, and for its default installation the only technical requirement is that the freely available Java 1.4 SDK be installed. It is also possible to configure SnipSnap to run under the Apache webserver or as a WAR (Web Application Archive).

Installation was relatively straightforward — in fact most reasonably competent computer users would have no trouble installing a copy to their own machine to tinker with, though doing so turns the machine into a web host. For computers behind a firewall, unauthorized intrusion should not be an issue, but if you are unsure of security concerns that attend hosting, you should check with your technical support staff. Some basic familiarity with JSP (JavaServer Pages) is useful if you wish to customize the behavior of the SnipSnap instance or modify its user interface, and familiarity with CSS (Cascading Style Sheets) and basic HTML is required if you'd like to significantly modify SnipSnap's appearance.

The only modification we made to SnipSnap's basic install was to strip away a 'delete page' function, which we accomplished by removing the button enabling this feature. This meant that only the instructor was able to keep order on the site and remove botched entries, while students were protected from inadvertant deletion.

Technical concerns

For the most part, any technical difficulty that cropped up with RAP had to do with the documentation of this open-source software and its uneven state of development. SnipSnap is a work in progress, with the attendant glitches and undocumented or nonfunctional features that implies. In addition, its developers are not native English speakers, though they provide documentation in English. This language gap, in combination with the lack of strong editorial control of the SnipSnap home site (itself a SnipSnap instance), made it difficult to track down answers to technical issues that arose during RAP's deployment.

One can actually infer one of the primary weaknesses of wikis from this, and there's a small irony to enjoy here: when poorly managed, a wiki can evolve into a soup of tenuously related pages that are difficult to use, especially in comparison to a 'traditionally' authored, linear work.

Despite these drawbacks, SnipSnap has proven a steady and user-friendly platform, not only for RAP but also for wikis supplementing two other seminars at Bowdoin College. We have had to update one component of the application during the time RAP has been running for security purposes, but aside from that tweak RAP has been self-sustaining. Most important, we never experienced any instability or data loss events. That has not stopped us, however, from wishing for improvements to SnipSnap.

FIG. 1 — A chart by David Hamilton, compiled in late 2002 as we were choosing RAP's engine, compares features of four different wikis.
[Enlarged image and live page link]

 

FIG. 2 — Wikis are in constant development. A matrix lists fully and partially developed features of SnipSnap as of July, 2004.
[Enlarged image and live page link]

 

[Top of Page] | [Table of Contents] | [Works Cited]