Wiki wishlist

Dreaming on

All in all, our assessment of RAP's effect resonates with other preliminary identifications of wikis with student collaboration and a sense of ownership. Additionally, we credit an upsurge of student output and involvement in the course subject matter to this tool. We consider the implementation and use of this wiki to be a success for the instructor as well as his students.

SnipSnap, in particular, proved a good wiki platform, and after RAP we subsequently reemployed it for two other seminars at Bowdoin. We will consider using it again in the Spring of 2005, when its associated course is taught again. Open-source software development progresses rapidly, however, and we plan to once again assess a range of engines for RAP2.

The virtues of SnipSnap led us to choose it above other wikis in 2002; these virtues include general simplicity and elegance, flexible navigation, and proven stability. Such features have not stopped us, along with students, from developing something of a wishlist, and as we move to RAP2 we will be scanning available wikis for the following additional features:

Instant messaging. This was the number one feature request from students. Such a feature would link posting mechanisms to student instant messenger clients so that when someone links to or comments on an entry, the original author of the entry can be notified in real time.

Communication profile control. Extending the notion of keeping students 'in the flow,' and taking it beyond just instant messenging, we would love to alert users to changes in their wiki space. It is technically possible to send changes to posted entries to an author's email address, to their instant messenging client, or even to their cell phone's text messenging environment. Such alerts seem likely to stimulate an even greater level of active participation.

RSS feed. We'd also like a wiki to offer RDF Site Summary (RSS) content aggregation. Compiling excerpts of fresh entries in the system, XML-based feeds would offer class members a running index of fresh material in the wiki on an up-to-the-moment basis. Students with an RSS reader (increasingly common as a web browsing device) could subscribe to the wiki's RSS feed, allowing them to track changes and scan summaries of new content on the site.

Visualization tools. Toolsets like Touchgraph can help users visualize a wiki 'dataspace' (see Fig. 1). This graphic presentation can help users of a wiki get a feel for the scope of its content, the relationships between seemingly unrelated entries in the wiki; with such visualization, connections that might not otherwise get noted could present themselves.

Usage statistics. Such metrics would help to highlight and reward student entries that have been most useful to the class. Other wikis offer assessment tools that show users which pieces of content are most heavily read, which are most often linked to, and which are most commented upon.

Category control. It would be helpful to mark various entries according to type, to counter dispersion and facilitate later reference. In particular, it would be useful for RAP to distinguish poetry text entries, instructor pages, image pages, and student-authored entries from each other; in SnipSnap they were technically indistinguishable.

Linkback. One drawback of SnipSnap was its one-way linking structure. It was difficult to track student entries back to the poems they commented on, unless students took the time to build 'anchors' to passages of poems and then linked to these anchors in their entries. Ideally, a wiki would allow visitors to see an automatically generated list of all pages that link to a given page.

Concurrency. RAP supplemented a small seminar (eight students), so we never ran into a problem with two users trying to build links in the same entry at the same time. But it would have been nice (and comforting) to be able to 'check out' a page, so nobody could unintentionally wipe out an edit in progress.

Browser compatibility. The version of SnipSnap that runs RAP does not render properly on all major browsers; in particular, its style sheet rendering fails on Macs running Internet Explorer. Though it was easy for us to work around this issue, outside visitors could be put off and puzzled by this design flaw.

FIG. 1 — A visualization of interconnecting pages from Tinderbox, a personal content management system sold by Eastgate Systems.
[Enlarged image and live page link]

 

FIG. 2 — Visitors to PhpWiki list ideas for features to be added to the program.
[Enlarged image and live page link]

 

 

 

 

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