Distance education. Distance education presents unique problems for both instructors and students. For one, many distance learning problems were designed to fit the conception of the university as an information delivery service. As Brown and Daguid (2000) have criticized, schools do much more than pour information into the empty heads of waiting students. Schools are also responsible for enculturating students into a professional discipline. Yet, without assistance, distance learners are left without the opportunity to richly interact with their peers and instructors. Despite the promise of the Internet to address this need, most approaches from course websites to such complex web applications as WebCT?, BSCW, and CCNet focus merely on disseminating course materials, lesson plans, lecture notes, and offering occasionally minimal testing services. The bias in these designs focuses primarily on the original model of school as information delivery services, leaving out the critical interactions between instructor, students, and students with each other.
It is true that many of these services provide hierarchical discussion boards as a means to facilitate online conversation. However, in practice, students routinely ignore these facilities for a number of reasons. Most acutely, if the instructors do not respond online, then discussions online are not economic; when there are two classes of students, distance and in person, the online discussion (with the distance learners) is often secondary or perceived as secondary to the main interaction; and the format of discussion boards favours a question-answer approach that is not flexible enough for many types of conversations, such as collaboration.
To address the growing recognition for collaboration in the distance classroom, many novel approaches have been tried. Many have focused greatly on synchronous media such as online chats, teleconferencing, or videoconferencing, where participants are simultaenously present and therefore conversant. However, given that most distance learners are part-time students who have busy work and life schedules, synchronicity is not always possible. Further, much academic work is reading and writing that does not require nor desire simultaneity with peers, such as reading course materials or writing papers. Yet increasingly we find coursework that demands collaboration between students for even these asynchronous tasks. While the common approach is to coordinate with other peers through conversations, little thought so far has been given to supporting the primary solitary text-based tasks. Thus, there exists a gap in the research for developing tools to support asynchronous text-based communication.
Weblogs. In that vein, recently much interest has been given towards adopting weblogs (colloquially, blogs) in the classroom environment. Weblogs are the online equivalent of journals. At their most fundamental level, they are a sequence of entries, chronologically ordered, typically (though not always) authored by a single individual. Additionally, readers can automatically aggregate as many weblogs as they would like into one place, building a personalized reading environment that Negroponte (1996) has coined The Daily Me. As a tool that greatly eases writing and publishing, weblogs have made it very easy for students in classroom to have their own voice that other students, through the aggregation ability, can track over the course. Many courses use them to disseminate the students' research notes from reading to reading, for instance.
Weblogs have the disadvantage of being owned primarily by their author, making collaboration very difficult. If feedback is available, weblogs typically resort to the default and limiting discussion board conversation format centred around each entry. This constrains a reader's ability to branch off with their own idea and make something of it, let alone make a correction, addition, or change to a weblog entry itself. The weblog remains truthfully the author's and the author's alone.
Wikis. Another technology that is growing in popularity over the Internet are wikis, now with millions of installations. The first wiki (Cunningham, 1995) was a very simple creation characterized not by its features by rather by the lack of features that get in the way of social interaction, and most that have come after have mirrored this simplicity. A wiki is merely a website where the full text of every page is editable by anybody, and pages are only created by the behest of participants. Unlike traditional web page authoring, however, wikis do not use HTML markup but instead use a simple text markup that feels much like the way we write typical e-mails. Further, each page is given a unique name, so that links between pages are created automatically when a page is simply mentioned, simplifying linking. The system as a whole maintains integrity by being resilient to mistakes and malpractice, such as maintaining revision history of every page so unwanted changes can be undone as well as a central page called Recent Changes that tracks each change so that peers can maintain a watchful eye on the site.
Wikis present a great potential change from the traditional approaches to online courseware, such as WebCT?. Rather than information flowing from instructor to student, information in a wiki is perpetually in negotiation between each participant, much like any conversation or any collaboration. In courses where deep constructive interaction between students is necessary, for instance many at the graduate level, a wiki presents a more intuitive structural model than other approaches. Students can begin by sharing knowiedge, lecture notes, and reading notes. They can discuss the notes openly by adding more notes. They can then relate these various notes by linking them together. Finally, because all the text is editable by anyone, they can condense these notes into meaningful conclusions. The power of the last point should not be underestimated, as the typical approach to writing documents collaboratively is the ever painful pass the baton relay approach of e-mailing MS Word documents from student to student, often the night before the report is due. A wiki centralizes the document in one shared place where all team members can then work on it at the same time, whilst keeping an eye on the other team members to synchronize thoughts or to watch for quality (a major concern in groupwork).
Typical applications in a classroom might include creating a class-wide annotated bibliography, writing group assignments, asking and answering questions about assignments in a central location, and preserving knowledge from one class to the next.
Academic adaptation. The original wikis like most web technology originated from software developers for software developers, and as such are not necessarily perfectly adapted to the needs of other constituencies. Using an existing open source wiki in an academic environment will require some modifications. For instance, for an annotated bibliography, support for academic citation styles is a must. Additionally, support for the hyperlink academic citation style know as the Open Citation standard would be a great advantage. Further for cultural reasons, wikis have perennially prided themselves on an author-less style that has not emphasized keeping track of who did what on the site. However, in an accredited class, students must be evaluated, so their individual contributions must be somehow tracked even if they all eventually blend together in the universal editing melange that is a wiki. Keeping logs of each participant's activity as well as a record of his or her specific contributions is a necessary addition. Finally, the wiki will need to be adapted to fit into the wider framework of the school's existing courseware, if at all possible.
User-centred design. The need for adaptation highlights a critical problem: with the introduction of any technology into the learning environment, instructors may lose control over their teaching style because the introduced technology forces them to behave in the way its developers have decided. For instance, as mentioned, discussion boards favour a question-answer format. The more complex the technology, the more design decisions are embedded in the software, the more the instructors and students have to adapt to. For many types of courses, particularly those at the graduate level, this degree of control is not desireable. An alternative approach is needed.
One strategy is to only introduce small, lightweight tools that are easily adapted and adopted into the natural flow of instruction in the class, rather than heavyweight tools that force the flow of instruction to adapt and adopt to them. Perhaps for this reason weblogs have been so attractive to many educators, since their unobtrusive design gives control over how the tool is used back to the people in the class. Wikis are equally lightweight, perhaps even more so as they do not even impose the chronological structure of weblogs. Their primary form of organization is social rather than technological as they do not structure the workflow or interaction between participants in any way. Further, creating new wikis or manipulating data within wikis is not overly difficult, so participants are free to restructure the larger organization of the wikis. Finally, since wikis are thin and pliant, they work well in concert with other online tools that may be part of the online education environment.
Another strategy is to develop the technology in tandem with the instructors and students in the class. The participatory design school has widely emphasized the value in incorporating the actual users of the software into the design process. Just as instructors and students are fully competent and adept at manipulating and integrating paper-based materials (e.g. handouts, flipcharts, index cards) into their natural flow, ideally the software should be as under their control as possible. While in typical practice this is accomplished by the lack of controlling structures limiting users in the wiki, clearly new features, interface changes, or other adaptations require developer effort to enact. As such, having a dedicated developer is a must.
Over the course of the summer, an existing open source wiki (UseModWiki) will be upgraded to the minimal feature set necessary to facilitate a class:
The wiki will then be used by a class of graduate students studying distance education for a semester. They will be invited to join in the design and evaluation of the wiki. A designer and developer will work with the students and the instructor(s) to develop the wiki to meet their needs.
Of course, the wiki will be irrelevant if it is not used as part of the coursework, and therefore ignored. Students will be asked to create an annotated bibliography of their readings over the course using the wiki. If the instructor chooses, this can be an actual evaluated assignment for the course. The annotated bibliography will progress in four phases.
Clearly having only one course evaluate the tool in the compressed timeframe of one semester has a great deal of risk, but in practice, students will always be expected to grasp the software in this timeframe anyway. The greatest risk is really the influence of the expert developer on the participants. Participatory design techniques control for this.
The other major risk is the degree of involvement of the distance students. The developer will have to use separate design sessions with these students, and the instructor will have to ensure the wiki is the central place for work on this assignment. Given the nature of the assignment, however, it seems unlikely in person students will have hallway discussions about it.
The primary outcome will be an improved wiki that is better adapted to a graduate level academic course, specifically for the task of creating a collective annotated bibiography. Secondary outcomes will be an ethnomethodological usability analysis of the entire system as a whole. Undoubtedly not all wishes by the participants will be fulfilled by the developer in the time alloted. Finally, the collective annotated bibliography will be an outcome.
The first metric is the completion of the minimal feature set by the beginning of the course. If the course begins in September, 2005, this gives the developer six months to complete the features, which is more than adequate.
Measuring the general success of the wiki will require adoption metrics and assessment metrics.
The wiki itself is open source. The only real costs will be the developer and instructor times to be negotiated separately.
to be completed