April 6, 2006

WikiWikiWebs: New Ways to Communicate in a Web Environment

By Chawner, Brenda; Lewis, Paul H

This paper introduces WikiWikiWeb software, also known as Wiki, for use in library and information management contexts. Wikis provide an environment for Web-based collaboration and can also be used for Web site content management. The article includes an overview of the history and development of Wiki, as well as discussing basic and advanced Wiki features. It compares three Wiki engines and describes seven case studies of real-world library and library-related Wiki applications. The paper concludes with a discussion of factors that can contribute to a successful Wiki project.

Tim Berners-Lee originally saw the Web as "a system in which sharing what you knew or thought should be as easy as learning what someone else knew."1 However, early Web browsers just provided read- only access to existing hypertext markup language (HTML) pages, and this publishing model for the Web has predominated. It was not easy for people to share what they knew on the Web; the process involved learning to add HTML to text and using network file transfer software to upload content to a Web server. WikiWikiWeb, or Wiki, software provides one option for realizing Berners-Lee's early vision by enabling authorized users to edit and create new Web content using only a Web browser.

In 1994-95, Cunningham developed the first Wiki for the Portland Pattern Repository. It can be found at http://c2.com/cgi/wiki, and is sometimes called Ward'sWiki or TheOriginalWiki. Wikiwiki is the Hawaiian word for fast, and a WikiWikiWeb is a quick Web site. Cunningham wrote the original Wiki in Practical Extraction and Report Language (PERL). There is now a wide choice of software for WikiWikiWebs, and Wikis are growing in popularity as people explore their potential in different contexts.

This paper, based on a presentation at the 2004 LITA National Forum, will:

* describe the history and development of Wiki;

* list typical Wiki features and concepts;

* outline factors to consider when choosing a Wiki engine;

* illustrate Wiki applications in a library and information management context using selected case studies; and

* identify issues associated with using Wiki.

What is a Wiki?

A Wiki is a server-based collaborative tool that allows any authorized user to edit Web pages and create new ones using nothing more than a Web browser and a text entry form on a Web page. Wikis free writers from the burden of mastering HTML editing and file transfer software before they can publish on the Web. Instead, Wikis use very simple text-based markup to format page text and graphic content. While the idea of letting anyone change anything they want may seem radical or naive, most Wiki engines have features to let community members monitor changes, control user-edit permissions if necessary, restore previous versions of pages, and delete unwanted pages.

Wikis make it possible for people to collaborate in a Web environment by creating, organizing, and maintaining a Web site of automatically linked pages. As such, it is one example of what is known as social software, software that makes it easy for groups of people to communicate or work together in a virtual environment.2 Other examples of social software include Web-based discussion forums, Internet relay chat (IRC), weblogs or blogs, and instant messaging (IM). Large, successful Wikis usually have some type of constitution or philosophy that establishes goals and provides guidelines for individuals who want to participate in the group.

Some of the words in this paper have StrangeCapitalization. This is because the first Wikis used this convention to name a WikiPage. The software used to operate a Wiki is known as a WikiEngine, and is available in a wide variety of languages, and with a range of features.

Why Wiki?

When might a Wiki be an appropriate choice? Consider the following situations:

* a state library association is looking for an easy way to create and maintain its Web site;

* a professional association special interest group wants to provide an easily updated Web-based resource for its members;

* a library would like any authorized staff member to be able to update content on its intranet as necessary, without needing to use specialist software;

* an open-source software application project has participants from a range of countries who need to be able to contribute to a shared knowledge base for all software users;

* a conference planning committee needs a Web-based tool to keep track of their activities and who is doing what;

* a cross-organizational working group is preparing a collaborative report on a study trip to a range of institutions using a new type of software package; and finally,

* two people in different parts of the world are jointly writing a conference paper and would like to be able to see each other's work in context, rather than as individual word processing documents.

A Wiki could be used for each of the above scenarios. This paper will provide selected library and information Wiki examples.

History and development of Wikis

Since Cunningham developed the original Wiki in the mid-1990s, the Wiki concept has spread to many other groups, and people have written Wiki engines in a wide range of scripting/programming languages. Core Wiki features such as ease of editing, simple markup, and automatic linking of pages have been present since the beginning, but as the number of people using Wiki engines grew, extra features have evolved. These include a command to compare the current version of a page with earlier versions (PageHistory or QuickDiff), and one to browse a list of recent changes.

It is hard to determine how many Wikis exist, but SwitchWiki (www.worldwidewiki.net/wiki/SwitchWiki) lists some one thousand public Wikis, and there are many more that are restricted to specific groups (known as GatedCommunities in the Wiki world).

WikiFarms (both free and commercial) are servers that run a Wiki engine and allow people to set up their own Wikis without having to install any software. SeedWiki (www.seedwiki.com) is one example that lets individuals set up Wiki sites for personal use.

Leuf and Cunningham identify six types of Wikis, based on read- and edit-access permissions.3 These are:

* fully open, meaning that anyone has full access to the Wiki;

* lockable, with restricted editing for some or all pages;

* gated, with some public pages (that may be locked), but other pages restricted to authorized users;

* members-only, where access is limited to registered users;

* firewalled, where access is restricted to a range of specific IP addresses; and

* personal, where access is limited to a specific computer or private site.

Wikipedia (http://en.wikipedia.org/wiki/Main_Page) is an ambitious project to build a free, open-content encyclopedia. It was begun in 2001 by Jimmy Wales and Larry Sanger, using Wiki software, and as of December 2005, included more than 880,000 articles in English. They based the idea on the open-source concept of "many eyes make all bugs shallow," and anyone can edit articles and add new ones. While the idea of an encyclopedia that anyone can edit seemed ludicrous at first, during the last four years the project has gained credibility, and the Wikipedia community has put in place mechanisms to monitor and improve the quality of its content. Observing Wikipedia pages over time generally shows that article quality initially improves, and then stabilizes. Non-English versions of Wikipedia are also available; the languages range from Arabic to Chinese to Esperanto, as well as most of the European languages. Wikipedia-related projects now include Wikiquote (http:// en.wikiquote.org/wiki/Main_Page), Wikispecies (http:// species.wikipedia.org/wiki/ Main_Page), and Wiktionary (www.wiktionary.org).

WikiTravel (http://wikitravel.org/en/article/Main_Page), inspired by Wikipedia, is a Wiki-style travel guide begun in 2003. It uses a modified version of the Wikipedia engine, MediaWiki. By August 2004, it had 2,325 destination guides, as well as related articles.

The OpenGuides (http://openguides.org/) project, started in 2004, takes a similar approach to city travel guides. So far, Guides have been started for Glasgow, London, Northern Ireland, Nottingham, Oxford, Vegan Oxford, and Reading in the U.K.; Bologna, Oslo, and Vienna in Europe; and Orlando, Saint Paul, and San Francisco. They use the PERL OpenGuides software.

Typical Wiki features

This section describes features that are found in most Wiki engines, although in some cases the syntax may be different. It is by no means exhaustive, and the help pages for each Wiki engine will normally list the range of features and markup it supports. In contrast to HTML, Wiki markup is intended to be simple and nonintrusive.

Creating a new page

Creating a new Wiki page is a simple process. Most modern Wikis use a method known as "free linking" to create new Wiki pages. A free link is created by enclosing any word or phrase within square brackets when editing a Wiki page-i.e., [[New Page]] will create New Page. When the page is saved, the Wiki software interprets this markup and presents it as a hyperlink followed by a question mark to denote that the new Wiki page is an unedited pa\ge. Clicking on the new page hyperlink invokes a blank editing form on which content for the new page is entered. When editing is completed, the new page is saved and becomes a part of the Wiki.

The result of adding the text [[New Page]] to an existing page is shown in figure 1.

The free-link markup can also be used to link to existing local Wiki pages, local file attachments, e-mail links, external Web site pages, and other networked resources. The approach to hyperlinking varies from one Wiki to another-for example, Media Wiki uses a single set of brackets while PmWiki employs double brackets.

Early Wikis commonly employed a convention known as CamelCase to create a new Wiki page. A typical CamelCase word consists of any two words joined together with the initial letter of both words capitalized. CamelCase is still used in some Wikis. These normally provide a way to prevent accidental WikiWords resulting from proper names like Mclntosh or other situations where CamelCase occurs naturally, such as Ph.D.

Text formatting

Because Wikis use an HTML form to enter and edit content, the markup is text-based, using characters to signal special formatting. Typical formatting conventions are:

* blank lines signal new paragraphs;

* asterisks at the left margin (*) indicate a bulleted list;

* number-signs (#) at the left margin indicate a numbered list;

* two single-quotes ("), i.e., two apostrophes, indicate emphasis (usually italics);

* three single-quotes ("'), i.e., three apostrophes, indicate strong emphasis (usually bold); and

* four or more hyphens (----) at the beginning of a line create a horizontal line.

Figure 1. Saved page with the new link indicated by a "?"

In figures 2 and 3, two screenshots illustrate a range of Wiki markup and the way it is displayed.

This illustrates one of the benefits of text-based markup-the page of text displaying the Wiki markup is more readable than the associated HTML source.

Linking to an external Web page or resource

Including the text "http://,""mailto," or "ftp://" (or even "gopher://") before a URL or e-mail address will create an automatic link to the location or e-mail address. Some WikiEngines also recognize "www." as a reference to a Web resource.

Sandbox for new users

Most open Wikis have a page called SandBox or PlayGround for new users to experiment with such things as entering and formatting text, building unordered and numbered lists, and creating hyperlinks. The general rule is that anyone can edit anything on the SandBox page.

File uploads

Wikis usually provide a method for uploading images and other file types (e.g., Adobe Acrobat portable document format [PDF], Microsoft Word) to the Web site. File transfer protocol (FTP) software is the traditional approach to uploading files (such as image files or Adobe Acrobat PDFs) for posting on a Web server. One of the negative aspects of FTP is that the protocol has no way of encrypting username and password information and this is widely regarded as a major security vulnerability. FTP security issues are explained in detail at http:// en.wikipedia.org/wiki/Ftp.

A key benefit of Wiki engines is that the process for uploading files is built into the program. File uploads are accomplished using a Web browser and an HTML form; no separate FTP program is needed. Wiki administrators can set upload parameters specifying allowed file types and file size limits in a server-based configuration file; they can also limit file upload capabilities to authorized users. This Wiki file upload process provides a more secure approach than FTP, because it does not involve sending unencrypted user account information over the Internet.

Figure 2. Range of Wiki markup as entered

Figure 3. The way the markup is displayed

The simple syntax for hyperlink referencing of uploaded files makes it possible to use a Wiki to archive collections of document, image, and multimedia files on the Web. Leo LaPorte, the self- styled "Tech Guy" at the KFI AM-640 radio station in Los Angeles, uses the PmWiki engine to maintain a podcast archive of his radio programs at http://leoville.tv/radio/pmwiki.php/Main/AudioArchives. The South Carolina Library Association (SCLA) Governance page, www.scla.org/Governance/HomePage, is an archive of association annual reports, newsletters, and other documents in Adobe PDF, Microsoft Word, and Wiki page formats.

Recent changes

A list of recently changed pages is maintained automatically by most Wiki engines (see figure 4). As a rule, only the latest change is shown for a given page. This is a particularly useful feature, as it allows Wiki community members to easily see what has been changed. Some Wiki engines also support e-mail notification or really simple syndication (RSS) feeds for page additions, changes, and deletions.

Other features

Wiki functionality is continuing to evolve as developers improve Wiki engines. One example of a newer feature is Page History. This feature tracks previous versions of a Wiki page. With Page History, previously saved versions of a Wiki page may be recalled, reedited, and restored if necessary. This feature is essential for a fully open Wiki, which is vulnerable to malicious damage, or WikiSpam. New Wiki content contributors often find this aspect of Wikis a comfort, as it serves as a safety net to prevent them from doing harm to the Wiki page on which they are working.

Even the simplest Wikis available today usually include a basic keyword search engine to search the contents of the entire Wiki Web site. Of the Wiki engines already discussed, only PmWiki offers full Boolean search capabilities. PmWiki's search engine can be tailored in a number of ways to limit searching to specific Wiki groups or pages.

More advanced Wiki engines, such as MediaWiki, PmWiki, and TikiWiki provide additional capabilities to organize groups of pages by hierarchical categories. Wikipedia uses hierarchical categories to organize its entries. For an example of the use of categories to manage linking to geography-related topics, see http:// en.wikipedia.org/wiki/CategoryrGeography. The PmWiki engine offers WikiTrails as another feature for organizing groups of pages. An example of a WikiTrail for a library circulation manual is shown in figure 5.

The WikiTrail appears at the top and bottom of the Web page, allowing quick access to the preceding, home, and next pages in the manual. WikiTrail links facilitate logical movement through the pages in the circulation manual.

Other Wiki concepts

Collaboration versus discussion mode

There are two main writing modes used by members of a Wiki community. In collaboration or document mode, the focus is on creating a piece of text that the community is happy with, and the content of which can be edited by anyone. Discussion, or thread mode, on the other hand, is a form of dialog in which individual contributions are kept separate (more like a conversation). Rather than editing the existing content, different authors add their own comments, and may "sign them." Horizontal lines are often used to insert a break between authors. The original version of this paper was written using collaboration mode. Figure 6 illustrates discussion mode.

Figure 4. Sample recent changes page

Figure 5. Sample WikiTrail page

Communities whose main purpose is online discussion might find other software tools, such as discussion forums, more useful. Wiki- based discussion mode, however, can be particularly useful as a technique to support comments on pages created in collaboration mode.


This term is used to refer to the editing of one or more pages to make the content more coherent, or move it to a more appropriate location. Refactoring is often done when an extended discussion has created a number of similar pages, or when related points have been made on different pages. Good practice is to include a note on all edited pages to say what changes have been made, or to indicate the location to which content has been moved. Refactoring may also involve adding structure to a page-for example, by including headings or a table or contents, to allow a long page to be browsed more easily.

Figure 6. Selection from discussion mode page (accessed July 1, 2005, http://wiki.lianza.org.nz/index.php/ITSIG/CommentOnTheWiki)

Choosing a Wiki engine

Currently there are at least one hundred separate publicly available Wiki engines to choose from, according to an extensive list of Wiki software projects maintained at http://c2.com/cgi/ wiki?WikiEngine. Wiki engines have been developed in many computer- scripting languages, though the most popular appear to be personal home page (PHP), PERL, Python, and active server pages (ASP). Some Wiki engines work only on specific operating systems. For example, Wikis developed using the Microsoft ASP programming language only run on Microsoft Windows Web servers. However, most of them are multi-platform and will function properly if their requirements are met. With so many different Wiki engines from which to choose, selecting the right Wiki can seem like a difficult task.

Wiki documentation

One can quickly begin to get a clear picture of the level of quality of a given Wiki project by checking out the Wiki developer's Web site. Is clear documentation provided on all facets of the Wiki project, including system requirements, installation, upgrading, core functions, and expanded features?

Project maturity

Every individual Wiki is a unique software project unto itself. As such it can be thought of as existing in a particular stage of development. Has the Wiki been around a while or is it just getting started? Does the project Web site have a section detailing the development history of the Wiki? In general, a more mature project is more stable and reliable with fewer software bugs.

Wiki community

Is the Wiki developed by a single individual working essentially alone, or is there an active core of developers? What might become of the Wi\ki project if the original sole developer loses interest or otherwise cannot continue development? Also, what methods of feedback are provided for end users and developers to communicate? A mature project Web site will often offer a combination of e-mail, bulletin board, electronic discussion list, and possibly IRC for fast responses to requests for support. Are developers friendly and helpful when new users have questions? Is there an underlying philosophy or design principle, and how closely is it aligned with the library's goals for a Wiki?

W3C standards compliance

Does the Wiki offer compliance with Extensible Hypertext Markup Language (XHTML) and cascading style sheet (CSS) guidelines recommended by the World Wide Web Consortium (www.w3c.org)? In January 2000, the W3C issued guidelines urging adoption of XHTML, the successor markup language for HTML. Any library considering an upgrade of its main Web site or any new Web project that will be publicly available should consider XHTML compliance as a basic requirement. However, if the Wiki is to serve solely as the library's intranet or for some other nonpublic Web project, then XHTML compliance might be less of a concern. For more information about XHTML, see http://en.wikipedia. org/ wiki/ Xhtml#The_XHTML_2.0_ draft_specification. A CSS is essential for developing a consistent look and feel for a Web site. Mature Wiki projects provide CSS functionality for sitewide aesthetic control over the color, layout, fonts, and so on.

Local resources and expertise

Does the library have its own Web server or does it share space on the parent institution's Web server? Although not required, it may be more convenient in the long run to have a Web server dedicated to Wiki. Every Wiki contains one or more configuration files that reside on the Web server. The Wiki administrator will need access rights to the Web server in order to edit configuration files. Most likely this person will be the current library webmaster. Is there a staff person available with the knowledge, skills, and abilities to serve this function? Also, are local staff who contribute content on board with the changes? One of the biggest obstacles to implementing new Web technology may be reluctance by content contributors to try something new.

A choice is a commitment

Moving from traditional Web site development to a Wiki or other type of content management system requires a substantial investment of time and effort. Very few systems offer batch transfer options to automatically migrate the content of an existing Web site to another format, though preliminary discussions about a WikilnterchangeFormat have begun (http: / / c2.com / cgi / wiki? Wikilnter changeFormat). It might be useful to identify a short-list of potential Wiki engines, and install each on a trial basis before making a final decision.

Beyond the basic Wiki

Simplicity in form and function was part of the original allure of Wiki software. Today Wikis have evolved beyond being simply a workgroup collaboration tool. They are now replacing traditional Web sites. As such, some Wikis include advanced, interactive elements that modern Web sites offer such as permissions control for content contributors and users, e-mail feedback forms, calendars, photo galleries, and RSS feeds. A library organization looking to replace its traditional Web site with a Wiki, for example, might want to consider whether a given Wiki engine offers any extra functions. Additional features are often called plugins or modules. Plugins should be stable and simple to install, and supported by an active plugin community. A list of plugins a library Wiki might consider are (to name but a few): an interactive calendar application, graphical user interface edit controls, a keyword searchable image gallery for managing a local history digital photo collection, project management issue tracking, RSS link feeds from national and international news organizations or professional associations, a Java-based interactive image editing application, and a geographic map and data server.

Disadvantages of Wikis

Though their flexibility and simplicity mean that Wikis are useful in a variety of contexts, there can be issues associated with their use. WikiSpam can be a major problem for fully open Wikis. This usually takes the form of unwanted links to commercial or pornographic sites. While active Wiki communities generally rely on members monitoring changes and reverting spam, less active ones might need to implement a form of spam protection. Techniques for dealing with WikiSpam are evolving, and currently include:

* increasing the level of security, usually by requiring a password to use the Edit function;

* blocking updates from IP addresses of known spammers;

* blocking updates that contain specific unwanted words or phrases;

* restricting the number of links that can be added in a single update;

* "hiding" the Wiki site from search engines by implementing "no index" and "nofollow" metadata tags on Wiki pages, as well as asking community members to avoid posting its URL on Web sites; and

* requiring any links to external sites to be approved by an administrator.

The lack of a standard for Wiki content markup, which makes it difficult to migrate content to another Wiki engine or Web content management, is another issue, though this applies to all Web content environments, not just Wikis. The lack of a "what you see is what you get" (WYSIWYG) editing environment can be a barrier for participants used to working in a word-processing environment.

Although all Wikis share a set of key characteristics, Wiki projects vary considerably in their underlying architecture and the feature sets they offer. The result is a rich diversity of Wiki engines designed to meet a range of needs for managing Web content. The DocuWiki site includes an extensive table comparing features of different Wiki engines at http://wiki .splitbrain.org/ wiki%3Acompare. This section examines three Wiki projects, which represent different approaches to Web content management; these range from extreme simplicity to (perhaps) feature overkill.


Project Home Page: www.qwikiwiki .com

Download: http://prdownloads .sourceforge.net/qwikiwiki

Download file size: compressed: 57 kilobytes

Real world deployment: PeacefulFuture.Net http://wiki .peacefulfuture.net/

QwikiWiki packs an impressive amount of power and flexibility in a very small amount of PHP code. It is a testament to the creativity that can be achieved by a single software developer. QwikiWiki includes an installation wizard program to walk the Wiki administrator through the process of installing the program on the Web server. The Wiki includes three template files to choose from that control the basic layout of the Wiki and four separate CSS that control such things as font types and sizes for section headings and text. The Wiki administrator is free to edit existing templates and style sheets or create completely new versions to suit personal preferences.

According to Barrett, the original developer, QwikiWiki's core design goal is simplicity. This is reflected in the limited Wiki syntax users are required to learn to begin editing and in the feature set. QwikiWiki permits HTML to work along with the Wiki syntax and this can be especially helpful-for example, when migrating Web pages that include lengthy tabular data from a traditional Web site. QwikiWiki stores its Wiki pages as data in flat text files as opposed to using a database. This is also in keeping with the focus on simplicity.

QwikiWiki includes a very basic Web site search engine, with no Boolean capabilities. An edit password feature is included to prevent page edits by unauthorized users if that option is desired. Other helpful features include an option for automatic e-mail notification when changes are made to individual Wiki pages, ability to list pages that have recently been changed, and a built-in link to a help page containing info on QwikiWiki syntax. Clear, basic documentation is provided on all features. The QwikiWiki project Web site includes a discussion forum where users can ask questions and post feature requests, and an electronic discussion list.

QwikiWiki currently does not offer W3C XHTML compliance so it would be more suited for a library intranet or other nonpublicly accessible library Web project. However, the availability of only a single-site password for this Wiki could also be a limiting factor if, for example, a site has multiple-content providers who each need separate password protection for sections they manage.


Project Home Page: www.pmwiki .org

Download: www.pmwiki.org/pub/ pmwiki

Download file size: compressed: ~140-200 kilobytes

Real world deployment: University of Minnesota Libraries Staff Web Site http://wiki.lib.umn.edu

PmWiki, like QwikiWiki, also uses flat text files to store its data. Overall, however, PmWiki is more ambitious in its approach to Wiki design. Numerous developers collaborate with Michaud, PmWiki's creator, on the PmWiki core code, on plugins that extend the capabilities of PmWiki, and on project documentation. The main PmWiki Web site itself is an exemplary demonstration of the power of Wiki technology to support detailed project documentation. The PmWiki project Web site is an open Wiki, and users and developers regularly contribute to and refine the project Web site documentation. The basic PmWiki installation includes extensive documentation.

Updated versions of PmWiki are released on a very frequent basis. Developers and users have multiple channels to provide input and feedback, including a very active electronic discussion list, an IRC channel for real-time troubleshooting, and, of course, e-mail.

One feature that distinguishes PmWiki from other Wikis is its support of the concept of Wiki groups. A PmWiki Web site may have multiple groups that can be created according to organizational func\tion or for individuals within an organization, or by topic, or any combination of groupings. These distinct groups may have separate stylistic elements and password settings apart from the main Wiki. Read-and-edit passwords may be set for individual pages, groups, or the entire Wiki site. This granularity of read-and-write password protections for individual pages and groups can be very useful in library or other Web site contexts where site content providers need to exercise control over who may edit their pages.

With PmWiki it is possible to establish a WikiFarm on a single server. WikiFarm is a feature somewhat similar in concept to a Wiki group. With a WikiFarm, multiple independent Wikis are maintained through a single configuration file.

PmWiki's editing syntax is more extensive than that found in QwikiWiki, and yet it is still quite simple to learn. CamelCase WikiWords can be spaced when pages are displayed, or turned off completely. This approach gives hyperlinks a more natural, grammatically correct presentation.

Like QwikiWiki, PmWiki also permits mingling of Wiki syntax and HTML markup; this option is configurable by the site administrator, since enabling some types of HTML markup on an open Wiki can be a security risk. PmWiki has given significant attention to ensure compliance with W3C XHTML markup requirements. The look and feel of the site is controlled by templates and CSS. Its user community has contributed numerous templates to the project. As with QwikiWiki, users are free to edit existing templates and style sheets or create new ones. This design flexibility makes it possible to marry the PmWiki engine with a variety of Web site layout designs.

PmWiki offers a rich feature set. The PmWiki Web site search engine offers Boolean search capabilities. The search engine can also be configured to search selected Wiki groups within the Web site. An interactive calendar, photo galleries, graphical editing buttons, RSS feeds, and a random quote plugin are just some of the many enhancements beyond the core Wiki program. Most plugins are installed easily by uploading a single script file to the Web server and then editing a main configuration file to add a single line in the code referencing the script file. The PmWiki project Web site has a Cookbook section where all available plugins are listed along with installation details.

PmWiki is a powerful Web site content management system that can be used for a large number of applications. The ability to set read access rights for the entire Wiki makes PmWiki an excellent choice for organizational intranets. PmWiki is a good choice for small, medium, or large library Web sites and Web projects. It is one of the more widely used Wiki engines, with a Google search showing more than one million hits in mid-2005.


Project Home Page: www.tikiwiki. org

Download: http://tikiwiki.org/ Download

Download file size: compressed: ~4.7 to 6.9 megabytes

Real world deployment: Damosoft UK www.damosoft.co.uk/Home

TikiWiki is a large, open-source content management system (CMS) software project with more than six thousand registered users and more than 260 registered developers. TikiWiki has been called a "kitchen sink" Web CMS because of the numerous features and functions it offers. The actual Wiki component is but one of many modules included in TikiWiki. Other TikiWiki modules include public and private discussion forums, workflow management tools, interactive chat, a photo gallery, file download archives, a map server, and many others. TikiWiki, like many other traditional CMSs, is more focused on managing time-sensitive news articles, discussion forums, and blogs rather than on building Web pages. Indeed some CMS packages have created static-page plugin modules well after the initial release of the core package as a way to address user needs for traditional Web page management. By fully integrating a Wiki into its feature set, TikiWiki represents a hybrid CMS/Wiki and may well set a trend that other CMS projects emulate in the future.

TikiWiki employs a MySQL database to store all its data, including its Wiki pages. This requirement for MySQL database management skills adds a significantly higher threshold for the would-be Wiki administrator that can be somewhat intimidating. It should be noted, however, that many Wikis use a database backend and that learning how to manage a database-backed Web site is not an insurmountable task. Several excellent, free, opensource software tools are available to simplify the process. TikiWiki includes detailed installation documentation and a software wizard script to streamline initial Web site setup. Like Pm Wiki, the TikiWiki developers have used their Wiki to develop extensive documentation for all facets of the program.

TikiWiki includes extensive user and group read-and-edit permissions settings for its Wiki and all other modules. TikiWiki administrators pick and choose the modules they wish to deploy using a Web browser-based site control panel; other modules are turned off by default. It offers W3C XHTML and CSS compliance. There are numerous stylistic themes from which to choose. The project is under constant development with frequent updates. TikiWiki can be fine tuned to serve just a about any type of Web site need.

Selected library and information management case studies

There is an increasing number of library and information management Wikis; some are public while others are gated or closed, such as library staff intranets. Lamb identified four educational Wikis in use at the University of British Columbia, including course management, job postings, conference planning, and collaborative writing technology.4 Frumkin describes the use of Wiki software for a reference librarian knowledge base and a Web site content editing tool, and suggests that Wikis also have potential in digital libraries-for example, as a tool for user annotations or comments.5 Farkas set up an unofficial American Library Association 2005 conference Wiki, which was used by a number of conference attendees for conference tips, location information, and session reports (http://meredith. wolfwater.com/wiki). More recently, Farkas has set up Library Success: A Best Practices Wiki (http://lib success.org).



A Wiki used to develop a shared resource for members of the Information Technology Special Interest Group (ITSIG) of the Library and Information Association of New Zealand/Aotearoa (LIANZA). This was launched in October 2003, using the PmWiki engine. It includes information about ITSIG and its activities, as well as a resource page with links to useful sites. It also hosts a research register for the Research Special Interest Group (SIG), which allows anyone to create a page about research projects relevant to New Zealand libraries. A template is used to format the initial edit page for a new research project page, displaying the fields and basic markup. WikiSpam (like e-mail or blog comment spam) has become an issue, and the Wiki has recently changed from being fully open to requiring a password to save changes. Known Wiki spammers are blocked.

Koha Project Wiki


A locked Wiki set up to support members of the Koha open-source library management system project. It includes a register of Koha users, pages about installation and migration, information about reporting bugs, and documentation about Koha features. It uses the WikkiTikkiTavi engine.

New Zealand Government Tertiary e-Learning Standards Wiki

http://wiki.tertiary.govt.nz/ ~TertiaryELearningStandards/ Main/ HomePage

This is a gated Wiki set up to allow people to comment on an overview of standards for e-learning. People who wish to comment must first register, but the content is available for anyone to read. Part of a project to develop a national tertiary e-learning framework, the interim framework document was developed using a password-protected closed Wiki, with participants from a number of government departments, including the Ministry of Education and the National Library. Both Wikis used the PmWiki engine.

New Zealand Institutional Repositories Feasibility Wiki

http: / / wiki.tertiary.govt.nz / ~InstitutionalRepositories

The National Library of New Zealand set up a project to investigate options for institutional repositories for the New Zealand research sector in May 2005. This Wiki site was set up to provide a shared resource for project members, in particular to allow them to document their findings. It uses the PmWiki engine.

South Carolina Library Association


The South Carolina Library Association (SCLA) Web site serves the library community in South Carolina. It is a moderately sized Web site with more than three hundred separate pages. Page editing is password protected. Association committee, section, and round table chairs are authorized to maintain their respective pages. This Web site uses the PmWiki engine.

University of South Carolina (USC)-Aiken Library


The USC Aiken (USCA) Library Web site is a typical small academic library site employing PmWiki software for site content management. PmWiki is also used to manage the USCA Library's intranet. The intranet portion of the site includes the circulation department procedures manual, a section for development of the library's strategic planning and assessment, a section for collaboration for this Library and Information Technology Association (LITA) paper and presentation, and other content.

The USCA Library migrated to PmWiki from another content management system software, phpWeb site (http://phpWeb site.appstate. edu), during the summer of 2004. Librarians and some general staff contribute content to the main Web site and the intranet.

USC-Campuses Library Council


The USC Campuses Library Council Web site is a very small site whose purpose i\s to support communication and planning for the eight libraries of the USC statewide campus system. This Web site uses the PmWiki engine.

Wiki success factors

Getting people to contribute to a Wiki is as much about culture as it is about technology. Even though it is very easy to add and edit Wiki content, it is not always a case of "build it and they will come." People accustomed to the WYSIWYG approach in MS Word (or even Dreamweaver) may take a while to adjust to the idea of text- based markup, for example. Some Wiki engines, such as MediaWiki and PmWiki, are now moving to a more WYSIWYG approach, with graphical edit buttons on the edit page to help people learn the markup.

Creating the right conditions for a Wiki involves:

* setting up an effective initial structure, so that people can see where their contribution might fit;

* monitoring new and changed content, so that inappropriate content is dealt with promptly. This might also require clear guidelines on appropriate content, and a statement about the identity of the intended audience;

* having a statement about copyright and content ownership. If people sign their contributions, then it might not be considered appropriate for someone else to edit them; a comment (i.e., discussion or thread mode) might be better;

* providing an explicit Page History link to make it obvious that content can be restored if necessary;

* having basic text formatting tips displayed when someone edits a page, to help them remember the markup; and

* having suggested page naming conventions and writing style guidelines. The basic idea here is to remove some of the uncertainty associated with a totally open environment, which might help people overcome their initial hesitation about contributing.

In the early days, it might be useful to "shoulder tap" selected community members for specified Wiki contributions, to start the habit. Some Wikis have lists of "wanted pages" to identify topics they'd like someone to write about.

In some cases having a "comment on the Wiki" section encourages people to describe their reaction to the idea of editable Web content, and it can overcome their initial fear of breaking something if they edit a Wiki page.


The case studies in this paper illustrate just a few situations where Wikis can be effective. Because of their flexibility and simplicity, they can be used in a wide range of contexts, and provide an environment in which Berners-Lee's early vision for the Web can be achieved. A totally open Wiki might suit a widely distributed organization like the LIANZA ITSIG, while a members- only Wiki would suit a work group collaborating on policy documents or procedure manuals (or simply wanting an easy electronic notice board). Features like Recent Changes and Page History make it easy for community members to keep up with changes. Wikis are also gaining in popularity as simple, lightweight Web site CMSs for groups and individuals. Wikis offer libraries and other organizations a tool that can be used when upgrading traditional Web sites or implementing new Web-based projects-their potential for enabling Web-based communication with staff and users is just beginning to be appreciated.

Libraries were early and enthusiastic adopters of the Web as a medium to enhance and expand access to information for the communities they serve. The Web is constantly changing, and in the next few years we expect organizations to move to more interactive e- services. New technologies offer new opportunities and evolving Web accessibility standards present new challenges for libraries. For libraries looking to take advantage of new technologies and build Web sites that comply with Web accessibility standards, Wikis offer a relatively easy path to build the next generation of library Web sites. At the same time, they raise the possibility of having more interaction with users.

Finally, Wikis illustrate a shift to an increasing ability to use a Web browser as a person's main application tool, and they foreshadow other browser-based capabilities, such as table or drawing editors, which would make it possible to create complex documents using nothing more than a standard browser.

Author's note: all URLs in the text were accessed in early July 2005.

References and notes

1. Tim Berners-Lee with Mark Fischetti, Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web (New York: HarperBusiness, 2000), 33.

2. Wikipedia, s.v. "Social software," June 30, 2005. Accessed July 1, 2005, http://en. wikipedia.org/wiki/social_ software.

3. Bo Leuf and Ward Cunningham, The Wiki Way: Quick Collaboration on the Web (Boston: Addison-Wesley, 2001), 277.

4. Brian Lamb, "Wide Open Spaces: Wikis Ready or Not," Educnuse Review 39, no. 5 (Sept./Oct. 2004): 36-48.

5. Jeremy Frumkin, "The Wiki and the Digital Library," OCLC Systems & Services: International Digital Library Perspectives 21, no. 1 (2005): 18-22.

Brenda Chawner ([email protected]) is Senior Lecturer, School of Information Management, Victoria University of Wellington, New Zealand. Paul H. Lewis ([email protected]) is Government Documents Librarian, Gregg-Graniteville Library, University of South Carolina- Aiken.

Copyright American Library Association Mar 2006

(c) 2006 Information Technology & Libraries. Provided by ProQuest Information and Learning. All rights Reserved.