Application and Case Studies

Xanadu

Xanadu is a groundbreaking collaborative hypertext system begun in the sixties and developed, through several complete rewrites, through the nineties. Xanadu will be remembered, when it's remembered at all, for its status as the first hypertext system. Designed and implemented by the man who coined the term "hypertext" and developed most of the underlying concepts, Xanadu was the explicit inspiration for Hypercard, Lotus Notes, and the World Wide Web ([Xanadu2001] [BernersLee1989]).

Xanadu's visionary architect and project leader was Theodor Holmes Nelson, who had training and experience as a philosopher, sociologist, and computer scientist before he embarked on the project. Nelson spent decades writing about Xanadu explaining and justifying the design of the system as it was constructed and reconstructed. Xanadu's stated goals were to create "a magic place of literary memory and freedom, where nothing would be forgotten" [Xanadu2001].

In his "shortest description" in Literary Machines, the self-published book in which Nelson lays out the philosophy and design of Xanadu, he describes the document publishing system as "a fast linking repository with windows and criss-crossing super-documents" ([Nelson1981] 3/2). Understanding Nelson's description, and the system itself, requires readers to first become familiar with concepts of windowing, linking, document repositories, criss-crossing, and super-documents, most of which Nelson defines and describes in his nearly one hundred page introduction to the system. As a consequence, describing Xanadu fully is impossible in any short essay. Fortunately, Xanadu can be understood as an intriguing and unique example of a collaborative tool even with an incomplete knowledge of the system.

To make matters worse, there is no single or authoritative version of Xanadu available; the software is available to the public in at least two radically different versions.[1] Additionally, its authors put a large deal of their effort into the design and development of a front-end/back-end interface protocol to free users from dependence on a single interface and method of interacting with the data.[2] This allows for a system that affords a great deal of flexibility, which of course is a plus, but it comes at the expense of consistency in interface and interaction with the software. This makes describing the system difficult.

Figure 3-1. Xanadu: link source

Figure 3-2. Xanadu: link target

However, every version of Xanadu is based on a single philosophy of literature and collaboration. Nelson sees literature as "an ongoing system of interconnecting documents" and Xanadu is an attempt to create a system that codifies this philosophy and allows for the kind of borrowing, influence, and collaboration that he feels defines literary connections ([Nelson1981] 2/7). The technical implementation is in "links" that are often similar to the links found on the World Wide Web. However, Xanadu's links are more complex and nuanced than Berner-Lee's. Every link connects a source (see Figure 3-1) and target (either a point or a part as in Figure 3-2). While Xanadu's links can act like "jump links," similar to those on the web, they can also act as "quote links" which are described by Nelson elsewhere in Literary Machines as "windows" onto another text in the Xanadu system. Additionally, the system treats both footnotes, marginalia and commentary as links of different types. Readers or authors mark any number of targets and sources (a link need not have only one source and one target) and then chose the type of link they want to insert from a menu (see Figure 3-3).

Figure 3-3. Xanadu: "Select Link Type" menu

Any document placed within Xanadu can be linked, in any of the ways listed above, by any author and in any document. Through windowing or quote linking, a text can be manipulated and reused while simultaneously guaranteeing the original author attribution, original document integrity, and compensation. As Xanadu is a system where documents can be easily created, augmented and reworked by others, it harnesses the power of people working together to create better documents and facilitates collaboration in an unusual but powerful way.

If for example, I thought that Hans Christian Anderson's Little Mermaid's ending was too sad, I could create a new version that was almost entirely a window to the original text but that included my own more up-beat ending. If Anderson were still in control of the copyright, he would receive a proportional amount of compensation each time my work was purchased or read (the vast majority in this example) and all of the attribution for his contribution to the given work. In this way, with a couple clicks of the mouse, new and ad-hoc literary collaboration is born within the Xanadu system.

Documents might be nothing but collections of windows to other documents forming a sort of collaborative literary collage. In turn, these windows might also include windows or quote-links to yet another set of documents. In each case, the system will keep track of where the data is "really" stored and represent the text's inclusion in other documents as a series of nested windows. The system retrieves and assembles documents each time they are requested. At any point, readers can navigate through a window to instantaneously see the source of a quote, passage, or idea, or see the list of all places which have linked or windowed to a targeted point or section.

Vastly different from every other system analyzed in this study, Xanadu's collaborating authors do not work on the same document at all, but work on copies (windows actually) of documents belonging to others. The product, in each case, is single document made of of references and sums of changes to existing texts.

Each user is in full control of their own documents but cannot control the ad-hoc creation of new documents windowing to their text. The system has no enforced hierarchy or roles with the exception of technical administrators, who have access to the back-end server configuration and the unique capability to remove documents altogether. The system is flexible enough to allow labor divisions, like the creation of editors, to evolve organically and meaningfully. As each user creates their own copy of a document and edits it, the system works asynchronously without any problem. However, two users working simultaneously creates divergent copies and the system provides no explicit technical method to assist in merging divergent texts.

However, Xanadu includes the functionality to make this type of comparison easy and possible. In perhaps its most impressive design element, it is built upon a robust version control system. Links will automatically update to the latest version of a paragraph or sentence or, if the text has been removed or changed radically, to a version found within one of the archived older documents. New revisions begin as new documents containing a single window to the entire previous revision; changes are additions to, deletions from, or replacements within this window. The document compare window in Figure 3-4 illustrates the way that links interact in a revised document to concisely and unambiguously describe differences.

Figure 3-4. Xanadu: comparison of documents

Nelson makes it clear that he conceives of Xanadu not as a collaborative writing tool but as "a system for selling data online" ([Callister1995]). As a result, functionality to integrate intra-project communication or face-to-face meetings is non-existent. More importantly, existing implementations are hardly usable for anything other than experimental and historical purposes. However, Xanadu is an intriguing experiment because, while even its own authors did not conceive of Xanadu as a system for collaborative production of literature, it is founded in and reflective of a collaborative approach to the literary process. What is most interesting about Xanadu and Nelson's philosophy is that it tries to balance a desire to maintain very conservative ideas of ownership, attribution and compensation—even extend their them—with a social constructionist philosophy of literature and knowledge that de-emphasizes individual control.

In its current undeveloped state, Xanadu is probably not the right technical tool for any collaborative project. However, its approach to collaboration is broad, novel, and unique enough to warrant continued evaluation and provide meaningful and useful inspiration.

The WikiWikiWeb

Wiki[3] is a Web-based hypertext system not unlike Xanadu in many regards. Both systems support dynamic linking within an enclosed system (as opposed to the World Wide Web for example), extensive support for collaborative revision, and integrated version control. As a result of several subtle but core differences, the history, experience, success, and nature of the two systems differ wildly. Ward Cunningham claims that he chose the term "wikiwiki," the Hawaii word for "fast" or "quick," because "QuickWeb" already referred to another program. Cunningham, usually abbreviating the terms to just "Wiki," describes the core concept as being "at once both so simple and so novel that it is difficult to grasp" ([Leuf2001]).

Figure 3-5. Wiki: example page (PHPWiki)

In his book on Wiki, co-authored with programmer and collaborative writing facilitator Bo Leuf, Ward Cunningham describes wikis as "freely expandable collections 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" ([Leuf2001] 14). Put more simply, Wiki is a collection of interconnected web page where anyone, including people without specialized knowledge, computer savvy, or extra software, can create, edit, and reorganize World Wide Web content quickly and easily. The authors elaborate and describe the three essential goals and mechanisms employed by Wiki:

  • A wiki invites all users to edit any page or to create new pages within the wiki Web site, using only a plain-vanilla Web browser without any extra add-ons.

  • Wiki promotes meaningful topic associations between different pages by making page link creation almost intuitively easy and by showing whether an intended target page exists or not (See Figure 3-6).

  • A wiki is not a carefully crafted site for casual visitor. Instead it seeks to involve the visitor in an on going process of creation and collaboration that constantly changes the Web site landscape ([Leuf2001] 16).

In each of these ways, Wiki attempts to facilitate collaboration by making the system as simple, accessible, and flexible as possible.

Figure 3-6. Wiki: links (PHPWiki)

A Wiki page (pictured in Figure 3-5) looks like a normal, albeit a text-heavy web page. However, unlike other webpages, each Wiki page has a button or link at the bottom that allows every user to edit every page.[4] Upon clicking these links, users are presented with a large text box containing the contents of the page in an editable form (pictured in Figure 3-7). Noting that the Hypertext Mark-up Language (HTML), the computer language that webpages are written in and that your web browser understands and translates into viewable pages, is unfamiliar to most web-surfers and prohibitively complicated for many, Wiki make use of a simple set of text formatting rules visible to users editing pages. The provided key acts to both describe the mark-up in the edit box and to explain how the user, even if they are unfamiliar with wiki mark-up, can make changes of their own. Wiki mark-up (described in Figure 3-8), is designed to be as simple and accessible as possible. For example, underling a word or phrase is as simple as affixing underscores ("_") to each side of a word or region; creating a bulleted list is a simple as beginning each bullet on a new line with an asterisk ("*"). The hope is that within 15 minutes, everybody can begin writing and changing making Wiki webpages.

Like Xanadu, linking is an essential concept in Wiki. However, unlike Xanadu, Wiki pages do not belong to individual authors. All pages in a wiki belong to all members of the community; all readers of a page are potential co-authors or collaborators. Links are important because, through linking, ties between different texts are rendered explicit and documents can borrow, hook, hint, and connect with other texts. Linking in Wiki is limited to "jump links." Creating links is as simple as running capitalized words together: "HowToUseWiki" is automatically a link. However, because wikis are enclosed systems, links to targets that do not yet exist are marked as such (see Figure 3-6). As a result, Wiki authors can leave visible hints and suggestions to their collaborators and to themselves about directions they want to take a text.

Figure 3-7. Wiki: "edit" page (PHPWiki)

Figure 3-8. Wiki: PHPWiki's summary of text formatting rules

Leuf and Cunningham claim that "Wiki is inherently democratic—every user had exactly the same capabilities as any other user" ([Leuf2001] 17). By describing the method as "democratic," the authors make explicit reference to the political ramifications and the context of control created by the non-hierarchical editing structure in Wiki, a system they call "open editing." The only possible exception is that in many implementations and clones, there are administrative users who have special abilities to "lock" pages (mark them as temporarily or permanently unchangeable), and to get access to statistical information on wiki usage and the technical ability to make or restore backups. Aware of these possible and considered exceptions, Leuf and Cunningham's comments speak to extremely non-hierarchical, unobtrusive, and flexible nature of control that create a highly dynamic and flexible technical environment.

In most incantations, Wiki works synchronously. However, because Wiki is web-based and each user edits a single master copy on a web server, latency issues are minimized and every user is aware of a changed version instantaneously. On each Wiki page, is a link to a list of recent changes and edits is provided so that each user can consult to determine if another author is working on a given document (see Figure 3-9). This ability to track changes provides a way for a Wiki author to easily find the sum of changes made to a work. Many wikis provide list of all pages that have changed since the last time an author visited. While unlikely, it is possible that if two users are editing a document simultaneously, the second might overwrite the first's changes. In these cases, rare even on the largest and most actively modified wikis, the overwritten changes can easily be reintroduce through Wiki's strong system of version control.

Figure 3-9. Wiki: "Recent Edits" page (PHPWiki)

Using strong version control, Wiki saves every version of every document. As such, authors tracking the "Recent Edits" page can easily display a neatly formatted description of the differences between the current version of a file and the most recent, or between any two arbitrary version of a file (see Figure 3-10). By tracking changes over time, different authors are able to work asynchronously and without a huge investment in extra-textual communication.

Figure 3-10. Wiki: "Show Difference" page (PHPWiki)

Wikis approach to facilitating communication is interesting because it is completely unintentional. Unconsidered by Cunningham while designing Wiki, Wiki itself has been adapted by users to facilitate both intra and extra-textual communications. When Wiki authors commit a change, they leave short (one line or so) summaries of their changes. While this is useful to those skimming a particular wiki, this functionality cannot facilitate meaningful dialog between Wiki authors. Using the system itself, long conversations are often executed as series of edits to a single page. Each author simply edits a page and adds a bit to the bottom (or to a relevant place that signifies that it is in response to a particular comment). These conversations occur on dedicated Wiki pages and in reserved sections of normal pages to comment on the page topics. Complex systems of notation and etiquette help shape and frame these conversations. While kludgey, or an ugly hacked-together solution, this answer is surprisingly effective in its simplicity in generating, and preserving, meaningful discourse on a topic.

Much in Wiki arises from custom and kludge. While often ugly or unpredictable, these solutions speak to Wiki's immense flexibility. This flexibility has translated into success. The first Wiki run started by Cunningham for the Portland Pattern Repository (available online) expands at over 500 new wiki pages a month. Wiki has facilitated dynamic interconnections between previously unconnected communities and more separated "walled gardens." As Wiki is used by more people in more places for more purposes, the potential for Wiki has yet to be fully revealed. Through its dynamic and flexible articulation of control, Wiki has taken on a vibrant life of its own.

Wikipedia is an impressive project to build a Wiki-based encyclopedia as well as a good example of how wikis can be used. Wikipedia, which has partial translations into twelve languages, currently has 115,606 articles in its English version. These are articles are well cited, heavily cross-referenced, and often very long. Because every reader can edit each page, controversial pages, like those on the Israeli-Palestinian Conflict, represent compromises by going into great depth and describing the conflicting positions of authors on both sides. While it's possible for someone to erase or modify pages maliciously, this happens extremely rarely and, through version control, can easily be undone. Although the system is extremely open, it's also extremely edited; each entry is edited each time it is read.

The collaborative powers of Wiki have been harnessed by several other ambitious web-based projects like Wikipedia. One, the Wikitionary is a Wiki-based project attempting to build a massive cross-referenced dictionary. Wikis are also used by individuals and small groups; I used a wiki for the organization of notes for this project. It provided a quick and flexible way of organizing my thoughts with the full ability to insert cross references, links, and to keep track of the changes over time. Wiki has been put to use at Georgia Tech and in an large number of classes and educational institutions, at Motorola and a growing number of corporations—in the Debian Project and growing number of non-profit organizations ([Leuf2001]). Wiki has been recognized as a useful way for a product, systems, or technical solution to "self document:" both users and designers can insert, update, and change documentation as the software changes, as bugs are found, or as shortcomings are recognized.

Modern Word Processors: Microsoft Word and OpenOffice.org

The following analysis need not dwell long on the introduction of contemporary word processors like Wordperfect and Microsoft Word; they are doubtlessly familiar to the vast majority of readers. As the primary mode of electronic textual composition, it is unsurprising that those wishing to compose electronic texts collaboratively have immediately looked to familiar software. As the Internet has massively increased the amount of communication and collaboration possible, designers and programmers of word processors have scrambled to keep up. Originally quite simple and highly designed for the individual production of text, word processors have been repeatedly reinvented.

While Microsoft Word and Corel Wordperfect are probably the most widely used word processors, they are both proprietary, "closed source" software. In addition to the intense quality of inflexibility this adds in a way described in the Section called Flexibility, the inaccessibility of source code makes it impossible to analyze each in the manner used in previous case studies. However, there are a number of free/open source software word processors available.[5] Of these, OpenOffice.org, a free software spin-off of Sun Microsystem's Star Office, is by far the most similar in design, layout, and functionality to Microsoft Word and Corel Wordperfect. While the figures and descriptions pertain to my experience with OpenOffice.org, they will, in almost cases, describe parallel functionality in Word and Wordperfect.

Figure 3-11. Word Processors: basic view (OpenOffice.org)

Word processors, for the most part, develop text in a "What You See Is What You Get" (WYSIWYG) method (see Figure 3-11). Most go so far as to display the edges of the printed page that will be produced to frame the users workspace. While taken for granted by many users, WYSIWYG technology imposes limitations the nature of what can be written—one can only get what one can see and a link is complex to represent on a printed page. Both Xanadu and Wiki documents have viewable forms that are manipulated and changed through modification of distinct document "source" not unlike computer software; word processors collapse this difference.

Unlike both Wiki and Xanadu, the product of word processors is printed pages. Links and explicit systems of interconnected documents are either meaningless or must be articulated in very different ways on a printed page. One can refer readers to links but unless one is going to supply printed copies of all literature within the web of links within which a given documented is embedded, and this is rarely practical, these references are rarely followed.

However, as Chapter 2 demonstrated, the collaborative production of printed text is at least as possible and precedented as electronic textual production. Features useful or necessary for collaboration have been tacked onto word processors in the course of the genre's evolution. While meaningful, the post facto nature of much of these additions, and of other functionalities' continued absence, has hindered the word processors' total effectiveness at promoting meaningful collaboration.

For example, OpenOffice has no integrated method for limiting access to documents; anyone with access to a document can do anything they wish with it. Since there are no centralized servers, every user with a document has ultimate and unmediated control over the text. As the Section called The WikiWikiWeb has shown, this lack of structure can facilitate flexibility that can increase the effectiveness of the writing process. However, Wiki facilitates non-hierarchical access to a single centralized repository; while users feel empowered to make major changes, there changes are always described in a single authoritative copy. With word processors, there can easily be as many incompatible—often impossible to merge—copies of a documents as there are collaborators.

The result is a need for non-technical systems of organization and roles outside those provided by the word processor. For example, one collaborator might be designated as the editor or document leader and every change made by every collaborator must be proxied through this individual onto a single authoritative text that is controlled. The side effect of course, is the insertion of a single individual with ultimate control; the replacement of technical proxying mechanism with a human one. Another option is the "round robin" model where each collaborator makes a change before passing the document to the next person in a circular list. While eliminating individualized control, this sacrifices the asynchronous element of collaboration; you can only edit when it is your turn. These two methods, while far from exhaustive of the ways that users of word processors can structure collaboration, are indicative of the way that systems built around word processors involve serious negative side effects.

Figure 3-12. Word Processors: show changes mode (OpenOffice.org)

Perhaps the recently added feature most meaningful to collaborators is the ability to record, track, show and manage changes made to a document. In many cases, two versions of a given document can be compared with a resulting third document describing the changes as additions, removals, and formatting alterations wherever possible.[6] Changes are usually highlighted in a noticeable color and deletions are struck out (see Figure 3-12. While mark-up changes are recorded, they are often difficult to describe or convey in a WYSIWYG environment; for example, it's difficult to implicitly represent the merger of two paragraphs in a way that makes sense.

With this ability to represent changes come the ability to record them; with the ability to record changes comes the ability to step through them one-by-one and apply or reject each given change. OpenOffice.org provides a window with a list of all changes recorded into memory. When a change is selected in this window (see Figure 3-13, the changed text is highlighted in the document (see Figure 3-14). Using this feature, a collaborator can easily compare a new version of a document to an older copy, see the list of changes, and walk through each change considering each individually and applying or rejecting each. The usefulness of this feature for the purposes of collaborative writing, particularly editing, is readily apparent. By making changes visible to users, word processors succeed by breaking out of the purely WYSIWYG model.

Figure 3-13. Word Processors: accept/reject changes - Picture 1 (OpenOffice.org)

Figure 3-14. Word Processors: accept/reject changes - Picture 2 (OpenOffice.org)

This type of breaking out of the WYSIWYG model reflects a transition to what the author of the rather atypical word processor LyX calls a "What you See Is What You Mean" (WYSIWYM) environment. Increasingly common, this model is proving increasingly effective. For example, OpenOffice.org is able to embed inter-textual comments that, while visible to those editing the document, are not displayed when the document is printed. These comments can be placed either at points or in reference to regions to allow meaningful commentary on the text. However, they act only as one-way communication devices and, outside of a two person collaboration, do not easily support the display of inter-textual dialog between for the benefit of other collaborators.

The ability to leave comments and track changes is extremely important for collaborative writing using word processors such as OpenOffice; however, this type of functionality is still the exception, not the rule for word processors. As a result, word processors are often combined with other software systems in collaborative writing projects. Networked filesystems of groupware systems have been adapted to provide version control to word processor documents. External version control systems can keep track of old versions. Email, mailing lists, and Internet Relay Chat (IRC) or Instant Messaging (IM) systems are used to increase communication between collaborators. Each of these, while not uniquely helpful to word processors, can play an essential role in augmenting the use of software like OpenOffice.org for collaborative purposes.

At the end of the day, the fact remains: like Xanadu, word processors are not collaborative writing tools at all. They are tools designed to assist individuals to write which, because of their wide popularity, have been adapted for collaborative purposes. Through their strong individualization, these tools articulate control in a way that makes collaboration more difficult. While changes to the software in recent years have pushed word processors through an increasingly reflection and more meaningful facilitation of CSCW, the softwares shortcomings have had an impact. As a result, they seem less likely to succeed as tools for collaborative writing than those geared toward production of text for use within the new mediams of distribution and geared particularly toward collaborative production.

Notes

[1]

Xanadu's technology was proprietary and secret for several decades. As it became increasingly clear that the World Wide Web was succeeding in Xanadu's niche, the Xanadu Operating Company (OC) transfered intellectual property rights for most of its code and trade secrets to a new company, Udanax, which released two version of Xanadu as free/open source software. It is important to note that the trademark for Xanadu was not transfered so the software was renamed Udanax before it was released. The literature and documentation used in this analysis refers to Xanadu but the software I have access to is Udanax. From a technical perspective, this is inconsequential; the difference lies only in the ownership and use of the Xanadu trademark. To avoid confusion, I will refer to the software as "Xanadu" throughout this section. Keep in mind that the screen shots and my own impressions are of a version of Xanadu renamed "Udanax Green."

[2]

In fact, no production quality client was ever created by the Xanadu team. Not until Udanax was released to the public was a simple front-end hastily constructed to demonstrate the Xanadu server's capabilities. All the figures below are made with this rather primitive Udanax Python front-end distributed with Udanax Green.

[3]

Wiki's author suggests that the term "Wiki" should be used to refer to the essential concept while the particular implications be called "wikis" ([Leuf2001]).

[4]

Logging into a Wiki is almost all cases optional and rarely even involves entering a password. The point of signing in is not to provide authentication but simply to provide a way for a series of changes to be associated with a single author or individual and allows for more organized discussion around a particular page or change. One author could sign in using multiple usernames. Similarly, multiple authors might share one username, or simply choose work anonymously at any point.

[5]

In testing software for this article, I used the free word processors KWord, Abiword, LyX and OpenOffice.org and the proprietary Star Office 6.0, Microsoft Word 2000 and Corel Wordperfect 8.0 Personal edition.

[6]

This is in contrast to the slightly more useful model of displaying additions, subtractions and changes. While all changes can be described as the addition or subject of text, this description is often awkward of difficult for humans to interpret correctly . Because in most non WYSIWYG editing environments, mark-up and formatting is explicit, physically written in the text like "<emphasis>emphasized text</emphasis>" or "\emph{emphasized text}", there is is no need to distinguish between mark-up and text changes.