25.3: Wiki Technology for Online Education
- Page ID
- 88843
by Richard S. Lavin & Joseph Tomei
“The parts are the tools within the whole, they make sense only in the unity of the whole, every single organ performs its intended goal for its organism and this intentional functionality is not situated outside of nature but its value lies within it”. – Alexander Neuer, 1936 (Stein, n.d., Alexander Neuer, para. 2)
Introduction
Wikis are collaboratively editable websites that can be used for various purposes. They are particularly well suited to taking students who are already competent bloggers to the next level.
From weblogs to wikis
For many contexts blogs may be the tool of choice, and sufficient by themselves. As we have shown in the previous section, they can be used for a wide range of purposes and can foster reflection and communication among students, classes, and institutions, and thus they can move us in the direction of learning communities.
There are cases, however, where blogs alone may be limiting. There may be a need to bring older blog posts to the forefront, to build on earlier discussions or knowledge. Of course, this is always possible, through an archive search, followed by copying and pasting into a new post or linking to the old post, but blogs, because of their temporal organization, are not ideally suited to such use. It will sometimes be desirable to have a more-or-less complete snapshot of the state of knowledge built up over a course, possibly several iterations thereof. Again, the teacher could conceivably write a summary linking to key posts that contribute to such an understanding, but this would be an inefficient use of a blog, and that summary post would again be pushed down the stack as new content was added.
In such cases, we suggest that wikis provide an answer, if taken with “a measure of caution” (Tomei & Lavin, 2007, p. 26). Wikis are free-form, collaboratively editable websites, designed to work with a minimal set of simple markup commands rather than the more difficult HTML. Content can be arranged in whatever ways make sense; and, since wikis are simple, they can be edited as needed. Although wikis can be used as standalone websites, independently of blogs, here we are interested in the possibilities for complementing blogs. A wiki could be used to archive key blog posts in an easy-to-find organizational scheme, together with extra details or commentary. Alternatively, it could be used as a database of background information to raise the base level of the blog discussions.
It is their collaborative editability, however, that makes wikis such powerful tools, potentially enriching students’ interactions and fostering cooperation and collaboration inside and outside the classroom.
What are wikis?
In the preceding section, we gave an informal definition of wikis. Before discussing how to use them in more detail, let us attempt a more rigorous definition, which may serve to clarify their uses, strengths, and weaknesses. Wikis may be defined as instantly updateable, collaboratively editable, radically hypertextual websites. Let us take a look at each component of this definition.
“Instantly updateable” means that there is no need to edit a local copy of a website, upload the new version, and then reload the new version in a browser. Though such a process is not difficult, it is just enough trouble that countless small-scale websites remain untouched for long periods of time. (Teachers reading this may be familiar with the leave-it-till-the-end-of-term syndrome.) With wikis, it is enough to click the Edit button, correct a typo or change a deadline, for example, and then press Save to implement the change.
“Collaboratively editable” means that there can be multiple authors of a website, possibly at multiple locations, or people other than the authors who are able to make changes. This is the feature that is of most interest to us in this chapter, though it is best to keep the other features in mind.
When Tim Berners-Lee devised the original specifications for the World Wide Web (Berners-Lee, 2000), he envisaged that everyone would publish and edit information, rather than just read pages and click to follow links. Instead, for a time the Web became something like a “glorified television channel” (Berners-Lee, 1999). Wikis started the move towards a web more in line with Berners-Lee’s vision.
Consider a standard hyperlink on a web page. In the absence of specialized software, you need to use a moderately complex code to create it. It points to a whole page, which may be quite long, and you may have to do further searching within the page for the information you want. The destination page does not point back automatically to the originating page, so if your browsing had taken a different route you might never have discovered the connection between the two pages. And if you link to something that does not exist, you get an error message.
Hypertextuality means that links are two-way rather than one-way, so you can find your way back to pages you have looked at before and also to pages that link to the page you’re on. (This is essentially the same technology as blog track-backs, discussed earlier.)
Links can point at small chunks of information, rather than whole pages; and information can be organized freely, without resorting to hierarchical structure based on directories and sub-directories. Most importantly, as long as you know the name of a page, you can link to it without knowing where it is within the wiki. The system used in most wikis is known as CamelCase, as, in addition to an initial uppercase letter, CamelCase words, otherwise known as WikiWords, feature a hump or humps of intermediate uppercase letters.
This does not apply only to pre-existing pages; new pages can also be created using the same syntax, meaning that it is very easy to expand on existing information, and even add whole new categories of information. This is why Klobas (2006) suggests that the Berners-Lee dream of a fully interactive web may already have been surpassed, thanks largely to wikis.
Wikis and Wikipedia
Since Wikipedia is now the best-known wiki in existence, it may be useful to take a closer look at wikis through the lens provided by Wikipedia, noting features that are in common with other wikis and those that differ. Most readers will probably have heard of Wikipedia. It is a large (more than 1,800,000 articles as of June, 2007), multi-lingual (fourteen languages with more than 100,000 articles, and more than 60 languages with smaller numbers), freely accessible to anyone with an Internet connection, and, more radically, freely editable, in principle, to anyone in the world.
Thus, anyone who finds an article with factual or typographical mistakes can rapidly correct the mistakes. Similarly, if an article exists but is incomplete (many of these articles are marked as “stubs”) anyone with knowledge of the topic can add details or links to further resources. As long as this is done with a sense of responsibility, students who contribute in this way can justifiably feel they have made a real contribution to human knowledge, if only in the sense of making knowledge already available in one place simultaneously available in another, more central, location.
Wikipedia can be said to be typical of wikis in the sense that there are generally no specific software controls over who can change the wiki (except that certain IP addresses that have been identified as the source of malicious changes are excluded, but only after a process of consideration by members of the community). It is atypical in the scope of its subject matter and in the size of its target community. In fact, since most communities are partially defined by whom they exclude, the Wikipedia community is very unusual since potentially it includes all humankind (though in practice, of course, some may never hear of Wikipedia, some may not be interested, and many, for economic or geographical reasons, may never have access).
The other major wiki that we will mention is Ward’s Wiki, the wiki created by Ward Cunningham, the inventor of the first wiki engine (found at http://c2.com /cgi/wiki?WikiWikiWeb). This wiki’s subject matter (People, Projects, and Patterns in Software Development) is rather esoteric and may hold little interest for most people. However, its discussions on thread mode and, more broadly, on wikis, how they are used, problems with wikis, how to choose a wiki engine, and so on, are most valuable. In addition, Cunningham has resisted the recent trend to add features to wiki engines, consistently favouring simple code and a minimal feature set. Thus, this wiki functions as a useful reference point when comparing wiki engines or when defining what is often termed wikiness.
It might be overstating the issue to claim that these two wikis represent the alpha and omega of wikis, and all other examples would fall somewhere between them, but they serve as two useful poles of wiki development, that of a constantly evolving and growing set of pages and users and a smaller, more focused, and maximally simple wiki that might help you understand the tension between the two poles.
Introducing Wikis to Students
The nuts and bolts of choosing a wiki engine to install oneself, or a wiki hosting service to make the installation unnecessary, is dealt with in greater detail in Chapter 26, Techno Expression, so we will avoid details here. We will instead focus on the practical and pedagogical issues once the wiki is installed and ready to use.
The nuts and bolts of choosing a wiki engine to install oneself, or a wiki hosting service to make the installation unnecessary, is dealt with in greater detail in Chapter 26, Techno Expression, so we will avoid details here. We will instead focus on the practical and pedagogical issues once the wiki is installed and ready to use.
We should emphasize first, though such warnings may be unnecessary, that simply creating a wiki site and telling students to “interact” (or “collaborate”, or “play around”) on the site is unlikely to work satisfactorily, unless students are very mature and self-motivated and they have a lot in common, or a ready-made purpose in the nature of the course. Whereas it is fairly easy to start students blogging by describing a blog as an online diary and asking students to introduce themselves or write about what they did at the weekend, such an obvious entry point to wikis does not exist. Since processes are best explained in terms of steps, and problems are best solved by breaking them down into sub-problems, we shall take a closer look at possible difficulties with wikis in the next section.
Wikis are not easy
For inexperienced learners, wikis may be a difficult tool, and therefore it may be difficult to create the conditions where they lead to real engagement. In addition to general computing skills such as typing, copying, and pasting, the major characteristics of wikis given above point to possible areas of difficulty.
Initially, it may take some students a long time to get used to the simple but radical idea of instant updateability. They may not notice the Edit button, for instance, until it has been pointed out to them several times. Since they are not accustomed to web pages being editable, their eyes may at first gloss over the editable window in the centre of the page as they search for something recognizable as a database field to fill in.
Collaborative editability represents a complex melange of technical and social issues. Students may resist the very idea of touching someone else’s work without specific permission or conversely be offended when someone touches theirs. Even when they have become accustomed to the Edit button, it may not occur to them that it is possible and permissible to actually edit existing pages, or even sentences and paragraphs, and they may restrict themselves to making new silos with their own personal content. Thus, it is advisable to be ready to give extensive instruction to students in these possibilities, along with guidance on any restrictions you wish to impose.
Finally, the radical hypertextuality of wikis can cause severe disorientation. It may take students some time and considerable guidance to master the mechanics of making links. Even then, it may not be possible for all students to grasp the structure of the wiki as a whole, resulting in difficulties fitting in new content and linking it to other relevant pages.
Blogs as an entry point to wikis
Our own experience with weblogs and wikis has led us to conclude that weblogs can act as an entryway into using wikis by establishing a firm foundation for learners. Some of the skills necessary for wiki use that can be established by regular use of weblogs are as follows:
- manipulating computer text (copying, cutting, pasting),
- using tags and understanding how they work,
- writing short coherent paragraphs of content,
- commenting on others’ work,
- linking to external sources, and
- linking to internal sources (within the weblog).
These skills may seem so basic as to need no introduction, but we have found that even groups of sophisticated learners, when placed in a new environment, often transfer only some of these skills, and then only fitfully.
Using Wikipedia and other global wikis
Since most students will probably have heard of Wikipedia, and many may have experience using it for reference, this may be the easiest entry point. The teacher could find a page on a topic of interest to the class and show the present version and selected older versions for comparison. If there is a live Internet connection, the teacher could find a page with typographical or minor factual errors and correct them in real time, explaining that anyone throughout the world can now benefit from the new version. If students are deemed ready, and of course with appropriate supervision, they can be guided to pages that they can improve, and be invited to make minor edits. This should be sufficient to demonstrate that wikis are valuable tools.
If Wikipedia is considered somewhat forbidding, there are other global wikis that allow students to improve the world in some small way by correcting faulty information or, more commonly, providing missing information. We shall introduce three of these here: Wiki Travel (wikitravel.org), Wikia (wikia.com), and Wikibooks (wikibooks.org).
When we were looking for a simple wiki-based project to excite our tertiary EFL students in Japan, we were delighted to discover that Wiki Travel had no mention of the students’ home area of Kumamoto. Although the students’ writing proficiency is fairly low, as are their technical skills, they were able to create this section and provide some useful information to prospective travellers. The fact that there was no existing information lowered the stakes, since any information they could provide represented an improvement. They were delighted when other Wiki Travel users from around the globe corrected some of their linguistic errors. Subsequent cohorts were surprised to discover that the Kumamoto section had been created by their seniors, many of whom they knew personally, and were pleased to be able to build on their predecessors’ work.
Our students’ experience with Wiki Travel also points to some potential pitfalls with projects of this kind. One of the Wiki Travel guardians at one point asked us to make sure that students’ work was corrected before posting in the wiki space proper, since the majority of articles are quite polished. They suggested that students’ personal pages within Wiki Travel would be a better place to host relatively raw work, prior to polishing, perhaps via peer editing, and moving to the wiki space proper.
Wikia, formerly known as Wikicities, features thousands of wikis on specific topics. Many of these are related to places, and the focus differs from that of Wiki Travel in that they are not aimed primarily at tourists but typically at providing a convenient information source for residents. Places that do not have enough articles to make it worthwhile creating a separate wiki can have an entry in the Towns, Villages, and Cities wiki. Most wikis on Wikia are still in their infancy. This lowers its value as an information source, but at the same time maximizes its potential for student projects.
Wikibooks is an attempt, launched in 2003, to provide textbooks on a whole range of subjects, and as of June 2007 there were over 25,000 English-language wikibooks available, in various states of completion, on topics ranging from organic chemistry, the solar system, and quantitative finance, to bartending, Turkish, and table tennis. A smaller number of modules in an assortment of languages are also available. Wikibooks are divided broadly into Wikijunior books (aimed at ages 8– 11), Wikistudy books (typically aimed at secondary education examinations), Wikiprofessional books (typically aimed at those preparing to sit professional examinations), and Wikiversity books (all others, with an emphasis on the idea of lifelong learning). Since the wikibooks have a very serious purpose, any project aimed at improving any of them should have a similarly serious intention.
An example of such a successful project is the Rhetoric and Composition Wikibook started by Matt Barton and his students in a composition class, announced on Kairosnews (Barton, 2005a), and further explained on Barton’s website (Barton, 2005b). The wikibook is for students in first-year university composition classes, and thus represents a case of near-peer role models creating course materials, tempered by collaboration with instructors. As of this writing, the book is available online for editing and also as a free PDF download (http://en .wikibooks.org/wiki/Rhetoric_and_Composition).
Other simple wiki projects: conventional website plus
The fact that wikis have great potential as collaborative writing tools does not necessarily mean that they must always be used in this way from the outset. One way to get started is for the teacher to use a wiki as, at least initially, a conventional website. This could include the syllabus, assignment deadlines, and useful resources. An opportunity to show students that the site is not quite like the ones they are used to is presented when an error (strategically inserted beforehand if necessary) is discovered during a class meeting, or if a deadline is renegotiated, for example. Far more powerful than a promise to update the site later is to instantly correct the error and show students the new version on the spot. Taking this a little further, when during a class a new concept is introduced, the teacher could create a link to a new page introducing the topic and create a two- or three- sentence page stub on the spot.
Once students have had a chance to see a wiki in action, its collaborative editability may not come as such a shock. The teacher could prepare for a class meeting by creating an Introductions page, containing links to each student’s name (typically a full first name, followed by the initial letter of the surname, such as RickL, or JoeT). Students should know that the page will not exist until they click on the link.
The above example can be taken as far as necessary. If the teacher notices that several students have the same hobby, she could create a page devoted to that hobby, with a descriptive title such as TrainSpotting or ReadingBooks, and show students how to link to the page with minor changes to their own sentences; for example, simply changing I like reading to I like ReadingBooks. As a simple demonstration of the power of the richer model of hypertext employed in wikis relative to the Web at large, teachers could show how the back-links to the ReadingBooks page constitute a list of all students who like reading.
In this way, apart from giving students a painless introduction to wikis, any divide disappears between the official course website and the course wiki as a new tool to be understood (and a new URL to be remembered). It also constitutes a very low-risk strategy, as not very much depends on successful completion of any wiki-based assignments, and in any case none of the assignments mentioned is difficult enough to make failure likely.
Even if students do not take to the wiki, the teacher has discovered an approach that may revolutionize his approach to lesson preparation and course re-tailoring. Because the wiki is instantly editable, any lesson plan that is overly optimistic about the amount of material to be covered can be changed immediately for the following iteration of the course. If the teacher is worried about unauthorized edits, she can write-protect the wiki. If she wants to keep the content secret, she can read-protect it. If she wants to have certain sections such as quizzes protected, and others editable, this is also possible, depending on the wiki engine.
Wiki Foci and Processes
Although it is possible to use a wiki without any specific problems, it is useful to have a grasp of some of the already existing conceptual work. This can also help you get more out of wikis.
Wikis imply engagement with ideas
Typically, where a team of people is working on creating a knowledge base of some kind, a wiki implies engagement with information and ideas more than with people, though of course it was ultimately people who produced those ideas. Interaction will generally need to be focused on creating a product, however tentative, and this implies a degree of sophistication on the part of the learners.
It is interesting to compare wikis with discussion forums. A discussion forum emphasizes engagement with others, making it easy to engage in friendly communication that may or may not be related to the main topic of concern. Substantive debate is also possible, but, crucially, the debate is a kind of meta-dialogue, that is, talking about something, but often not creating anything new in a systematic way. A participant is more likely to say “I think you’re wrong about that, because …” than to say, “I think you’re wrong about that; instead, I would say …”. Hewitt (2001) found that it can be very difficult with discussion boards to pull disparate threads together, as one message may simultaneously address multiple issues. Without extra synthesizing steps, for which discussion forums fail to provide specific mechanisms, valuable contributions can be lost before they have been understood for what they are. Reinforcing what we said in the previous paragraph, since a wiki is focused on product (an actual collaboratively generated version of a text), engagement is with ideas, even though those ideas may have been produced by others. As Jennifer Claro suggests, wikis are a cognitive constructivist tool in the Piagetian sense, in that they create knowledge from within the learner rather than imposed from outside by the educator (2005, personal communication).
Any activities requiring use of a wiki will typically have to be carefully tailored to learners, and possibly the wiki should be seeded with templates to provide some kind of structure to make exercises easier. Mind mapping or flowcharting can often help students develop a structure.
Thread mode for communication
People now are accustomed to seeing Wikipedia as representative of wikis in general. Since Wikipedia is designed to present a friendly face to people visiting briefly to get specific information, it tends to obscure the writing processes that produced the apparently finished article on view. To see what goes on behind the scenes, you can click on the tab labelled discussion. What you will find may be enlightening, and perhaps a bit frightening, especially in the case of contentious topics.
However, the earliest wikis were commonly used in thread mode, where a signed contribution at the top of the page is followed by another signed contribution responding to the first, and so on. When a wiki is used in this way, the point about ideas and information being favoured over people may become invalid.
At first sight, this threaded mode may appear to be no more than a discussion forum without many of the functions we have become accustomed to. Yet it has the trivially easy hyperlinking features of wikis, which allow one to refer to other discussions easily. Most importantly, it has the potential to be transformed from thread to document mode.
Where discussions need to take place, but the wiki proper needs to serve simultaneously as a resource for others, users would typically make use of the discussion feature mentioned above, which is now a fairly common feature across wiki engines. Sometimes, this appears in the guise of a comments feature; in WackoWiki, for example, comments are appended to the bottom of a page, in a separate space. Users can choose whether to show or hide a page’s comments.
Direct transformation over meta-dialogue
Wikis are sometimes seen as less desirable for discussion than discussion forums. This may well be the case when discussion is the sole or main purpose of instruction. As we have mentioned, the standard mode of use is to attempt to create a page that is a product of some kind, however tentative its status and however many more iterations may appear in the future, as the scenarios below may illustrate.
An advanced user, B, when finding a page authored by another advanced user, A, may, while respecting the intentions of A, alter the text to reflect B’s concerns in addition to A’s concerns. In many cases, A will infer the intentions of B from the changes, and this understanding forms the basis of a continued collaboration, with A and B engaging in true co-authorship. When users are able to see the creation of a wiki page as a social process, in the sense that they are able to imagine the intentions of their co-authors, wikis can become a social constructivist tool. Of course when co-authors disagree, they may choose to make a phone call or launch a discussion by email, for example; however, in general it seems to us that a large part of wiki interaction consists of a kind of tacit debate, where the debate is in a sense encapsulated in the version changes of the wiki pages. It further seems to us that this is a very efficient way of working and that it would be wrong to conclude that the lack of meta-dialogue is necessarily a deficiency, although it may mean that much wiki work falls outside the scope of strict definitions of collaboration (see Chapter 28, Online Collaboration: An Overview).
A technologically unsophisticated user D, encountering a page authored by a user C, may in many cases feel too intimidated to alter the text in any way and may instead create a totally new page. If this is titled User D Perspective, for example, this may be an entirely appropriate strategy. If the pages largely overlap in content, though, and if the relationship between them is not indicated, it creates a redundancy which may never lead to real engagement between the two users, since the wiki does not have the structures in place to push users towards discussion; or rather, although wikis can easily support discussion, this functionality is not foregrounded by default. The emphasis is very much on creating pages, which are works in their own right, ready to be read profitably by others.
Thus, it may be better to avoid wiki exercises with non-advanced users or to make the exercises very limited in scope and pre-structure the wiki to some degree.
Product over process
While co-authoring a wiki page can be a highly collaborative and ongoing process, each time a page is saved it becomes a product. Although this product has the potential for future development, it is nevertheless very much a product in the eye of the casual visitor, and there is an unseen pressure on the authors to make it a “real” product on each page. Although much depends on the purpose of the wiki and the context surrounding its creation, in general the product aspect can be considered as being foregrounded, and this has a subtle effect on the dynamics of the process and the interaction between users. It is up to teachers to decide whether or not this is a positive thing. In general, we consider it overwhelmingly positive, as it focuses attention on incompletions and imperfections.
Note that this does not mean that all problems have to be solved definitively. However, they do have to be acknowledged and defined as far as is practical, and this opens the way for future attempts at completion.
From thread to document mode
It is with relatively sophisticated users that wikis may come into their own, when teachers encourage the use of thread mode initially, but also encourage a process leading to a product in document mode (Bruns & Humphries, 2005; Morgan, 2004). In other words, at first learners respond to each other’s ideas on the page as if the page were a thread in a discussion forum, but gradually begin to take ideas from other contributors, from various parts of the page, and merge them into a partial summary or reconciliation of different viewpoints. These summaries serve in turn as raw material for others to summarize or exploit in other ways to achieve a higher synthesis.
“Wiki goes meta—almost naturally.” (Morgan, 2004)
In this process, even signed comments lose any clear authorship and become material for the co-authored text that emerges. Though this process can be difficult to achieve, it is arguably the highest form of collaboration, and serves to demonstrate advantages of wikis over more fully featured threaded discussion forums.
Extended Wikis
As mentioned above, wikis are not easy to use to their full potential in many educational settings. A large part of the difficulty is a conceptual and attitudinal one. If students do not wish to work together, it will be difficult to use a wiki effectively (Rick & Guzdial, 2006). There may be resistance to the idea of editing another’s text. The number of cases where a satisfying transformation from thread to document mode takes place may be quite limited, except where students are mature and there is a pre-existing culture of collaboration (Chapter 28, Online Collaboration: An Overview).
In addition, there a number of difficulties associated with classic wiki engines that may be overcome by enhancements to the software, and we deal with some of these here. We use the term extended wiki to refer to software that is in general functionality and look-and-feel a wiki engine, yet sports enhancements that take it clearly beyond most wiki engines in certain areas. We do not offer a hard-and-fast definition because, as wikis in general evolve, the functionality that qualifies an engine to be classified as an extended wiki is something of a moving target.
Simultaneous edits
Wikis are asynchronous tools in the sense that there is no requirement to be logged in at the same time as other users. This is on the whole a strength, but classic wiki engines can be inconvenient for in-class use because two users may edit the same page at the same time, potentially causing one user’s changes to be lost, depending on the relative timing of the respective users’ saves. Most wiki engines these days implement some measures to alleviate this problem. PhpWiki, for example, uses special markup to indicate areas where two people have made simultaneous edits between saves, giving the user the chance to reconcile the two versions, usually by merging both edits. MediaWiki allows each section of a page to be edited separately. Neither, however, represents a complete solution to the problem.
Wang and Turner (2004) describe some wiki engine enhancements that they introduced to make wikis more useful and easy to use in their classes. A key one is a simple mechanism to handle concurrent edits: when one student is editing a page and another attempts to edit the same page, a timer appears on the first student’s screen. She is expected to save her changes on the page before the timer ticks down to zero, after which her work will be saved automatically, she will be locked out, and the second student gets priority.
Managing cohorts
It is arguably wasteful for each cohort to start from zero. As in real life, it is generally more fruitful in education if each cohort can build on the work of previous cohorts, with collaboration extending across course and time boundaries. This may not always be very convenient for teachers, however, nor satisfying for students, as it is difficult to pinpoint what a specific cohort has done. Another of Wang and Turner’s (2004) enhancements offers a partial solution, in the form of a snapshot function that can be invoked at the end of each iteration of the course, archiving the state of the wiki at that time.
Course management
There are a number of features that can aid in course management. Typically, a teacher will want to keep some pages un-editable by students (for example, syllabus details), and perhaps some un-viewable by students (for example, future quizzes). With a classic wiki, the standard solution would be to keep such material off the wiki, finding some other medium to archive or display it. More modern wiki engines provide functions to make alternative media unnecessary.
For example, WackoWiki has access controls that can be customized per page. PmWiki and DokuWiki have a name-spaces feature which allows certain sets of pages to be made un-editable or even un-viewable, usually by means of password-protection. Wang and Turner’s engine goes one better by means of a visibility function, reminiscent of Moodle’s hidden function: by switching visibility from false to true, for example, the teacher could create all course quizzes before the start of the course, revealing each one on the day of the quiz.
Media types
Wikis typically are very text-heavy, and in many cases this is a welcome feature when students may spend hours adding pictures, colours, and animations to a PowerPoint presentation, forgetting to prepare sufficient material or to practise what they are going to say. But there may be a legitimate need to include other kinds of media.
Nowadays, many wiki engines can incorporate pictures in some form, usually as attachments that need to be uploaded to the wiki, and then downloaded by the viewer and opened separately. This should be regarded as the minimal requirement, as it is not desirable to require students to keep track of multiple sites or online hubs. Far better is a wiki engine that allows pictures to be viewed within the body of the page. Again, this is no longer a rare feature, but some wiki engines take things further. Of particular interest is WikkaWiki, which allows users to incorporate mind maps created in the open source mapping software FreeMind, in addition to Flash animations. LizzyWiki (Desillets, 2005), an experimental testbed rather than a generally available product, allows files to be attached using syntax similar to that used to create a new page, alleviating one possible difficulty associated with incorporating external resources.
With research students, or those working in mathematics or related fields, UniWakkaWiki may be a good choice, as it supports MathML, for mathematical notation, and BibTeX for handling citations and reference lists.
Output
For many projects, the wiki itself is the result of the work in the wiki, and people who wish to view the work can simply be directed to the wiki’s URL. In other cases, to emphasize the completed product aspect of the project, print output may be desirable. To avoid arduous copying and pasting, some kind of special export feature is necessary. WackoWiki can export documents in Microsoft Word format, while UniWakkaWiki does the same in OpenOffice format. PmWiki has an optional extension that can create attractive PDF documents.
Structure
While the free-form nature of wikis is one of their biggest attractions, there are times when some kind of structural support could be invaluable, for example when there is a need to create a set of pages of similar format, such as tourist guides to a range of destinations. For beginners for whom simply mastering the mechanics of page editing is challenge enough, it may also be helpful to reduce the field of choices as regards structure. When there are few categories of information, some limited form of hierarchical organization may be useful, and similarly linear arrangement of information can sometimes be the most obvious and helpful way to go.
Linear navigation schemes in wikis are commonly called WikiTrails. PmWiki was one of the first popular wiki engines to offer this feature, and an example of a trail can be found in the PmWiki documentation, starting at Basic Editing (http://www.pmwiki.org/wiki/Pm Wiki/BasicEditing). In this case, the creators of the site have judged that someone just beginning to explore the functions of PmWiki might first want to know the basics of editing an existing page, then how to create a new page, then how to create links, and so on. In a course website, you may wish to create a trail of short pages introducing lectures in the order in which they are held, or a series of past quizzes for present students to refer to. An important thing to remember about trails is that they are a secondary navigation system overlaid on the basic wiki structure, and can thus be used or ignored by readers as they wish.
Another helpful feature offered by LizzyWiki is optional page templates. These can be applied to any pages that require them, they serve as a reminder to writers regarding what information to include, and they offer some indication as to suitable length.
PmWiki, DokuWiki, and MediaWiki are three wiki engines that offer groups, or separate namespaces. Consider, for example, a course with four or so major topics, each of which features pages like JohnsPerspective, LindseysReaction, and so on. To avoid ambiguity between John’s perspective on Topic 1 and his perspective on Topic 2, we might create a Topic 1 and a Topic 2 group. Thus, the two pages would become TopicOne/ JohnsPerspective and TopicTwo/JohnsPerspective, respectively.
In a course orientation, or when introducing wikis for the first time, one may have a clear idea of what order would be best for presenting information. One way would be to put all that information on the wiki’s homepage, arranged in headings, sub-headings, paragraphs, and lists. Another would be to put only one link on the homepage, so that readers are pretty much forced to follow the prescribed path. Neither of these methods would be ideal, however, for people looking for more specific information.
Ease of use
QwikWeb offers a wonderfully easy entry to wikis. It functions as a simple mailing list, and this is the facet that can be shown to learners initially. Instead of sending an email to several users, the teacher can simply request that emails should be sent to the stipulated qwikWeb address, which forwards emails to list members. However, qwikWeb is also a wiki. After users are accustomed to sending email to each other through the list, the teacher can introduce the wiki URL and then, for example, offer instruction on how to edit an entry or combine it with another.
LizzyWiki recognizes the problems that many users have handling links, and therefore offers a more forgiving syntax, allowing variants like WikiWord, Wiki_word, and wiki_word to all point to the same page (Desillets, 2005). It also extends this same pattern to uploads, such that entering my_document.doc will prompt the user to locate a file to upload. Equally importantly, it has a mechanism for graceful recovery from link-related errors, providing a button that renames the current page and repairs all links to the page.
Wikispaces goes even further in facilitating error-free link creation, providing a kind of wizard that prompts the user to choose an internal or external link and then, if the link is internal, giving a list of link targets to choose from. In this it takes a cue from VoodooPad, the desktop software based on wiki links that has long recognized the difficulty of remembering the names of all pages to which one might want to link.
Combinations and Extensions
The extended wikis we discussed in the preceding section, though offering certain extra functions not usually associated with wikis, are still recognizably wikis. The software we discuss in this section go beyond wikis in functionality, and in many cases are not based on any wiki engine. Yet they still have the collaborative editability of wikis and take their inspiration from them. The second group of tools examined here, blikis, represents a merging of blog and wiki functions, and we believe these represent an important direction for future development.
Super-wikis and non-wiki collaborative tools
JotSpot is the best known example of what we term super-wikis. Though based in the wiki ideas of collaborative editability and instant updateability, the code is different, and the functionality is an order of magnitude greater. JotSpot has various types of fields in addition to plain text fields, and thus, although it can also be used as a standard wiki, it can also serve as a web application development environment.
Wikindx can also reasonably be considered as a super-wiki. At its heart is a database of reference information in BibTeX format that can be freely cross-referenced like a wiki. Winkindx also contains a writing module that references the database.
Collaborative writing applications such as Zoho Writer, Writeboard, and Google Docs are in essence word-processors with a subset of the functions of a desktop program such as Microsoft Word, but running wholly on the Web and allowing multiple users to work on the same document. For more structured data, tools like Google Spreadsheets or Zoho Sheets can be a useful alternative. To a large extent, these tools solve the limitation common to most wiki engines that prevents them from being used for synchronous collaboration, saving any change automatically and almost instantly.
Blikis and Drupal
We argued in the preceding section that blogs are a suitable general-purpose CMC tool for most purposes, and that wikis are best supported or preceded by blogs. An exciting recent avenue of development is software that combines the two types, which we shall refer to generically as blikis, though other terms such as wikilogs are also sometimes used.
While blogs typically are suited to quick noting of thoughts and experiences, the writing in wikis tends generally to be the product of deeper reflection, often processing a number of ideas at the same time and coming to a kind of synthesis. In many usage scenarios, a wiki will incorporate many ideas or pieces of information that have previously been talked about on the writers’ blogs. If this is the case, then it makes sense to link the two together in software, rather than leaving writers to trawl through their blog archives looking for material.
There are several different approaches to blikis, which reveal interesting differences in the developers’ views regarding the essence of blogs and wikis. Here we shall look at a few specific examples.
Wikilogs (http://webseitz.fluxent.com/wiki/) take a wiki as a base and incorporate weblog entries as a special kind of wiki page, named with a yyyy-mm-dd format date. Thus, a subset of the wiki entries is arranged in reverse chronological order like a blog but, because those entries are within the wiki space, they can be referred to easily by other wiki pages, some of which will be topical entries building on the blog entries. Likewise, PmWiki is a conventional wiki engine that allows the creation of blog entries through extensions.
Both the above examples are clear cases of wikis with blog-like features added on. TiddlyWiki (http://www.tiddly wiki.com/) and its many derivatives are rather more platform-neutral, though they are still located on the wiki side of the fence. Items (tiddlies) are small chunks of text rather than whole pages, and a sidebar offers flexible options for viewing content either chronologically or according to content tags or keywords associated with items.
It is possible to have a separate wiki and blog, but linked in a way that approaches bliki functionality. For example, people signing up for an edublogs blog (http://www.edublogs.org) are given a free wiki on Wikispaces. The customized WordPress Multiuser administration controls have a special Wikispaces tab, while Wikispaces admin has a WordPress tab, and wiki updates are usually posted automatically in the blog sidebar.
One package that is not known as a bliki but functions in a broadly similar way, in addition to having discussion forums and offering multi-blog installations, is Drupal (http://www.drupal.org). In Drupal, users would typically have their own blogs, while the wiki-type functionality lies within the book module. This is different from a real wiki, in the sense that there is no wiki-style linking system. Instead, pages are created and then arranged in a linear and hierarchical structure. Similarly to a wiki, typically all users can edit the pages in a book, as well as manipulate the structure of the book. Blog entries and book pages, as well as other content, can have keywords associated with them. Clicking on a keyword attached to one blog post, for example, will show all items of any kind with that keyword. Thus, the blog and wiki-like entries are part of the same seamless space.
Wikis and Usability
We conclude this section on wikis by broadening our focus to usability. This issue is relevant to all educators seeking to introduce new technologies, but it is arguably of particular concern with wikis, because software-related difficulties may be entangled with conceptual or attitudinal issues. In other words, the nature of the tasks that learners are expected to perform may be unfamiliar or be at odds with learners’ expectations or preferences, while at the same time more mechanical issues such as how to create hyperlinks may be a source of difficulty. By finding out what aspects of the software interface cause problems for learners, and focusing our initial instruction on these aspects, we can create some space for addressing directly the wider issues surrounding the use of wikis and other collaborative software. Ultimately, we can find ways to improve the software to alleviate these problems.
Lavin and Tomei (2006) attempted to isolate usability factors by giving pairs of wiki novices deliberately trivialized tasks to perform, and observing the wikis they created, trying to understand the difficulties by means of think-aloud protocols. Though we were only partially successful, we discovered that linking was a task fraught with difficulty, students forgetting where the Edit button was, and making all manner of errors with WikiWords. Training can no doubt overcome these problems, but there clearly is scope for improvement in the software, if we are going to use it widely with novices. Desilets (2005) concluded that requiring novice users to use raw wiki syntax to manipulate wiki links is not appropriate.
The Lavin and Tomei (2006) study showed that the effort involved in creating syntactically correct links led one pair of students to create a page which consisted wholly of one link, leading to a page consisting wholly of one link, which in turn led to another page consisting wholly of one link. It did not seem to occur to the students that content other than links might profitably be included.
The above examples are extreme, and we should not lose sight of the fact that wiki syntax is indeed easy when compared to HTML, for example. However, as a general rule, it is probably dangerous to assume that any computing task will be easy for all learners, however trivial it may seem to us. When software makes tasks complex, the frustration often makes it impossible to concentrate adequately on the central task at hand, thus destroying any chance at achieving a state of flow (Csikszentmihalyi, 1990), when learners can be at their most productive and absorbed in the activity.
Several projects address usability issues with wikis. LizzyWiki (http://lizzy.iit.nrc.ca/LizzyHelpNew/public /wiki.cgi), developed at the National Research Council of Canada, is a leading candidate for educational use, partly because of the thought that has gone into removing some of the stress associated with linking, though at the time of writing it was not yet available to the general public. MediaWiki now has eliminated CamelCase as a linking mechanism, requiring double pairs of square brackets instead. Though this is arguably slightly more time-consuming, it may prove to have some benefits in terms of ease of use.
Conclusion
The length of this section on wikis reflects the great importance that we attach to wikis, partly as tools in their own right, and partly as lenses on a wide range of issues including usability, the nature of collaboration, and ways in which technical aspects of e-learning tools can become entwined with wider issues of deployment. Such issues may be part of any new tool, but the collaborative editability of wikis brings them to the fore, and teachers deploying wikis may wish to reflect on their goals as well as the extent to which they are willing to embrace new technology and work practices.