Making the Case for a Wiki

Introduction: What is a Wiki?

Software use cases are necessarily incomplete, a failing which seems to intensify in reverse proportion to the degree of simplicity in the software in question. Complex software responds to a given set of requirements, simple software as a partial solution to a much broader problem set. More concisely put, certain ideas just seem to catch on, particularly the simple, brilliant, ‘now why didn’t I think of that’ class of ideas. Examples include IP, the Internet protocol, the point-and-click user interface that arose from Xerox PARC to conquer computing, or HTTP, the Hypertext Transfer Protocol upon which the Web is built. Although these ideas are often traceable to one inventor, today’s implementations tend, broadly speaking, to be the result of a fairly long evolution and a number of sources.

These are ‘killer applications’, software that has changed the world, and membership in this exclusive club is strictly limited, but there exists a rather larger and fuzzier class of other ideas that have enjoyed a more gradual rise to fame, the classic example being the message board or the online journal that received very little attention before its felicitous re-birth as a ‘blog’. Most of these are software concepts that have become a recurring theme for the Web, recreated perhaps a thousand times in various forms by web developers because of their wide appeal and broad spectrum of potential applications, yet largely ignored until re-branded into a buzzword.

The wiki is another such concept, that could be christened ‘simple user-editable data storage’. It was born in 1995 to hold a pattern repository, the term ‘Wiki’ famously being taken from the Hawaiian term ‘WikiWiki’, or ‘Super fast’. The image below shows a simple wiki such as I might have used to gather my thoughts before beginning to write this article, one theme, or WikiWord, per page, with various links between the pages showing where I have referenced one from another.

Figure 1: Example of a simple Wiki representing this article

The wiki was rather aptly described by Ward Cunningham as ‘the simplest online database that could possibly work’. Although this description is entirely accurate and very concise, it isn’t entirely sufficient. In terms of features, wikis generally, although not invariably, include:

• A space containing pages that can be freely written or edited by anybody - depending on the aim of the wiki, this capability may be limited to certain authorised members. A basic wiki consists of one page per WikiWord, with one editable text area.
• Pages may be added by the use of WikiWords, words that are automatically linked to a page referred to by that name. In certain wikis, this is restricted to linking of all words that contain two or more capital letters (LikeThis), in what is usually referred to as CamelCase. More recently, the use of CamelCase has lost favour, and is often considered to be untidy or difficult to read, leading to alternative conventions such as the use of double square brackets [[such as these]] to denote a WikiWord.
• Wikis are not usually written directly in HTML, though some do allow HTML formatting to be used; most provide a simplified system of markup [1]. The details of the markup used tend to reflect the intentions of the wiki’s developers. Many simple wiki applications make use of traditional tricks such as marking underlined text with underscores and bold text with asterisks - i.e. underline to underline and bold to bold, for example - whilst Wikipedia, the Web-based, multi-lingual encyclopedia designed to be read and changed by anyone, has introduced additional markup for definitions, references and mathematics markup. Many are similar enough to provide a fairly consistent user experience for the less demanding, which lowers the learning curve for novice user participation in a wiki.

The above features merely tell us the defining features of a wiki; they do not tell us anything about the actual purpose of the system. In fact, they show that the purpose to which the wiki is put can demand radical differences to its structure and functionality. To pin this down, it might be helpful to examine a few hypothetical use cases.

Use Cases: Mental Models of the Wiki

Single-user Wikis

Talking to yourself may well be the first sign of madness, but what about writing to yourself? At first sight, it seems peculiar to imagine a single author making good use of a wiki. Wikis are collaborative environments, after all - or they’re fast flexible multi-user web development platforms. What can one person do with a wiki? Or, rephrased, what on earth is the good of wiki software for a handheld or PDA (Personal Digital Assistant)?

They can map concepts; wikis are extremely useful for brainstorming. Exploring a topic by means of a wikiweb is a curiously comfortable feeling, and often very rewarding. Authoring a wiki on a given topic produces a linked network of web pages roughly analogous to a concept map, a visual technique for representing knowledge and information. More can be read about concept mapping in Novak’s online introduction [2].

One cannot take this analogy too far, although the similarity has often been discussed in the past. Few wikis offer plugins that provide visual representations, for the reason that wikis tend to be rather more confused than a pure concept map; moreover an arbitrary number of links may be made between pages, which tends to result in a network which, though valuable, is rather too complex to be displayed in a simple diagram. One or two have been developed, for example the VisualTour that is sometimes available on c2.com. Perhaps instead of offering a general overview of the entire content of a wiki, a tool that displays all of the concepts within a given number of links, or a tool that attempts to separate keywords into themes based on the interlinking, will prove more useful.

Nonetheless, a single user wiki is a marvellous way of collecting and presenting information over a period of time.

Lab Book

Students requiring a place to keep an online lab book or research notebook are in much the same situation as the ‘single user’ jotting down brainstorming ideas, except for a number of details:

• The students may wish to impose a more formal structure, such as an index and entries cross-referenced by date and by content.
• In order to store other resources, the wiki may need to be extended or twinned with a separate application to provide file storage and description functionality.
• Page export facilities in various forms are useful, if not necessary; for example, if the student can export their completed pages as a well typeset PDF document, the results can easily be used and shared in a variety of scenarios, or even bound into a book and used as a permanent record.

Collaborative Writing

Wikis are available online, for anybody granted access, and usually include the vital versioning information that allows authors to track the history of their documents. They appear to be an ideal platform for collaborative authorship, and indeed certain projects such as the Wikipedia, an online encyclopaedia, have proved to be entirely successful.

Not all wikis are suitable for this task; some have no page locking system, so if two people edit the page simultaneously, one set of changes will be silently deleted. Those that do will permit only one author to edit the page. Some wikis do not include a versioning system, making them inappropriate for the task. Finally, there are the social issues that occasionally crop up, particularly on very large projects such as the Wikipedia. Certain pages on the Wikipedia that deal with particularly controversial topics, eg. abortion or evolution, are periodically subjected to a phenomenon known as an edit war, which is to say the continued editing or reversion of the text by wikipedia contributors, often for social or political reasons. The easiest way to call a halt to such disagreements is to place a block on the page edit functionality for a period of time [3].

Wikis destined for collaborative writing should therefore include:

• a page locking system
• a versioning system
• the ability to temporarily remove the edit functionality for a given page

Knowledge Base

Any good technical support team needs to retain their experiences somewhere, and a wiki makes a reasonably good knowledge base. Essentially, this is a collaborative authoring system, but the need to access the correct data as quickly as possible means that a wiki used for this purpose will also require an advanced search functionality, not to mention tight integration with file management software. Since quick access is so important, an effective navigational structure will also be useful.

A knowledge base wiki will therefore benefit from:

• an efficient search function
• effective navigation and categorisation
• file management abilities

Choosing a Wiki

Lightweight implementations of the concept are available for most existing environments or interpreters in a variety of programming languages. That being said, various more complex wiki implementations are not entirely interchangeable, as each one is generally the result of customisation processes to increase the application’s usefulness for a given purpose.

The original wiki included no authentication features and no rollback or logging of diffs; nor did it boast an RSS feed nor any export facilities. It is still used, along with several clones, but authentication has become increasingly necessary due to the risk of overwriting, not by hostile individuals, but by spambots (programs that extract email addresses from Web pages for the purposes of spam) using the wiki space to link to a set of sites in the hope of earning an improved search engine page ranking.

At the other end of the scale lie the content management systems with wiki components, including complex structure, presentation and navigational elements, as well as an authentication and identity model sufficient for corporate intranet use.

The following tables compare a few features of a number of possible wiki implementations. No such list can hope to be exhaustive, but it is hoped this comparison will provide an idea of the span of available software and their dissimilar use cases. A more complete list is available at Cunningham’s original C2 wiki [4].

Table 1 : Comparison of features of wiki implementations

Table 2: Comparison of external features of wiki implementations

Issues in Deployment

Despite the clear use cases that appear to underlie its design, the wiki remains largely a laboratory animal. Even in the event of a wiki being made available, there is no guarantee that the opportunity will be seen as useful. As with chat rooms, bulletin boards, or blogs, many installations quickly fall into disuse. A colleague remarked recently that, ‘there’s nothing sadder than tumbleweed blowing through an abandoned messageboard’. Very true. But is it inevitable? In some cases, yes; not every perceived user community will accept a technology. The underlying factors, surprisingly, are much the same on the Internet as elsewhere: communication difficulties; lack of common ground; status issues in human relationships.

For quite some time, the nascent Internet was assumed to be a force for democratisation and gender equality. The popular lore suggested that the newly formed means of communication in cyberspace would provide equality of opportunity, as though by displacing communication from physical media to cyberspace, one becomes somehow symbolically disembodied. Unfortunately, this optimism has been shown to be somewhat misplaced. Research from the 1990s discussing gender in computer-mediated communication began to show that off-line status and hierarchy was reflected in the online world, and that factors such as levels of aggression tend to dictate the membership of a given online community. In effect, disparity of gender is still very much with us in the new media. Perhaps unsurprisingly, in many situations gender differences ‘tend to disfavour women’ as Herring would maintain [5].

The above could be restated rather more gently as follows: people tend to form communities. Those communities depend upon a given set of social interactions and behaviours. The specific choice of technology chosen to mediate that activity has a relatively small influence, provided it is adequate. Missing features are often successfully bypassed, as with the paucity of emotional cues or turntaking signals in IRC (Internet relay Chat). It is due to this phenomenally successful robustness of communication that the communication problems that plague us off-line join us online as well. Proof of this assertion is easy. Examination of a few mailing list archives, or comparison of the aggressive writing style at slashdot.org [6] with the positive reinforcement (‘Good job!’) displayed on the discussion boards at Ballet talk [7] will suffice to persuade the reader that something is going on. Rather less obvious is the applicability of this research to the wiki.

Herring’s examination of the blog suggests that, although bloggers come from all walks of life, disproportionate attention in various forms is paid to the adult, male bloggers [8]; it is justifiable to theorise that wiki use – and indeed motivation to contribute – is likely to vary by gender, status, and relationship to the apparent community. The details are another question; one might imagine that a significant difference in use profile might arise between applications that label contributions by username, and those that do not. One might suspect that beginning a new wiki page is a task that offers the same risk of writers’ block as any other new work, and that the additional burden that the wiki places on the first author of any section - defining its structure - might weigh heavier on some than on others. Further, one might imagine that correcting a wiki page is an act that comes easier to certain individuals than to others, and one in which aggression plays a significant role.

Generally speaking, a golden rule of successful software deployment is, ‘get to know your audience’. There are any number of approaches to this goal; from the approach advocated in The Inmates Are Running the Asylum [9], thinking yourself into the user’s perspective in a manner reminiscent of method acting, to Lucy Suchman’s pioneering approach to ethnography in the office environment. These vary in efficacy, but it is very worthwhile attempting to fit time for such analysis, investigation, or roleplay into the early stages of any technology deployment. Knowing your audience, in computer-mediated communication, means gaining an understanding of the target community. Be warned: with only rare exceptions, if you cannot imagine your target group conversing comfortably together under normal circumstances, the chances are fairly slim that they will imagine they can either - much less online.

In practice, it is not easy to get to know each and every user group quite this well, so the second best option both from the user perspective and from the perspective of the site’s administrator is flexibility, a minimal imposition of structure, and support for unexpectedly advantageous effects. This is typically at odds with the system administrator’s need for a simple, well constrained system that requires little maintenance. It is usually possible to create a system that works well both for the system administrator and with the users’ needs, but it is an extremely difficult problem; not only are users’ needs deeply intertwined with cultural and social factors, they are also in a constant state of flux. Successful attempts tend to be either inspired guesses, the result of a great deal of up-front research, or the result of evolution through several iterations.

Remember: a user in an uncomfortable situation will (unless bound by corporate policy) generally choose to leave Dodge City to the midday shoot-outs and, eventually, the tumbleweed.

Future Trends

It sometimes seems that every combination of consonants, plus the suffix ‘-iki’ have been used for some form of project or another. The latest in this string of tongue-twisting derivatives is the ‘bliki’, a mixture between the blog and the wiki, in which articles are posted on a journal in date order, but remain editable by other users. Effectively, the bliki is simply a wiki in which articles may be added not by keyword, but by date. There is therefore no initial obligation for topics to be linked according to any sort of concept mapping.

Bliki applications are currently rare, partly because the idea is still relatively new and possibly because the place the blog holds in present-day online dialogue is generally different to that of the wiki. Authoring a blog is a little like holding speeches from atop a soap box, and tends to prioritise feedback while wikis, due to the ease with which they can be vandalised, are more usually employed for topics of a less emotive and immediate nature. However, it is possible to imagine that once bliki technology matures to adulthood, the combination will present a useful approach to the integration of the two systems.

Conclusion

Wiki implementations are available for almost every system, even the most unexpected, and the concept is mature enough to take seriously as one of a number of possible enabling technologies for computer-mediated communication and information storage and retrieval. When considering the addition of a wiki implementation into a given environment, it is nonetheless important to ensure that the application chosen has the right span of features for the user requirements; furthermore that the expected users are comfortable with the software, its capabilities, and the intended community. Although the technology clearly provides a number of potential advantages, there are many circumstances in which factors conspire to reduce its usefulness or possibly even make a deployment counterproductive, so it is important to consider the actual needs of the user base as a priority.

There exists a large number of available wikis, and many are of high quality, meaning that it is possible to choose one based on factors such as preferred development or use platform, current support or continuing development, in addition to the availability of required features for a given use case. Bear in mind that wikis differ in all sorts of detail, and therefore that it is generally worth test-driving a selection of possible software packages before coming to a decision.

Familiarisation with wiki technology is a goal best accomplished by trying out an implementation or two, either alone or with a small sample of the user base that might make use of it in the future.

References

1. Wikipedia : authoring instructions: http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page
2. Novak, Joseph D. The Theory Underlying Concept Maps and How To Construct Them http://cmap.coginst.uwf.edu/info/
3. Wikipedia : the edit war: http://en.wikipedia.org/wiki/Wikipedia:Edit_war
4. WikiWiki reference list: http://c2.com/cgi/wiki?WikiEngines
5. Herring, S. C. Gender and power in online communication. In J Holmes & M Meyerhoff (Ed.), The Handbook of Language and Gender (pp.202-228), 2003. Oxford: Blackwells Publishers
6. Slashdot News for Nerds. Stuff that matters. http://slashdot.org/
7. Ballet talk http://balletalert.com/dancersforum/
8. Herring, S. C., Kouper I., Scheidt, L. A., and Wright, E. L., Women and Children Last: The Discursive Construction of Weblogs http://blog.lib.umn.edu/blogosphere/women_and_children.html
9. Cooper, A. The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, 1st edition, April 6, 1999. Sams.

Author Details

Emma Tonkin
Interoperability Focus Officer
UKOLN

Email: e.tonkin@ukoln.ac.uk
Web site: http://www.ukoln.ac.uk/ukoln/staff/

Return to top

Article Title: “Making the Case for a Wiki”
Author: Emma Tonkin
Publication Date: 30-January-2005
Publication: Ariadne Issue 42
Originating URL: http://www.ariadne.ac.uk/issue42/tonkin/