Feature
Quickiwiki,
Swiki, Twiki, Zwiki
and the Plone Wars
Wiki as a PIM and Collaborative Content Tool
by David Mattison • Access Services Archivist • British
Columbia Archives, Cananda
In July 1991 I had my first taste of hypertext when a neighbor loaned me his
Classic Macintosh. I created a HyperCard stack simulating an orientation to
my workplace. Working in a Wang shop as I did at the time, I couldn't show
it to anyone except in printed form. I remember it was pretty tough to convey
my excitement over hypertext on the basis of ink on paper. Over my many years
of research and writing, I could see the personal potential for either a stand-alone
or a Web-based hypertext system. Over the 2 decades I've worked with personal
computers, I tried a few personal information manager (PIM) and free-form database
products such as AskSam [http://www.asksam.com/],
but decided to wait. Even then, others were already working out solutions to
using a Web browser as a hypertext writing tool.
While researching and writing my February 2003 Searcher article
on RSS and blogging ("So You Want to Start a Syndicated
Revolution?"), I kept running across references to "wiki" software.
Since I still haven't grasped the subtle distinction
between when and when not to capitalize wiki, I've made
it lowercase throughout except when referring to a specific
wiki site or wiki software. (See the "Wiki Words" sidebar
interview with Bo Leuf on page 42.)
Since I come from Hawaii, the word "wiki" itself caught
my attention first. "Wiki" is Hawaiian for quick. "Wikiwiki" means
real quick. Ward Cunningham, the creator of the first
wiki, liked the name, learned through frequent rides
on the WikiWiki shuttle buses at the Honolulu International
Airport. His first WikiWikiWeb [http://c2.com/cgi-bin/wiki],
rendered into HTML through a Perl script written in 1994-95,
still runs today at its original home on the Portland
Pattern Repository site.
In The Wiki Way (2001), the one and only book
devoted solely to wiki, Bo Leuf and Ward Cunningham define
wiki as "a freely expandable collection of interlinked
Web 'pages,' a hypertext system for storing and
modifying information — a database, where
each page is easily editable by any user with a forms-capable
Web browser client" (page 14). Wiki pages are controlled — created,
linked, edited, deleted, moved, renamed, and so on — by
a programming or scripting language, and stored either
as plain ASCII text files or in an external relational
database, such as MySQL, Oracle, or PostgreSQL. Wiki
pages are only rendered or displayed as HTML through
templates by the wiki Web server. Ward's original wiki
was written in Perl, and he released the script as copyright-limited
open source.
Since 1995, many other talented individuals have produced
dozens of wiki clones or wiki-like Web content management
systems (WCMS), most often under an open source license,
in various programming or scripting languages that run
on every microprocessor platform imaginable, including
PDAs and smartphones. Some of these implementations are
free for personal and commercial use, others are free
for personal use only. Still more are strictly commercial
only and may offer either a downloadable limited-feature
or time-limited executable program.
This article looks chiefly at completely free (both
personal and commercial use allowed) or shareware open
source products. An excellent starting point, and one
Ward calls canonical, for wiki clone software is at WikiWikiWeb WikiEngines[http://c2.com/cgi/wiki?WikiEngines].
If you wish to delve deeper into the philosophical and
metaphysical realms of wikidom, go to these pages on
Ward's WikiWikiWeb:
• ElementsOfWikiEssence
[http://c2.com/cgi/wiki?ElementsOfWikiEssence]
• WikiEssence
[http://c2.com/cgi/wiki?WikiEssence]
• OneMinuteWiki
[http://c2.com/cgi/wiki?OneMinuteWiki]
• InternationalOneMinuteWiki [http://c2.com/cgi/wiki?InternationalOneMinuteWiki]
• WhyWikiWorks
[http://www.c2.com/cgi/wiki?WhyWikiWorks]
• WikiDesignPrinciples
[http://c2.com/cgi/wiki?WikiDesignPrinciples]
• WikiHistory
[http://c2.com/cgi/wiki?WikiHistory]
• WikiWikiWebFaq
[http://c2.com/cgi/wiki?WikiWikiWebFaq]
Built around object-oriented programming, wikis are
extremely popular within the software development community,
especially among those that practice the principles of
Extreme Programming (XP, not to be confused with Windows
XP). (For definitions of some of the wiki and Web content
management system terminology I use, see the sidebar "Wiki
Words Glossary" on page 39.)
Wiki Uses
"Not everyone needs a wiki. Not everyone wants a wiki.
Not every situation benefits from becoming an open discussion
or collaboration forum."
The Wiki Way (2001,
p. 30)
Wikis are everywhere, but, unfortunately, the online
literature has not begun to focus on wikis yet. Why aren't
wikis on our radar screen the way blogs are right now?
Walt Crawford, a senior analyst at RLG and active writer
and speaker in the library field, reported to me by e-mail
that he had "tried out a library-related one quite a
while ago and, at the time, found the mechanisms and
content both either uninteresting or problematic. Since
I didn't have any need that cried out for wikis as a
solution, I didn't pursue the matter. That also explains
the absence of any mention of wikis in my American
Libraries 'e-files' series in late 2001: I was not
aware of any real significance in the library field.
That doesn't mean there isn't any, of course."
Perhaps my questions to him weren't fair, but I can
see all kinds of potential for wikis in libraries, both
behind the scenes where they are being used, and in public
customer service areas where you could create a librarian-administered,
self-serving knowledge bank. For example, what about
a My Favorite Web Sites subject guide to the Web wiki,
a readers' advisory or book-rating wiki, a suggestion
box wiki, an FAQ wiki, a collaborative story created
by children, or a guide to using the library wiki by
your friends and neighbors?
Ben Schmidt, Canadian National Site Licensing Project [http://www.cnslp.ca/],
and Professor Anita Coleman, School of Information Resources
and Library Science, University of Arizona, both contributed
reports by e-mail and via my Searchers' Swiki experiment
(see below) about the use of wikis within and outside
their projects and institutions. Professor Coleman pointed
me to the National Science Digital Library as
one of the most high-profile sites in the library community
using wikis as part of its Communications Portal (for
examples, see http://eval.comm.nsdlib.org/cgi-bin/wiki.pl?WhatIsThis,
http://annotations.comm.nsdlib.org/cgi-bin/wiki.pl,
and http://sourceforge.comm.nsdlib.org/
cgi-bin/wiki.pl?WikiResources).
Some of the common wiki uses are as a hypertext database
for research and writing (the wiki as personal information
manager [PIM] or organizer), a knowledge management (knowledge
bank or knowledge-log), a team collaboration tool for
creating and maintaining documents that need frequent
updating such as policy and procedure manuals, content
for academic instruction, and a more flexible kind of
Web log. This last use is already addressed in some wiki
or collaborative WCMS implementations such as Scoop [http://scoop.kuro5hin.org/], SnipSnap [http://snipsnap.org/space/start],
and Vanilla or VanillaSBX (VanillaSite-out-of-the-Box) [http://www.langreiter.com/space/Vanilla and http://www.langreiter.com/space/VanillaSBX].
These applications describe themselves as allowing collaborative
editing, commenting, and threaded discussion, generally
by date as with Web logs. Besides serving as "an easy-to-use,
hyperlinked text database" (The Wiki Way, 2001,
p. 98), some mature wiki clone implementations also fall
in the category of Web content management systems (WCMS)
and already come designed as collaborative content tools.
Wikis are easy to learn and use. There are no complicated
syntax or text formatting rules. Some wiki clones permit
the inclusion of HTML, but The Wiki Way authors
recommend, with some exceptions, against this practice.
The lack of a consistent, cross-wiki standard for text
formatting is a distinct and severe disadvantage, especially
if you visit and contribute to different wikis. Because
a basic wiki stores content as plain ASCII text, the
original text-formatting rules use start and end pairs
of punctuation for markup. Internet URLs are written
out in full and automatically recognized. In Ward's WikiWikiWeb,
a wiki page is created by running words together with
initial capitals for each word to create a WikiWord.
In other wiki implementations such as Swiki, wiki pages
are created by a paired-punctuation pattern. In the WikiWikiWeb,
the WikiWord page name is the last part of the URL; in
the Swiki model, pages are numbered, which means you
easily rename a page while you're editing it, and once
saved, the change is reflected throughout the database.
The Wiki Way authors recommend never deleting
a wiki page, but deleting the content instead, leaving
a note explaining why, and creating another page instead.
This practice encompasses the gentle (or brutal) wiki
art of RefactoringWikiPages [http://c2.com/cgi/wiki?RefactoringWikiPages].
Except where some implementations allow the use of a
JavaScript or some other kind of HTML editor, Wiki page
creation or editing is generally done inside an HTML
text area box that usually only permits the inclusion
of ASCII text. The left edge of the box usually contains
certain kinds of visual styles such as bulleted and numbered
lists, horizontal rules, headings, or the creation of
an Append or Comment field. When I had to copy and paste
e-mail messages into a swiki I created, it proved a chore
of back and forth correction as certain characters appearing
at the left edge of the textarea box kept turning into
a bullet or a horizontal rule. Worse, some characters
such as a "<" or a ">" would not appear at all
unless "escaped" because saving the document in Internet
Explorer automatically stripped some HTML markup symbols.
Wikis, Web Logs, and RSS
"I've toyed around with the idea of using wikis [http://c2.com/cgi-bin/wiki?WikiWikiWeb] for
various projects, but in the end, I'm hesitant to use
them because it's still stationary information. I want
my information coming to me, not waiting around for me
to get to it. Yes, you still need the depository, but
these days I want it in my news aggregator or my e-mail."
Jenny Levine,
The Shifted Librarian
[http://www.theshiftedlibrarian.com/2002/03/19.html#a887]
Various experiments are underway on integrating the
RSS protocol for both aggregation (subscribing to and
reading a news feed) and syndication (exporting of wiki
content as RSS content so other sites can subscribe to
it). Ward's WikiWikiWeb contains a simplified overview
and pointers on WikiStyleRss [http://c2.com/cgi/wiki?WikiStyleRss];
his page on CategoryWikiMetadata covers the limitations
faced by wiki sites [http://c2.com/cgi/wiki?CategoryWikiMetadata].
John Abbe's Wiki Weblogs [http://www.ourpla.net/cgi-bin/pikie.cgi?WikiWeblogs] and Wikis
with RSS[http://ourpla.net/cgi/pikie?WikisWithRss] demonstrate
how some wiki developers integrate wikis with blogs
to support RSS aggregation and syndication. While aggregation
appears more easily accomplished, syndication is generally
handled in a standard wiki through the RecentChanges
page. The proposed RSS 1.0 extension for wiki syndication
is called ModWiki [http://www.usemod.com/cgi-bin/mb.pl?ModWiki].
One of the goals for ModWiki is to produce a dynamically
updated UnifiedRecentChanges page that aggregates external
wiki content. Examples of UnifiedRecentChanges pages
appear on sites operated by Jeff Dairiki [http://www.dairiki.org/rss1.0/urc.html] and
Dave Jacoby [http://csociety.ecn.purdue.edu/~jacoby/UnifiedRecentChanges/].
To see an example of wiki aggregation, visit the Open
Wiki WikiSites/Aggregation page [http://openwiki.com/?WikiSites/Aggregation].
Some wiki clones, such as MoinMoin [http://purl.net/wiki/moin/] by
Germany's Jürgen Hermann, contain both an XML
link on every page that can be "scraped" for RSS syndication,
along with a valid RSS URL for his site's RecentChanges
page [http://twistedmatrix.com/users/jh.twistd/moin
/moin.cgi/RecentChanges?action=rss_rc&unique=1].
Wiki Search and Page Control Tools
All wiki implementations contain a few basic search
and navigational capabilities, some of which relate to
their nature as hypertext databases. The integrated search
feature of a wiki at its most primitive is a keyword
or text-match tool. Ward's WikiWikiWeb site shows an
extension of this feature to include page titles or full
text, with the latter searching a separate index updated
daily. Some wiki search engines provide case-sensitive
and phrase searching, along with Boolean expressions.
Every time a page is added or changed, you can select
the RecentChanges or Changes query, which displays
a real-time update of those page titles [http://www.usemod.com/cgi-bin/mb.pl?RecentChanges].
The History query on some wiki clones provides
a list of page versions back to the very first instance [http://prosaic.swiki.net/1.history].
Wikis that implement page-version control may also allow
page rollback, usually via the History view; sometimes
you will see the word "diffs" used for version display,
which means differences, a short form of the software
utility of the same name.
The Backlinks function may or may not be enabled,
depending on what wiki software you use [http://zwiki.org/BackLinks/backlinks].
Backlinks shows you a hyperlinked list of which pages
refer to the page you are viewing. The Category feature
on Ward's WikiWikiWeb is explained as a "ReverseIndex
to related wiki pages" [http://c2.com/cgi/wiki?CategoryCategory].
Some wiki clones have since adopted this wiki structural
and search tool. An interlinked site map, the TourBusMap [http://www.usemod.com/cgi-bin/mb.pl?TourBusMap],
operates in some wikis. The "grand central" wiki TourBusStop is
you-know-where-by now [hyperhint: http://c2.com/cgi/wiki?].
The WikiWikiWeb also features a nice LikePage search
that produces a list of page titles matching the one
you're on. Each time you select a new page title, a new
LikePage list is generated. Slick and quick, it works
something like the Related Links in the Alexa Toolbar
or "Similar pages" in a Google results list. Ward's WikiWikiWeb
also contains a VisualTour [http://c2.com/cgi/tour] link
that you'll find on every page. Finally, some wikis show
you a hyperlinked, hierarchical trail ("breadcrumbs")
back to where you started, or back to the FrontPage.
For examples of these, see my Searchers' ZWiki [http://searcher.freezope.org/zwiki/FrontPage],
the ZWiki.org site, or any of the public wikis hosted
at SeedWiki.com[http://www.seedwiki.com].
Experiments linking wikis togetherfor searching purposes
generally fall under the InterWiki concept (or
other names) intended to mimic Usenet servers [http://c2.com/cgi/wiki?InterWiki].
In the WikkiTikkiTavi InterWiki implementation, each
public or private Tavi wiki controls its own InterWiki
linking through a dynamically updated database [http://tavi.sourceforge.net/InterWiki];
you can jump to other wikis or conduct searches of non-wiki
Web resources. Canadian Sunhir Shah's MetaWiki inter-wiki
keyword search tool [http://sunir.org/apps/meta.pl],
based on cached page titles, is found on the Meatball
Wiki, which he edits. Jeff Dairiki's experimental,real-time InterWiki
Title Search [http://www.dairiki.org/interwiki/search.php] is
another example of how wiki developers are enhancing
the utility of the technology. You'll find an article
summarizing InterWiki in the Wikipedia [http://www.wikipedia.org/wiki/InterWiki],
one of the largest single wikis around. Other ideas and
leads about wiki data mining appear on the WikiWikiWeb
at WikiMines[http://c2.com/cgi/wiki?WikiMines] and
via the Meatball Wiki InterWiki page [http://usemod.com/cgi-bin/mb.pl?InterWiki].
Treading the Wiki Software Waters
"Potentially, the Web can become a way to structure
your workplace. If you have a server and a hypertext
editor, you can use the Web to write proposals, status
reports, and so on; your colleagues can use the Web to
insert their own comments or questions; and so on. It
can be used for collaborative authorship: Several people
can jointly write a paper or presentation. ... In the
future (i.e., after 'simple' hypertext editors are available),
special-purpose editors designed for collaborative work
may be developed."
Ed Krol,
The Whole Internet (1992, pp. 241-42)
Throughout my research and writing of this article
over 6 weeks, I downloaded, installed, and tested wiki
and wiki-like software, including a few PIM products
for comparison such as Infocetera [http://www.infocetera.com] and Treepad [http://www.treepad.com/].
Jeff McWhirter's (WTS Systems, LLC) shareware Infocetera
impressed me. Infocetera packs a lot into a compact package,
builds on Tcl/Tk, and runs on Windows or Linux. McWhirter
describes Infocetera as "a stand-alone Web server/application
that provides a rich suite of tools for information management
and group collaboration." Among the existing tools are
a wiki, selected news feeds from Moreover.com, an outliner,
and a text chat/whiteboard. He reports that the Web log
tool is not yet implemented. You can also create your
own databases, or extend existing ones, as well as import
or export text-based content into the databases.
Treepad is a more traditional, hierarchical outliner/word-processing
tool. While you can embed hyperlinks within each text
window, and import/export data in a variety of text formats,
something you can't normally do with most wiki implementations,
I did not immediately discover a way to see the existing
relationships or even find visual aids to know which "nodes" had
content. You can use Treepad, like AskSam, to generate
a static Web site. Since a wiki is by definition a dynamic,
real-time Web site, I didn't see any advantage to this
feature.
The first wiki product I tried to install myself was
the QuickiWiki script that comes on CD-ROM with The
Wiki Way. This requires downloading and installing
Perl 5. The authors recommend Perl 5.6 from either ActiveState [http://www.activestate.com] or
IndigoSTAR [http://www.indigostar.com];
the latter includes an integrated Apache Web server.
Because this ensures compatibility between the scripts
across different operating systems, they also suggest
installing Perl in the filesystem path used on Linux/UNIX
installations (rootdrive/usr). I quickly discovered that
even on following the book's direction, something was
wrong. The scripts that came on the CD-ROM were damaged,
but you can find corrected scripts on the book's support
site at http://wiki.org.
QuickiWiki runs as advertised with or without a server.
The script simulates the required server activity through
an MS-DOS window, or you can set up a free server such
as Apache (not recommended for the non-technical) to
run the QuickiWiki. Since I did not want to be bothered
with trying out all the useful "hacks" described in part
two of The Wiki Way (2001), I moved on to other
products.
Those working in corporate environments might want
to look into TWiki [http://www.twiki.com], "a
Web based collaboration platform." Originally developed
by Peter Thoeny when he worked for TakeFive, a software
development company now owned by Wind River, TWiki is
open source and hosted at SourceForge.net. This industrial-strength
wiki clone is based on the abandoned JOSWiki (Java Operating
System Wiki), not to be mistaken for the JSPWiki software [http://www.ecyrd.com/JSPWiki/Wiki.jsp].
I found TWiki difficult to install on both Windows and
Linux (RedHat Linux 8.0 in particular). Corporate user "success
stories" listed on the TWiki.org front page include,
in addition to its current corporate intranet home at
Wind River, the Disney Corporation, Inktomi, Motorola,
and SAP. The TWiki software allows developers to create
or extend current TWiki Plugins suitable to a corporate
setting. Among those available as of January 2003 are
the Database Plugin, which appears designed for PHP and
MySQL, the Spreadsheet Plugin for adding elementary spreadsheet
functions to a TWiki table, and many others [http://twiki.org/cgi-bin/view/Plugins/WebHome].
Bloggers, take note: TWiki also contains a Headlines
Plugin for aggregating RSS feeds.
Not having had much luck in installing several other
wiki clones on a RedHat 8.0 Linux PC, I finally settled
on Swiki [http://minnow.cc.gatech.edu/swiki] for
my Windows XP PC. Developed at Georgia Tech under the
direction of Professor Mark Guzdial (see the "Swiki Words" sidebar
interview withMark Guzdial on page 43), Swiki is a wiki
clone created with Squeak, an object-oriented programming
language variant of Smalltalk. I found Squeak itself
quite fascinating, as it runs on just about any microprocessor-equipped
platform imaginable, even handling digital cameras! There's
even a Squeak plugin for Internet Explorer that provides
a lot of Squeak functionality without installing the
entire application.
Swiki includes its own Web server called Comanche,
also known as CoWeb (Comanche Web or Collaborative Web).
The major difference between Swiki and other wiki clones
is the storage of pages as numbered, plain-text, XML
1.0 files regardless of what you name them, and you can
include HTML. I found the Swiki text-formatting rules
a little easier to remember, with the flexibility of
page renaming a great feature. I quickly discovered,
however, that the free Swiki.net service (see the "Swiki
Words" sidebar interview withStephen Pair on page 45
used different text-
formatting rules, and that page creation did not always work, so some page
URLs had to be encoded as HTML rather than the asteriskPage Nameasterisk pattern
used by Swiki and Swiki.net. I have yet to experience this problem with my
desktop Swiki.
ZWiki [http://www.zwiki.org] is
a wiki clone designed for use on a Zope Web/application
server. If you want a quick overview of how ZWiki differs
from the original Wiki, go to DifferencesFromClassicWiki [http://zwiki.org/DifferencesFromClassicWiki].
My initial experience with Zope left me in the BoyDoIFeelStupidCategory.
I didn't quite understand how to get ZWiki to work with
Zope, but I knew from all I'd read and learned by e-mail
over the past few years that Zope itself is an important
open source product. The ZWiki product, as internal objects,
applications, or services written in Python for Zope
are called, contains some features (and flaws) unique
to Zope. The most important feature is the ability to
mix on a ZWiki page different kinds of structured text
formats. Zope itself also implements WebDAV (Web Distributed
Authoring and Versioning), but I did not test this feature.
The simple secret to getting ZWiki accessible from a
Web browser lies in the extensive Zope security permissions.
You can test a public version of ZWiki I set up, courtesy
of FreeZope.org, at the Searchers' Zwiki [http://searcher.freezope.org/zwiki];
note that "searcher" is singular, not plural. If I haven't
implemented security correctly, I'm sure I will learn
about my oversight sooner or later. The major Zope flaw
widely discussed concerns some kind of memory leakage
problem, both within the Zope core program and from products
created to run within the Zope environment (source: Chris
McDonough, Zope.org post, January 22, 2002, http://www.zope.org//Wikis/DevSite/
Proposals/ToleratingHangsAndLeaks).
The Zope Corporation and community are also developing
a Content Management Framework (CMF) infrastructure for
Zope, which is where Plone comes in.
The first and maybe last shot in the Plone Wars was
fired on January 21, 2003, through an open letter to
the Zope community and the Zope Corporation by Robert
Boulanger, CEO and co-founder of BlueDynamics GmbH [http://plone.org/Members/zwark/plone-nzo].
In his long letter he noted that Plone [http://www.plone.org] is
the "first downloadable distribution of a Zope which
works out of the box, is free, and, most importantly,
is absolutely able to earn money in itself. It has a
great graphical design and just works. And a very big
point for the non-American world: Only Plone cares about
localization." There are 24 language translations of
Plone, "including the big Asian market." Boulanger also
boasted that Plone "kicks most commercial Content Management
Systems' collective asses." You'll find some examples
of Plone/Zope sites at the corporate level, including
the Austrian government, CBS New York, NATO, and the
Office of the Governor of Texas at http://plone.org/about/sites.
Rob Page, CEO of the Zope Corporation, fired back a reply
on January 31, 2003, that laid out a roadmap for the
future of Zope [http://www.zope.com/News/ZopeRoadmap].
The response agreed with Boulanger that Plone works out
of the box, but pointed out that users still have to
configure Zope through the Web browser interface. The
reason I call this the Plone Wars is that I believe Boulanger
is wrong on that last point. I think Plone's okole is
going to get kicked as badly as some others by some other
open source Web application/servers.
Besides the venerable Apache Web server, probably the
only other enterprise-level open source Web application/server
against which Zope competes is the AOLserver [http://www.aolserver.com/].
Yes, this is the server that powers the America Online
information service, and it is an open source product
available without licensing restrictions. There are two
exciting open source collaborative projects (dotLRN and
dotWRK) underway through the Collaboraid [http://www.collaboraid.biz/] service
in Denmark — and other Web entry points — using
AOLserver and OpenACS (Open Architecture Community
System) [http://www.openacs.org].
Among the first online sources I consulted for wiki
software was Ward's WikiWikiWeb page on WikiEngines[http://c2.com/cgi/wiki?WikiEngines].
I found many other outstanding WCMS applications, chiefly
open source, with wiki-like features by visiting the
active Web sites of just about every entry in the Google
Directory for wikis and content management system software [http://directory.google.com/Top/
Computers/Software/Groupware/Wiki and
http://directory.google.com/Top/Computers/Software/Internet/Site_Management/Content_Management].
I found the following sites especially useful for current
WCMS data: cmsInfo.org [http://www.cmsinfo.org
and RSS feed: http://www.cmsinfo.org/backend.php3], CMSWatch [http://www.cmswatch.com/
and RSS feed: http://www.cmswatch.com/RSS/cmswatch.xml],
and Transform Magazine [http://www.transformmag.com/],
along with SourceForge.net, Slashdot.org, and Tigris.org.
Besides the free wiki hosting services I tried (Swiki.net,
NetUnify.com, FreeZope.org, and SeedWiki.com), I also
looked at various WikiFarms [http://c2.com/cgi-bin/wiki?WikiFarms] and PublicWikiForums [http://c2.com/cgi-bin/wiki?PublicWikiForums].
Unless it gets rescheduled again, the third Open Source
CMS Conference [http://www.oscom.org],
hosted by this international, nonprofit association,
will be held at the end of May 2003 at Harvard University.
You can easily find many other academic and vendor conferences
geared to e-content and collaborative software, some
of them sponsored by Information Today, Inc.
Where Will Wikis Go Next?
The good news about wiki technology is, that like the
Web itself, it's here to stay. Wikis filled a small niche
near the time of the Web's birth, but that niche has
begun to widen. At its narrowest point, we will continue
to find wikis filling the humble role of helping shape
people's attitudes and knowledge about Web-based, collaborative
content creation and editing.
The bad news about wikis is twofold: Unless you implement
a wiki within an industry-standard database such as Oracle,
MySQL, or PostgreSQL, you may need programming skills
to migrate your wiki from one wiki implementation to
another. Some wiki implementations store wiki content
in database records, while others store content in plain-text
files (don't forget, XML is plain text). In both cases,
the Web site is dynamically rendered into HTML. This
is why wiki sites don't have URLs that end with the ubiquitous ".htm" or ".html." The
other major bad news about wiki is that there is no standard
way to mark up a wiki. If you do move from one wiki implementation
to another, you will need to ensure that your Wiki markup
is changed accordingly so it will be understood by the
new wiki. I was dismayed to discover that there are important
differences, for example, in the way Swiki.net allows
Swiki markup and the way markup is handled in a Squeak
Swiki or CoWeb. It's the same product more or less, so
introducing needless variations in wiki text formatting
or markup between the same basic software puzzles me.
Wikis are already overshadowed, having never emerged
as a must-have technology, by more feature-rich WCMS
products that incorporate real-time video and audio.
A Squeak Swiki can do this for users with the right kind
of programming skills; Squeak itself already contains
internal, drag and drop, multimedia support. The future
looks promising for collaborative WCMS as shown by some
of these developments around the world.
For those who take air and computing for granted, MIT's Project
Oxygen (also known as the Oxygen Alliance) [http://oxygen.lcs.mit.edu] is
worth watching because of its mission to prototype
a series of systems for "pervasive, human-centered
computing." Among the database- and personal information
management-related facets of this $50 million experiment
mentioned on the Knowledge Access page are Haystack [http://haystack.lcs.mit.edu/],
the World Wide Web Consortium's (W3C) Semantic Web [http://www.w3.org/2001/sw/],
and START, a natural-language question-answering
system available since December 1993 [http://www.ai.mit.edu/projects/infolab/ailab].
One can see how far removed the ivy-veiled halls of
New England academe are from reality, however, by visiting
the Collaboration page, where the sole reference to a
working collaborative Web-based document annotation system
is the W3C's AnnoteaProject [http://www.w3.org/2001/Annotea/].
In the Annotea model, annotations of documents (typically
a Web page) are stored on an external server and made
accessible to anyone (or authenticated users). The difference
between Annotea and wiki is that in an open wiki with
no additional extensions, you have no way of knowing
who's contributed what. A WebDAV-enabled wiki would likely
solve this problem. I expect it would be trivial to request
some form of identification as part of the authoring
process, if deemed necessary in the wiki deployment,
before accepting contributed content. On the other hand,
the core idea behind wikis is that a wiki page is always
in perpetual edit, so one does not need to know who contributed
what.
The only two Annotea server implementations available
as of January 2003 are the W3C's own server, and the Zope
Annotation Server (Zannot) [http://www.zope.org/Members/Crouton/ZAnnot/].
Annotea Web browser clients, plug-ins, and tools listed
by the W3C are Amaya (its own editor/browser)
[http://www.w3.org/Amaya/), Annozilla [http://annozilla.mozdev.org/], Snufkin[http://jibbering.com/snufkin/],
and SWAD-Europe: RDF-based Annotation Systems [http://www.w3.org/2001/sw/Europe/
reports/annotation_demo_server_report/].
You'll find more Web-based annotation software listings
at the SemanticWeb.org's site on Annotation & Authoring [http://annotation.semanticweb.org/].
A few academic projects experimenting with collaborative
WCMS caught my eye and interest.
The Connexions Project [http://cnx.rice.edu/index_html] is
happening at Rice University. Brent Hendricks, who wrote
the Zope Annotation Server, is listed as Chief Architect.
Connexions sounds very much like the University of British
Columbia's Public Knowledge Project [http://www.pkp.ubc.ca/],
except that Connexions appears geared more towards collaborative
course development and publishing, and in that sense
is somewhat like the open source Andamooka library [http://www.andamooka.org/].
Daniel Suthers, Laboratory for Interactive Learning
Technologies, University of Hawaii, is leading two projects
described in one of his co-authored publication as "online
workspaces for annotation and discussion of documents." The
projects are Kükäkükä[http://lilt.ics.hawaii.edu/lilt/software/kukakuka/],
a Hawaiian word meaning discussion, and Pink [http://lilt.ics.hawaii.edu/lilt/software/pink/index.html],
not quite ready for prime time as of January 2003, but
sounding very much like a wiki. You can try the demonstration
version of Kükäkükä. MIT is also
leading an open source infrastructure project for computer-mediated
(e-learning or online learning) educational activities
called the Open Knowledge Initiative [http://web.mit.edu/oki/index.html].
With deep connections to MIT again (Sloan School of
Management), and the University of Heidelberg, Germany, dotLRN [http://dotlrn.mit.edu/], "a
fully open source eLearning platform project" uses the
enterprise-level OpenACS system [http://openacs.org/projects/dotlrn/] "to
foster learning and to promote collaboration." Another
project using the same client/server combination is dotWRK [http://dotwrk.collaboraid.net and http://openacs.org/projects/dotwrk/].
Among the competing products listed for dotWRK are Groove
Workspace [http://www.groove.net/products/workspace/],
into which Microsoft invested, and eRoom, which Documentum [http://www.documentum.com/] finalized
its purchase of in December 2002. Documentum was named
Content Management System of the Year by the Belgian Data
News.
I think it significant that with this much open source
activity in the field of collaborative WCMS, Microsoft
is issuing dire warnings about open source software,
yet at the same time planning its own collaborative WCMS
strategy. On January 21, 2003, Microsoft announced its
agreement to purchase PlaceWare, and, more significantly, "the
creation of a new business unit — the Real Time
Collaboration Group — within the information worker
business," of which PlaceWare will become a part. I have
a feeling that Microsoft may well be on its way to becoming
the IBM PC of collaborative WCMS, unable to compete with
more robust, more open, and less expensive products.
Opinions expressed in this article are not necessarily
shared by the author's employer.
Comparison of Wiki and
Blogs
• Wikis and blogs are both examples
of groupware; each contains design elements for
collaborative work.
• The first wiki [http://c2.com/cgi-bin/wiki] came
online in March 1995, the first recognized blogs
came online and were named as such in1997 [http://www.rebeccablood.net/essays/weblog_history.html].
• You can have one without the other:
A wiki can be a blog, but a blog does not have
to be a wiki (and I think most blogs are not).
• While both wikis and blogs are
extensible to the point that they become indistinguishable,
the general design principles of wikis and blogs
remain unchanged: wikis promote content over
form, blogs promote form (temporal organization)
over content.
• All wikis include default, integrated
search mechanisms for locating content; not all
blog authoring applications and Web hosting services
contain internal seach engines.
• Wikis are by default open to anyone
within the domain served by the wiki, but can
be secured against unauthenticated (uninvited)
users.
• Blogs by default are secured against
open collaboration, but can be managed for limited
collaboration, usually via appended comments
or a threaded discussion forum.
The Searchers' SWiki Experiment
Early in my research, I set up a wiki as an
experiment and a research repository using the
free hosting service at Swiki.net. (See the "Swiki
Words" sidebar interview with Stephen Pair on
page 45.) I prefer Swiki because it allows the
use of HTML, making renaming pages easy. I was
also a bit nervous about allowing in the Others
out there who might delete something. This is
the curse of the wiki newbie. I was quickly talked
out of locking pages by one user and tried to
add comment forms to just about every page so
even unregistered users could post — but
not modify — content anonymously. The use
of frames, however, surprised at least one contributor.
If you've visited some of the wiki sites already
mentioned, you'll have noticed how minimalist
they are compared with other Web sites. Lots
of prose and very few graphics.
I posted a few e-mails to various lists to
see what kind of reaction I would get and whether
I would hook anyone to a degree that another
individual besides myself would contribute not
only content, but also structure. The results
of my experiment can be viewed at the Searchers'
Swiki [http://searchers.swiki.net].
As I concluded the writing of this article, I
decided to provide an alternate source for content,
structure, and the wiki experience via the FreeZope.org
service [http://www.FreeZope.org] provided
by Amaze Internet Services [http://www.zopewizards.com/] in
the Netherlands. I encourage you to visit both
these sites as they contain more information
than I could cram into this article. Your contributions
are, of course, always welcomed.
What I learned through my little, unscientific
experiment reinforced what I read in The Wiki
Way and elsewhere: You can lead just about
anyone to a wiki, but no one who's not sufficiently
bold or has had previous wiki experience will
take that first tentative step at changing someone
else's creation. So group dynamics in a wiki
require a dedicated group to start and keep the
wiki alive as long as it's needed. Group or community
wikis are first and foremost about collaboration:
That's the whole point of the radical (and still
controversial), open editing solution devised
by Ward Cunningham.
It's the same as with open source software
development: You're expected, if able, to contribute
a part to the whole and to make that part available
to the community. You'll find long expostulations
on the collaborative, mutable aspect of wiki
in Ward's WikiWikiWeb under such WikiWords as
PerpetualNow, TheWikiDiscontinuity, WikiIsNoSandCastle,
and WikiNature. Elements of mysticism and religion
also arise in many WikiWords as some individuals
attempt to grapple with the philosophical/metaphysical
overtones and existential "meaning" of wiki:
for example, NooSphere, WabiSabi, and ZenSlap.
Some plain-talking folks just admit their ignorance
through a WikiWord — BoyThisStuffMakesMeFeelStupid — and
let their wiki neighborhood take over. In describing
in a short, final paragraph the experimental
nature of wiki, The Wiki Way concludes
with these wise words: "People adapt. Wiki adapts."
Wiki Words Glossary
Some of these terms originate with content
management software.
Backlinks (reverse links): As defined
by Whatis.com, "a backlink is a link back to
the page or one of the pages that currently link
to the page you're using." Here's an example
from http://howto.ipng.be/openMosixWiki/index.php/InterWikiMap For
further information on backlinks see http://www.usemod.com/cgi-bin/mb.pl?BackLink and http://www.kuro5hin.org/story/2002/5/16/152614/482.
Reverse link functionality is available through
the "link:[Web URL]" search protocol in Google
and some other search engines.
CamelCase: see WikiWord.
Citation link: A specially formatted
URL allowed in some wiki markups that creates
a hyperlink consisting of a number, usually enclosed
in square brackets.
CMF: Content Management Framework, a
Zope Corporation initiative. CMFWiki is a wiki
clone implemented within this framework.
CMS: Content Management System. See
also WCMS.
Intertwingular: Memes.net, a wiki, defines
this as "many relationships between atoms of
data, not just the simple hierarchies that we
see in todays [sic] computer interfaces." Examples,
besides wikis, that promote intertwingularity
are The Brain [http://www.thebrain.com/],
Lucid Fried Eggs [example site: http://www.memes.net],
and Ted Nelson's ZigZag and Xanadu projects [http://www.xanadu.com/].
Open link: An uncreated wiki page that
results from the use of a WikiWord (or whatever
text-formatting rule applies to the wiki implementation).
Accidental open links are a problem in wikis
and result from a wiki writer not checking to
see if a page exists before creating a page with
the same content, but under a different WikiWord.
See also WikiWord and WordJam.
RecentChanges: A wiki page that lists
the most recent changes to every wiki page. Also
called Changes. A proposed wiki extension to
the RSS protocol uses the RecentChanges page
for syndication content.
Refactoring: The process of editing
existing wiki pages to create new ones, to enhance
existing links, and to reorganize the internal
structure. Defined in The Wiki Way (2001,
p. 330) as "a technical term for iterative adjustment
based on new input"; basically, rewriting, but
also restructuring.
SlashDot Effect or Slashdotting: According
to The Jargon Lexicon [http://catb.org/esr/jargon/html/entry/slashdot-effect.html], "what
is said to have happened when a Web site becoming
virtually unreachable because too many people
are hitting it after the site was mentioned in
an interesting article on the popular Slashdot
news service." The effect is unintentional, unlike
a Denial Of Service (DOS) attack.
WabiSabi: Refactoring of content in
a Zen-like fashion.
WCMS: Web Content Management System.
A client-server application category built around
the HyperText Transport Protocol (HTTP) that
includes site and content management tools. WCMS
do not necessarily include collaborative, real-time,
Web-based editing of contents by the Web site's
end user.
WebDAV: Web Distributed Authoring and
Versioning. An extension or new version of the
HTTP protocol. Zope implements WebDAV.
WikiBadge: Zwiki.org [http://zwiki.org/WikiBadge] describes
this wiki search feature as "a page which you
can add as a link to other pages, usually at
the bottom, to mark them in some way. The badge
page should describe the purpose of the badge.
View the badge page's backlinks to see a list
of all pages marked with that badge." Additional
discussion about the utility of a WikiBadge is
on Ward's WikiWikiWeb [http://www.c2.com/cgi/wiki?WikiBadge].
Wikiblog: A combined wiki and blog application.
WikiWord: A text formatting rule from
the original wiki Perl script that creates a
new wiki page, and, once saved, creates a hyperlink
to the page. The WikiWord constitutes the file
name, which in turn forms part of the URL. Using
a WikiWord again on any other page creates an
automatic link to the page, otherwise an open
link indicator signals that the page needs to
be created. Also known as Camel Case [http://www.ecyrd.com/JSPWiki/Wiki.jsp?page=CamelCase],
InterCap, and EmbeddingCapitals.
WordJam: A conflict in a new wiki page
name and real words, acronyms and abbreviations.
See also Open link.
Toward a Collaborative Networked Future
The tragic events of September 11, 2001, accelerated
an existing trend towards Web-based and peer-to-peer
network collaborative work.
The Gartner IT research and consulting firm
devotes one of its business focus areas to "Collaboration & E-Learning" [http://www.gartner.com].
James Lundy, editor-in-chief, and Debra Logan,
contributing editor, of this section, predicted
in their 2003 letter from the editor, "Users
can't wait for IS organizations to bring them
the tools and collaborations that they need to
do their jobs." In announcing through a publicly
available document the evolution and merger of
Lotus products with the IBM WebSphere/DB2 platform,
Gartner analyst Simon Hayward admits that "next-generation
products have appeared earlier than Gartner had
expected." He points out, "The options for enterprises
looking for collaboration support have become
more plentiful. While Microsoft struggles to
turn its assets into a coherent offer for collaboration
support, Oracle's entry has opened up the market,
and Novell has recommitted to this space."
In a presentation justifying its acquisition
of eRoom in the fall of 2002, Documentum devoted
a page to "The 'Buzz' About Collaboration." Predictions
from market research by META Group and Giga Information
Group are quoted to support this purchase. Mike
Gotta, the META Group analyst, anticipated 85
percent of "knowledge workers" would use "teamware
tools" by 2006. Erica Ruguillies, Giga Information
Group, anticipated similar strong, yet even more
rapid, interest in linking "team collaboration
functionality" with content management systems.
Transform Magazine named two existing
IBM Lotus products that support collaboration,
Sametime and Lotus Team Workplace (formerly QuickPlace),
among its choices for 2002 products of the year.
The magazine's Web site's lead article for February
2003 by Lowell Rapaport is "Team Collaboration
Unites the Workforce," and one of the top trends
outlined in a January 2003 article by Penny Lunt
and others discusses how collaborative technologies
are transforming business activities.
Microsoft began staking out the territory in
2001 with the introduction of SharePoint Web-based
collaborative products that include support for
WebDAV. Here is what Microsoft reported on October
29, 2002:
SharePoint™ products and technologies
have experienced overwhelming adoption by companies
implementing portal and collaboration solutions.
More than 10 million seats of SharePoint Portal
Server have been licensed in its first 17 months
of availability, and it has been widely adopted
by medium- to enterprise-sized organizations.
... In some cases users need a Web site they
can create and contribute to immediately, and
SharePoint Team Services meets those information-sharing
needs. SharePoint Teams Services is designed
for small ad-hoc teams that need a quick and
intuitive site to share documents and project-focused
work. More important, SharePoint Team Services
helps teams create Web sites that are easy to
customize and manage.
This, of course, is exactly what wiki technology
is all about, except that wiki Web server applications,
including database components, are for the most
part completely free. To its credit, Microsoft
bundled SharePoint Team Services with FrontPage
2002 and some other products, but you can only
use SharePoint Team Services with Microsoft Web
servers equipped with the required Microsoft
Data Engine or Microsoft SQL Server 7.0+. You
can locate ISPs through the SharePoint Team Services
site [http://www.microsoft.com/sharepoint/teamservices/default.asp] that
will host a subscription-based SharePoint Team
Services site for you.
Wiki Words from Bo Leuf
Co-author, The Wiki Way (2001) and Peer
to Peer: Collaboration and Sharing over the
Internet (2002). Mr. Leuf's biography is
on his wiki [http://www.leuf.com/ww/wikicom?WwwBio];
he lives in Sweden.
DM: What attracted you to the Wiki concept?
BL: Its unique combination of simplicity
and leveraging power, plus the fact that it was
open source, so anyone could hack customized
versions and play around with the concept. I
was an early visitor to the original public Wiki
at c2.com, and the rapid growth of posted co-authored
material and community feeling was quite amazing.
DM: Why do you think wikis haven't captured
the public imagination the way blogs have?
BL: That question is misleading, I feel. "Wiki
farms" have in fact spread rapidly, and many
more "blogs" than you might suspect are actually
built on Wiki or Wiki-like solutions, albeit
usually closed for edit to all but the owner.
However ... "blogging" or properly Web journaling
isn't about any particular technology, it's a
form of expression, whether the publishing tool/medium
is Movable Type [http://www.movabletype.org/],
b2 [http://cafelog.com/],
Wiki [http://c2.com/cgi/wiki?WelcomeVisitors],
or your average ftp'd HTML site. I rather doubt
the average blogger really cares about the underlying
technology as such, being more concerned with
ease of publishing, the CMS features, layout,
and referencing community.
And that is perhaps the core of what the question
intends. Wiki is primarily about co-authoring,
and most implementations tend to downplay layout
and styling. Bloggers are mostly writers of personal
journals, not likely to be interested in freeform
co-authoring. In fact, most would find the very
idea of open co-authoring both frightening and
unrealistic. The main community interest appears
to be cross-linking with other journals and commenting
these in one's own postings. Blog software has
functionality for this kind of thing, support
for calendar organizing postings, and a modicum
of styling options.
DM: What are some of the features that
make a wiki different from other kinds of content
management systems?
BL: I try to use "a wiki" for specific
implementations and "Wiki" for the concept. [The
features that make Wikis different are] Minimalistic.
Informal. Freeform content. Open source. Open
editing (though this can be restricted in various
ways). Plain text storage. Hyperlink aware and
HTML rendering on the fly. Customization.
DM: Can you tell us a little about the
Cluster Wiki concept you developed?
BL: Experimenting with a clone variant
of Ward's original, I soon had several public
wikis on a single server [http://leuf.net/ww/wikinet?WikiWebList].
Keeping multiple code bases in sync became tedious
and prone to mistakes, so the natural reaction
was to move core functionality into a shared
library. As I moved towards Wiki as a Web hosting
option, and thus even more wiki instances, centralized
code bases seemed to be the only reasonable way
to go. The defining feature of Cluster Wiki is
that each deployed wiki instance is represented
by a very short code "stub" with a unique name
and a few, largely optional, parameter values.
The stub imports the shared library, which then
knows which database to look at.
DM: What are some of your favorite wikis
and why?
BL: My own, since that's where I organize
my own information. :) Seriously, though, Ward's
Wiki at c2.com is always a place I return. It
has a large and very active community, highly
knowledgeable. A relative newcomer, Wikipedia.org [http://www.wikipedia.org] has
rapidly become a valuable Web resource. We may
also note that many support and discussion sites,
such as the Open Source discussion forums "went
Wiki" during 2001. You may now even see a loose "clustering" of
HTML site, journal, and open wiki, evidently
leveraging the best of each for different aspects
of the site.
DM: How do you see wikis changing or
influencing Web culture?
BL: For some, Wiki has meant a return
to "content" and "peer" publishing, a return
to the original design of the Web, away from
the passive content consumer model that became
prevalent in the late '90s. In this respect,
Wiki shares some characteristics with the peer-to-peer
technologies; it's P2P in the person-to-person
co-authoring sense. Wiki is in the tradition
of simple tools and few user constraints, of
community and sharing.
DM: What are your thoughts about wikis
as hypertext-based information retrieval tools?
BL: Wiki is an absurdly simple database
tool, very informal. Probably optimal for the
kind of ill-defined or shifting needs that an
individual has for organizing personal notes
or for Web-published meanderings. Less suited
to formal database environments where entry format
must be specified and access more controlled.
That said, wiki implementations have been constructed
as front ends for MySQL engines, corporate team
tools, and support sites. Wiki has scaled far
better than expected.
DM: What benefits do wikis offer corporate
culture and why should organizations use them?
BL: The informal aspect is important,
as is the co-authoring aspect. Wiki can be seen
as a better group communication/archive tool
than e-mail and distribution lists. One of the
problems with traditional, more formal knowledgebase
solutions is the bottleneck effect, that updates
are delayed through centrally managed entry.
In, for example, a customer support site, support
technicians can search and update on the fly
as they deal with customers. Others using the
same database know that the information they
see is always the most recent version.
DM: What are the disadvantages to corporate
culture of wikis?
BL: There are several reasons wikis
might not be sanctioned in corporate contexts.
Lack of control. Lack of fixed format. Lack of
accountability. "Not on the approved list of
applications."
DM: Can you connect the dots for us
between Wiki, WebDAV, and any other database-driven
permutations of collaborative software being
rolled out over the next year?
BL: Wiki is firmly based on the existing
client-server model of the present-day Web. It
builds on existing infrastructure and ubiquitous
software: Web servers with Perl script capability
are legion, any stock forms-capable browser client
can participate. No extras, which is why the
user interface is by necessity rather primitive,
and until the incorporation of CSS, the display
totally no-frills. It's also easy to add Apache/Perl
support to an MS-Windows PC, which helps the
stand-alone or local-network usage of Wiki.
Wiki is a simple server-based, node-style application,
regardless that you can run it as stand-alone
on a desktop (by emulating a Web server with
the QuickiWiki script). Some experiments have
been done to extend the concept into what is
commonly called Wiki Federation [DM: replaced
by the InterWikiMap; http://c2.com/cgi/wiki?InterWikiMap],
that is a peer network of wiki servers that exchange
data so that user requests on one in some way
leverage the content of the others. Multisite-spanning
search is one example. A very simple enhancement
is SisterSite functionality, where page links
are validated against lists of page names from
sister sites, not just the wiki's own database.
Wiki was subsequently extended by some clone
derivatives to include more explicit database
management (server-side add-on), such as RCS
(Revision Control System) [http://www.gnu.org/software/rcs/rcs.html],
CVS (Concurrent Versions System) [http://www.cvshome.org/],
or ported/integrated into larger CMS systems
(Python Zope) [http://www.zope.org].
It was also early ported to the Smalltalk environment
(Swiki) [http://minnow.cc.gatech.edu/swiki],
where the wiki easily can leverage any of the
Smalltalk operating system's native capabilities,
or that of other Smalltalk applications.
For Mac OS users, Swiki is still probably the
easiest well-supported path to go. OS X users
have native Perl and server support, so the choice
there is less of an OS-issue.
WebDAV [http://www.webdav.org] is
something different, because though some of the
concepts are the same (across-the-Web co-authoring,
for example), the implementation is primarily
by way of a longer-term change in the infrastructure
of the Web — new servers, new applications,
new client software, and above all, a new extended
HTTP protocol. This is all good and well, and
the result will assuredly incorporate many desired
features that current Wiki cannot do with its
reliance on stock clients and the current HTTP
1.0/1.1 Web protocol. Thus, WebDAV is a future
development from the perspective of users and
less malleable to individual needs. Wiki is here
and now and highly customize-friendly, if very
much a hack.
You also find a number of usually "enterprise" solutions
for Web/distributed collaboration, and these
applications are what Wiki is contrasted with
on corporate LANs. The big solutions are almost
always very client-software specific (and task-oriented),
although some of them do have Web interfaces
for general use (but perhaps specific for IE
with plug-in xyz and support for abc). The big
solutions are no doubt relevant for large user
bases and the kind of process control (hierarchy,
authentication, permissions, audit trails, etc)
that some aspects of corporate activities require.
Such contexts are not well-suited for Wiki. As
noted in the book [The Wiki Way (2001)],
corporate use of Wiki tends to be team/department-local
and "under the radar" of IT management, for informal
discussion, follow-up, and data management before
things are ready to be submitted into the formal
KB/DMS used. I expect this situation to continue,
no matter what software "rolls out" in the immediate
future.
What I've been following suggests two things,
however:
1. Use of small-scale and simple (free, open
source) solutions is proliferating rapidly on
the Web, and doubtlessly also in the largely
invisible corporate networks. Visible adoption
of Wiki and Wiki-like applications has been extensive,
practically exponential since the book was written.
I see no reason for this development to stop;
quite the opposite, as more people come into
contact with the concept. Some will probably
consider Wiki and quasi-Wiki solutions for the
Web as just another blog tool.
2. Use of P2P technology (which I wrote about
in Peer to Peer [2002]) is also spreading
rapidly within certain segments of the corporate
world and forming the basis for large scale changes
in the way we do business and how individuals
will interact with online services. Wiki-like
applications find application as part of this
new infrastructure, especially in areas such
as flexible databases for customer support, discussion
forums, and so on.
Whether or not .NET [dot NET: http://msdn.microsoft.com/netframework/]
becomes the Web services paradigm is irrelevant
in this context. The distributed and collaborative
functionality will be implemented and deployed
in one way or another, and with it some form
of greater openness for the individual user,
supported by community and trust mechanisms to
make it all work. I believe this expansion will
happen despite the pervasive repressive movement
towards closed systems and centralized content
control that is in the news currently. Technological
solutions for open systems that cannot be controlled
are already deployed on the Web, and in 2003,
a broad public backlash against content control
could easily become the dominant force as a reaction
to efforts at control having gone too far. Collaborative
software can only become more important and pervasive
over time.
Swiki Words from Mark Guzdial
Associate Professor, Learning Sciences & Technologies,
Collaborative Software Lab, College of Computing,
Georgia Institute of Technology, and lead developer
of Swiki; http://coweb.cc.gatech.edu/csl or
http://www.cc.gatech.edu/~mark.guzdial/.
DM: What attracted you to the Wiki concept?
MG: We had been doing work with computer-supported
collaborative learning for several years before
we discovered Wikis and developed Swikis. One
of our tools, CaMILE, supported Web-based annotation
of other Web documents ("anchors" for discussion).
Our studies found that anchoring discussions
led to more sustained, on-topic discussion than
newsgroup-based forums that were unanchored in
things that students cared about. For the most
part, though, CaMILE discussions and anchors
were created by the teachers. What if students
had the power to create their own discussions
and anchors? How would it change the dynamic
of how students collaborated and used the tool?
Those questions are what led us to Wikis.
DM: Why do you think wikis haven't captured
the public imagination the way blogs have?
MG: A blog is a much more structured
application. Wikis can do anything. That makes
Wikis more powerful, but also more demanding
and complex. Why is Word more popular than Photoshop
or Painter? Creating within a comfortable, structured
space like a typewritten page is easier than
being given an empty canvas.
DM: What makes a Swiki different from
other kinds of content management systems, especially
other wikis?
MG: Swikis are tuned to the audience
we're most aiming at: university teachers and
students, and the visitors that they invite.
Our users wanted to use the HTML they already
knew, and they wanted more control over page
titles than most wikis provide. We've realized
that we also have a range of users even within
this limited audience, and we've tried to cater
to those ranges. For example, some classes use
the Swiki to create a forum for involving external
visitors. These external visitors don't know
about Swikis, nor do they want to, so clicking
on "Edit" is frightening for them. So, we made
it very easy to create "Add to this page" sections
at the bottom of pages, to enable ease of visitor
input. Jochen Rick, who built our current Swiki
software and serves as the open source champion
of Swikis, and I wrote a paper for the CSCW conference
a few years ago about the user roles we noted
and how we tuned the environment to support those
users, available at http://coweb.cc.gatech.edu/csl/Papers.
DM: What are some of your favorite aspects
of and favorite (s)wikis and why?
MG: My favorite aspect of the Swikis
is how teachers have adopted Swikis and invented
terrific uses that never occurred to us developers.
The architects do this spectacularly. They've
invented wonderful activities in the Swiki, like
collaborative pin-ups and galleries, with online
debates and critical essay reviews.
Irfan Essa in the College of Computing uses
Swiki for his annual course on digital video
special effects, and those are wonderful Swikis
to visit, because his students use the Swiki
for storing everything: their storyboards, scripts,
code, rough drafts, everything. You can go look
at the students' movies, then trace back through
the movies' evolution. It's like having an interactive "The
making of..." for each of the movies.
Our English Composition classes have Swikis
where students collaboratively critique poems
and essays, and even their own writings. They're
not the most exciting Swikis to visit for outsiders,
but they're among my favorites because we've
found that the collaborative aspect has had an
important learning benefit to the students. That's
exciting.
DM: How do you see wikis (and swikis)
changing or influencing Web culture?
MG: There isn't a single Web culture.
There are many cultures on the Web. We've learned
that the same tool, Swiki, can be amazingly successful
in one course, and an abysmal failure in another
course in the same department, where students
don't participate at all. Each course is its
own microculture, with its own values and goals.
In some settings, the Swiki has had great influence.
Our Chemical Engineering School now uses Swikis
for every class they teach. But the Web is too
vast and diverse for any single Web application
to affect all of it.
DM: What are your thoughts on wikis
as hypertext-based information retrieval tools?
MG: That's not really something we've
explored much. We're much more interested in
the role of Swikis in supporting learning, and
then studying how they get used.
DM: What benefits do wikis offer the
education system and why should they be used
as part of the curriculum?
MG: We've seen uses of the Swiki where
it's had an important role in helping students
to collaborate and become more engaged in the
course material. Learning scientists refer to
this phenomenon as "shifting the agency." In
most classrooms, the teacher has the "agency," the
control, the driving force — the teacher
asks the questions, the students respond. But
in the real world, each of us have our own agency.
In that sense, the classroom works backwards
from the real world. In the real world, if you
have a question, you go to an expert who knows
the answer, then ask him or her the question.
But in the classroom, the teacher typically already
knows the answer, but is asking the students
the question, and they may not know the answer.
The Swiki offers the opportunity to shift the
agency into a more realistic state: Students
ask questions, make the pages, even create their
own activities.
One night, while working to meet a deadline,
a group of my students decided to create a "Choose
your path" adventure game. Someone posted a few
pages, and the rest of the class joined in, and
soon there were a few dozen pages written by
a whole bunch of students. They decided to do
that, they took control of the Swiki, and they
just made it happen.
DM: What are the disadvantages to the
education system of wikis?
MG: It's scary for teachers to give
up control over their students. Today, we increasingly
demand our teachers to be more accountable for
their students' learning and for their time.
In my kids' school, recess was outlawed as unproductive
time. However, that's not how learning works.
Learning is an individual, purposeful activity,
and if you can cajole students into taking charge
of their own learning and to inquire about useful
and interesting questions, they learn much more
than if tightly controlled and lectured at. Our
research suggests that students succeed in the
more free-form world of Swikis, but only if the
teacher and classroom culture supports that freedom.
Otherwise, the students stay away and just wait
to be told what to do for their A.
DM: What does the future hold for Swiki?
MG: It's entirely dependent on the open
source user community. We're not actively adding
features to Swiki now. We've reached a point
where we're happy with the interface and performance,
and we're focusing on exploring its use. That
doesn't mean that Swikis are no longer being
improved. As the user community develops fixes
or enhancements, these get posted to the mailing
list, and Jochen Rick culls the best or most
generally useful of them and incorporates them
into the next release — in true, open source
style.
Swiki Words from Stephen Pair
Co-founder, Advantive Associates, Inc. [http://www.advantive.com/],
Marietta, Georgia, who provide the free NetUnify.com
and Swiki.net hosting services. The company introduced
both services in 1999 and states that in 2002
the combined total of registered users numbered
more than 6,000. The company will release version
2 of Swiki.net this year.
DM: Why is your company providing this
free service?
SP: We are offering Swiki.net as a free
service for a couple of reasons: a) it will eventually
have features that can be added to an account
for a fee; the current service helps us establish
ourselves while we work on the site that will
(hopefully) generate income; b) the software
that powers Swiki.net is a comprehensive Web
application development and deployment platform
and will serve as the basis for additional offerings
that are not related to Swiki.net; it will enable
users to design, develop, and deploy Web applications
very quickly.
DM: Why do you think wikis have not
taken off the way blogs have?
SP: Blogs provide more structure for
content than wikis. A very common form of publishing
is the individual or community news item. And,
the way that blog entries are organized by date
and time fits very nicely with this form of publishing.
Blogging capability is something that we would
like to add to Swiki.net in the future.
DM: What are some of the features that
make a swiki different from other kinds of content
management systems, including the classic Wiki
as initiated by Ward Cunningham?
SP: The most obvious difference between
Swiki.net and traditional wikis is that there
is no software that the user has to install and
host. In addition, Swiki.net offers some additional
privacy features. Compared with other content
management solutions, Swikis (and wikis in general)
are more peer to peer in their publishing paradigm
and offer greater flexibility (at the expense
of more structure) in the organization of content.
Wikis also tend to be self organizing.
DM: If you have any favorite swikis
or wikis, what are they and why?
SP: I participate in so many wikis that
it's hard to pick a favorite. Some wikis are
informational in nature and less participatory.
A couple of good ones are echostar.swiki.net
and gtw.swiki.net. Others are associated with
software development such as eclipsewiki.swiki.net.
Still others serve as quasi CRM solutions like
ostudio.swiki.net and stx.swiki.net. Many people
(myself included) have personal Swikis that they
use to organize their personal information. And,
a few companies use Swiki.net for their intranet.
There are also Swikis for clubs, families, pictures,
and neighborhoods.
DM: How do you see wikis changing or
influencing Web culture?
SP: I see wikis helping to decentralize
the publishing of information. The Web started
as a largely one-way communications medium. In
a traditional Web environment, the distinction
between publishers and viewers is quite distinct.
Wikis simply make it easier to be a publisher
of information.
DM: Do you have any thoughts about wikis
as hypertext-based information retrieval tools?
SP: Structurally, wikis are organized
just like the Web in general is organized, so
any general-purpose Web search engine can index
and retrieve content that is wiki-based. But,
since most Wiki engines more closely manage their
content, they do have potential for enhanced
information retrieval capabilities. For example,
page links in most wiki engines are bidirectional.
This makes it possible to navigate to all referers
of a page.
DM: What benefits do wikis offer corporate
culture and why should organizations use them?
SP: Wikis can be very helpful in an
organizational setting. Most work within an organization
is done in the context of a project. Wikis are
very useful in serving as the "home page" of
a project and being the place where team members
collect and organize their thoughts, work, and
research as they relate to their project. In
the context of a project, having a place to organize
information is critical. In projects where I've
used a wiki, it's amazing how much information
is collected and organized over time that would
ordinarily get lost in the e-mail shuffle. I've
often found information in such a wiki and thought, "Wow,
I'm glad we didn't lose that." ... Then I'd realize
that if we were only using e-mail, the information
would have been lost, and I wouldn't even have
realized it.
DM: What are the disadvantages to corporate
culture of wikis?
SP: I don't know that there are any
disadvantages. Perhaps just the fact that wikis
can be new to an organization is a disadvantage.
They could also subvert a normal flow of information
in an organization. But I'd say that in an agile
organization, it's important to encourage informal
lines of communication. And, finally, as with
anything novel, there can be an overexuberance
about it, which can lead people to use it in
places where it would be overkill or not a substantial
benefit. |
|
