Twenty years ago, technologists might have optimistically attempted an exhaustive analysis of computer supported collaborative writing (CSCW) software. Since then, the role of collaborative writing in the corporate and industrial sectors has been demonstrated to be more widespread and more important than even its staunchest supporters had imagined ([Ede1986a]). The world has witnessed the rise of free and open source software, the Internet, and a vibrant academic discourse around collaborative writing. As a result, the world of collaborative literary technology is a very different place. Today, merely assembling a list of CSCW software might prove impossible.
However, questions and processes at the core of such an analysis remain unchanged and unanswered. Which processes qualify as facilitation of collaborative writing? Which do not? Is synchronous collaboration less meaningful than asynchronous collaboration? What about access control, decision-making roles, change tracking, intra-project communication and integration with real world meetings? How does of each of these areas of analysis help define collaboration? In what ways? How do these areas relate to each other? How do they help us make sense of a given technology?
This document will not attempt to provide definitive answers to these questions. Twenty years of research and discourse around collaborative writing has demonstrated that no definitive answers exist. There are innumerable technologies facilitating collaborative writing not because the best way to do so is unclear but because the "the best way" is nonexistent. As every collaborator works differently, every collaboration is different. Approached from a perspective that prioritizes flexibility, this can be a strength of collaborative processes.
This essay attempts to give technologists analytical tools to evaluate both the nature of how a given technology facilitates literary collaboration and, as an extension, how well it is poised to succeed in facilitating collaboration in the ways and to the extent that different analysts find most important. The essay prompts readers to personalize this central analytical question and to ask: "How do I want to collaborate, and how can computer technology help me to do it?"
To answer this question, this essay describes a method for the evaluation of CSCW technology centered around the way that control is articulated in the design and implementation of the software. It is control—articulated technically as design decisions—that defines and limits the nature of collaboration. The methodology introduced in this essay includes an introduction of several areas of analysis through which computer technology attempts to control collaboration. Once introduced, it will be employed in the analysis of several existing or historically important CSCW technologies as case studies.
Collaboration is largely undefined in a broad technological sense. In a technical context it has been reduced to a buzzword: everybody loves it and every user wants it and every technology seems to support it—but nobody seems to know what it is. When "collaborative" means something different to each individual and in the context of each "collaborative" technology, the label becomes effectively meaningless.
Farkas' four-pronged definition, referenced in Chapter 1, provides a useful place to begin. While Farkas offers four definitions, it is his last definition, "one person working interactively with one or more persons and drafting a document based on the ideas of the person or persons," that is of primary interest to this argument. A technology that can facilitate two authors working on the complete text of the document can, with slight modifications—perhaps even managerial or other non-technical changes—also facilitate two authors contributing parts or the process of editorial review. While more difficult to implement, technology that extensibly and flexibly supports the type of collaboration in the first, more "problematic" in Farkas' words, definition, will always be more nuanced, flexible, and advanced than technologies that only support one or more of the last three.
Building from Farkas' definitions, my own concept of "meaningful collaboration" describes processes that are flexible enough to encapsulate all four of the types of collaboration listed above in broader, more flexible ways. By de-emphasizing the importance of compartmentalization, fixed roles, and territoriality implicit in the three final definitions, a collaborative project has more control of the structures and code that control the way you collaborate. For these reasons, it this definition of meaningful collaboration, and the power and flexibility that it affords, that is the central focus of this essay.
This methodology defines a philosophical and sociological approach to technological analysis of CSCW technologies. It argues that effectiveness is achieved through the analysis of processes, not code. While code occupies a central position, this analysis focuses on the processes shaped by code that define the way we collaborate. As a result, these questions look at code not as the implementation of technical specifications but as the implementations of processes encoded in technical specifications and re-encoded, always slightly differently, in code itself.
This section is divided into several technical areas of analysis. It aims to serve as a useful model for a deep analysis of collaborative technologies and does not attempt to be exhaustive. In each of the following cases, the central and underlying question can be articulated as one of control. The following descriptions is both descriptive of and highly dependent on the existence of this connection.
It seems obvious that new types of collaborative literary technology implementing new collaborative literary processes will result in new types of collaborative literature. In defining and limiting the scope of this analysis, we must again look at the question of "what constitutes collaboration," and the question of "what constitutes literature." New technology has further confused both questions.
If we begin with a dictionary definition of literature, like "learning; acquaintance with letters or books" ([Webster1913]), we have "limited" our discussion to nearly everything on the Internet. Email, the web, and instant messaging, the three most popular, most used, and in most cases most useful part of the Internet, are purely literary medias. While I feel that these forms are interesting, important, and increasingly influential, I must also acknowledge that I can not analyze every Internet-based communication technology.
By focusing on products like novels, reports, letters and dictionaries with clear historical antecedents, I can speak to the concept of collaborative literary work more generally and effectively. More importantly, the type of collaboration that products like mailing lists and web logs facilitate is less meaningful because control, and the medium as a result, is highly compartmentalized. The product of these technologies are single texts but are not controlled as a single entity. The final product is fragmented.
In addition to an important step in the definition of scope for this analysis, this consideration of product is the first step in the analysis of any collaborative writing technology. Most collaborative writing systems create a single type of document. However, the types of documents produced vary widely between applications. Collaborative processes are frequently employed in the the production of hypertexts (non-sequential texts) and many collaborative tools produce electronic documents. Others are geared toward traditional printed work. Eliminating systems facilitating the production of unsuitable or desirable document forms is an important and intuitive first step in any evaluation.
It is important to remember that products reflect the processes that create them. Processes hinging on less meaningful compartmentalized collaboration tend to create documents that are highly structured and logically broken up into pieces. Editors are often employed to mediate this effect—newspapers are a strong example of the effects of this type of compartmentalized work; a newpapers may comprise articles from hundreds of authors working for a large number of organizations and a paper's editor will rewrite and change the articles to promote coherency and consistency within a paper. A system promoting meaningful collaboration can support the creation of large highly integrated documents and allow the authors or managers full freedom to control where, when, and where and when not to structure and compartmentalize.
In addition to producing documents, many collaborative writing systems, especially those based on the web, contain integrated distribution mechanisms; most collaborative web-based writing tools provide a method of automatic web publishing. It is especially important in these cases to consider the nature of the product that readers will encounter and the relationship between how the document is read during production and how it is read after publication. What effect will these differences have? Can readers become collaborators? If so, what process does this change entail? Do new collaborators need to learn a complex interface or mark-up language? The use of annotation or comments is an important feature in the production of collaborative documents. Is it something a documents readers can do as well?
In answering the questions above, certain products will emerge as more useful, flexible, and suitable than others. Certain processes will seem more readily applicable than others. Carefully considering this evaluation cannot be underestimated. While the rest of this essay considers the structures of control exhibited between collaborators, the analysis of product asks us to consider the nature of the relationship between the reader and the text and, by extension, the relationship between the reader and the authors. Since the common goal of all writing processes, collaborative or not, is to be read, this process cannot be underestimated.
A particular subset of collaborative literary tools replace the term "collaborative" with "participatory" and describe collaboration as a democratic process or a method of more equitable decision-making. The designers of these tools are responding to the political implications of, and distinguishing their own work from, hierarchical systems for the collaborative production of literature.
Many collaborative writing systems, like most word processors described in the Section called Modern Word Processors: Microsoft Word and OpenOffice.org, for example, have no explicit system for controlling access—if you have the ".doc," you control it totally (this is discussed in more detail inthe Section called Modern Word Processors: Microsoft Word and OpenOffice.org). Deciding whether changes are integrated into a "master copy" is a bureaucratic decision, and not one that the software explicitly helps. For systems that are simultaneously authoring and publishing systems, access control is an essential consideration from the beginning.
Some tools (like Wiki described in the Section called The WikiWikiWeb) radically "open" the publishing system by eliminating any reader-writer hierarchy. Everyone involved has equal access to, and control over, all documents. This type of access is particularly interesting because through its instantaneous integration into the copy read by everyone, it has no historical antecedent; it turns mass-publishing tools into mass-authoring tools. It is through the creation of these types of tools that the technological context of collaborative writing is shifting radically.
Wikis, however, are unusual (although also unusually successful) in their radical approach to peer-based writing. Most web-based CSCW tools restrict the ability to make changes to authenticated (i.e., logged in) users. The most simple model splits users into those who can read, and those who have the additional power to write. For web publishing systems, this is often cast as the administrator/user hierarchy. There are those that control the content and those that consume it. More complex systems introduce more complex hierarchies that create access and power differences between groups of users (i.e., administrators, authors, editors, technical facilitators).
Replacing or eliminating traditional hierarchies is one of the most intriguing possibilities of CSCW. Ann Hill Duin and her own group of collaborators found that the use of software to facilitate collaborative writing in the classroom created a more productive context for collaboration between students and instructors by encouraging new and less hierarchical patterns of sharing information and by altering social norms that had previously controlled the exchange of written copy ([Duin1991] 158).
Hill shows the way that open access results in growth and change in ways that are dramatically different, and often dramatically better than those foreseen by a document's original architect. Open access on the Internet allows for a wide diversity of cultural, intellectual, and ideological viewpoints to shape a text. This type of unmediated and uncontrolled access, and the resulting lack of explicit hierarchies in similarly "anarchic" systems, is popular in part because it is easy to implement technically. Reproducing technical control systems analogous to the complex hierarchies used in the traditional publishing industry is in many cases prohibitively difficult. See the Section called Decision Making Roles on the use of roles in division of labor for a more in depth discussion.
While this philosophy of open peer-based access is unsurprisingly popular in Internet and the free and open source software communities, it also seems to be credible in the world of corporate and industrial collaboration. Research into peer and hierarchical editing by Henrietta Nickles Shirk has compared and contrasted attitudes toward and effects of editing by peers and by those operating within explicit hierarchies. Her conclusions are largely in support of peer editing. Eighty-nine percent of authors found peer-editing less threatening and ninety-four percent seriously considered peer editors' input for the final product. A large majority found it useful ([Shirk1991]).
Shirk describes the way that all editing is difficult because it involves a certain amount of psychological stress associated with critique of one's own ideas or expressions. Shirk sees editing, as an act of collaboration, as difficult because it involves a loss of control and "ownership" ([Shirk1991] 252). Peer-based editing, even if the difference is merely one of labels, allows this loss of control to be less threatening and the final product to improve—few will argue that great literature is written under stress and duress. However, peer editing can also act as a form of collaboration that emphasizes shared ownership of a document which deemphasize this stress by reconfiguring it as input of additional collaborators.
However, the power of hierarchical systems should not be completely dismissed. While a vast majority of students in Shirk's study felt they benefited from peer editing, authors tended to feel that professional editors' advice was more useful and beneficial to their work than they did peer-editors'. These hierarchical editors were perceived to have more credibility than their peers during the editorial process ([Shirk1991] 245, 249-50). These feelings framed and were reflected in the incorporation of peer advice into the final products.
While academic investigations of psychological stress in response to editorial decisions can be enlightening and useful, they will not decrease either the usefulness or use of either peer or hierarchical editing. Any well edited document will have been edited by peers and any document that can afford to will employ a more traditionally qualified editor. In all cases though, the best editorial work can only occur when an author or editor feels a degree of control over the document and is empowered to make changes—even if many of these changes are subsequently rejected. An open and flexible system can be employed both to challenge or harness external hierarchies when necessary toward the production of quality texts.
Systems that create hierarchies of users and writers often do so by defining roles for participants. In the most simple model of access control already discussed, participants are divided into readers and writers. The labels reader, author, editor, administrator, facilitator, and technical administrator each implies certain positions of power, certain types and degrees of control, and certain possessive capabilities. In implementation, each system has the opportunity to define these roles. Each system defines them differently.
Many pieces of software attempt to create roles based on analogues in the traditional publishing industry. A system dividing users into editors, readers, and authors is an example of how this is often done. While using the metaphor of an editor is convenient and familiar to a large number of potential users, software engineers find it exceedingly difficult to define these roles in technical terms. How should software differentiate between authors and editorstechnically? On one level it seems obvious that authors should be empowered to make larger and more meaningful changes, while editors' power must be more limited. But what does this mean in technical terms? Should the author be forced to review each editorial change? Should the system attempt to define"limited changes" in technical terms (e.g., percentage of words changed)? Either of these solutions will be complex and ugly and better alternatives are not forthcoming.
More problematically, while successful in the traditional publishing industry, the model of the editor on which software bases its technical analogues is not useful in the context of most real-world collaborative writing. James R. Weber is a scientific researcher who has analyzed the collaborative production of documents within one large scientific laboratory. While he felt that leadership roles were useful and important in collaborative writing, he saw these roles falling into two major groups:
lead authors who served as "project managers" routinely made changes in the other authors' contributions and who were responsible to meet contractual deadlines and negotiate directly with the sponsor of the project; and
document coordinators who rarely made editorial changes but merely oversaw the work of other authors and collected and integrated pieces into a single document ([Weber1991] 55).
Weber points out that the desire for a strong lead author by collaborators (as in the first example) can be read as part of the desire for an single overarching view of the work and thus perspective on one's own contribution to the whole; however, he noticed problems emerge quickly. By appointing or empowering one person as a lead author, certain feelings of ownership and propriety are implied. As a result, secondary authors feel less motivated to contribute meaningfully and extensively. Only by distributing control evenly can a system maximize collaboration.
The role of a document coordinator attempts to balance the need for coordination and an overarching view of the document with the desire to invest authors with a greater degree of control over their own work in the larger document and the shape of the text as a whole. It implies editorial control in a less threatening manner. By distributing control while retaining centralized coordination roles, it provides one useful model that can support a more meaningful and effective form of hierarchical production in CSCW.
Other noteworthy roles include any number of different kinds of administrators with different types and levels of access to documents. Some administrators have special textual responsibilities that include integration or maintenance. While the discussion in the preceding paragraphs emphasizes leadership roles, division of labor in CSCW in a non-hierarchical manner is both possible and useful. Toward this end, software designers can mediate the power imbalance introduced by administrators by defining and limiting administration to technological assistance and maintenance.
Regardless of the type of role under consideration, it is essential to consider the type of control conferred by each role and the manner in which this control will affect collaboration. Hierarchical or not, explicit division of labor within a collaborative production will play a dramatic role in the evolution and interactions of collaborative writing groups. While the creation of leadership roles can foster feelings of ownership and responsibility that can hinder or slow meaningful collaboration, its power as a motivating factor should not be deemphasized either. The analyst's job includes balancing the power of both control and responsibility with the desire for meaningful collaboration. As this balance will change with every group and with time in any group, the importance of flexibility in in defining and redefining these roles cannot be underestimated.
All communication, and collaboration as a result, is either synchronous or asynchronous. Synchronous communication requires that both parties work on the same clock. The telephone is an example of a synchronous communication medium. Asynchronous communication allows users to work on different and uncoordinated schedules. Examples include letters and email. Synchronous communication is convenient but requires additional scheduling. Like communication, synchronous collaboration balances convenience with coordination. If three individuals collaborate on a single document synchronously, only one can write or edit the document at any given point.
Synchronous collaboration is often facilitated through systems of "locking" or "checking out" pieces of text and marking them as off-limits to other collaborators. Anyone who has collaborated using email and a word processor (a process described in detail in the Section called Modern Word Processors: Microsoft Word and OpenOffice.org) is familiar with an ad-hoc version of this type of system. Fast and meaningful communication is essential as every author must know the sum of applied changes to a piece of a document before they can alter it. While often inconvenient and burdensome, this increased level of communication is always beneficial to a project in the ways mentioned in the Section called Intra-Project Communication.
Conversely, asynchronous collaborative writing systems allow each user to work without these limitations. At any given point, authors need not know what their collaborators are working on—even when they are working on the same piece of text. Consequently, an asynchronous collaborative writing system is one in which authors will inevitably create conflicts in the texts they produce; they might both rewrite a sentence in a different way. These systems must be technically equipped to monitor for conflicts and then provide methods for these conflicts to be analyzed, addressed, discussed, and resolved.
From a technical perspective, synchronous systems are easier to implement. When there is no technical ability to create conflicts, there is no need for a technical method to detect and resolve conflicting changes. As a result, most CSCW systems operate synchronously.
However, this ease of implementation can impose severe limitations on many projects. Within synchronous CSCW systems, there is a fixed ceiling on the number of hours of work any group can put into a document within a given period; a single document, or compartmentalized piece of a text, can only be worked on by one person at any given time. While in small groups, this restriction is unproblematic, it presents a critical limitations as the size of the group increases. This type of compartmentalization, as the only possible recourse in such situations, renders collaboration less meaningful.
By supporting collaboration in both small and large groups, software operating asynchronously is automatically more flexible and more meaningful than software operating synchronously. By opening up collaboration to larger groups and by allowing each person full reign over an entire document at all times, CSCW technology working asynchronously gives each person constant and total control over the complete document. As a result, asynchronous collaboration, while more technically difficult, is almost always preferable. Any system coupling synchronous or near-synchronous communication—as is simple on the Internet—with asynchronous collaborative writing technology can support collaboration in a synchronous manner.
A CSCW system supporting meaningful collaboration must allow collaborators to change or suggest changes to text that they did not write. Unless authors are willing to reread an entire document after each set of changes, blindly and completely trust the judgment and vision of their collaborators, or communicate the totality of their changes through a medium outside the CSCW software, any effective technical system for collaborative work needs a method for isolating and representing changes made to documents. Additionally, representing these changes is essential to the process of describing and resolving conflicts created by asynchronous textual collaboration. As a result, the ability to represent changes is essential to any CSCW system.
The three basic changes possible are addition, subtraction, or alteration and an effective system must be able to represent each. Changes to mark-up (e.g., a change in font, a new line, the addition of emphasis), which convey a large amount of meaning, is also important to represent. Many word processors can include the ability to compare two documents and represent these differences through colored text or strikeouts. Other programs like GNU diff and wdiff can examine two versions of a document and produce a third document that unambiguously represents the differences in several human and computer readable formats.
By allowing collaborators who are familiar with a document to quickly bring themselves up to date with the latest version of a document by perusing the changes made to it, version control facilitates efficient and meaningful non-hierarchical collaboration and peer-editing to develop. By simply tracking the changes made, a larger number of people can be familiar with the current status of a document and can share the position of lead author or document coordinator. In this way, the representation of changes can facilitate decentralized control and less hierarchical systems of collaboration.
Collaborative software development processes, which David Farkas compares to collaborative writing processes, are heavily based on systems that track and record all changes made to a given piece of text (in software's case, it is source code) through the use of "version control systems" like BitKeeper, CVS, RCS, and subversion. These version control systems store all changes made to a document in computer parsable and software reversible format. At any given point, anyone with access is able to have the software quickly back-track to any desired version of the document or request a list of the changes between any two version of the document based on the day, version number, or "tag" placed on a particular version.
By storing all changes, version control systems make collaborators feel more empowered to make major changes to pieces of source code, and it stands to reason that these systems could be broadly applied to the production of literature as well. With the knowledge that a document can instantaneously be reverted to any older state, authors feel more willing to take or share control of a document and are less hesitant to make changes. By lessening the long-term consequences of major changes, authors are willing to take control of the document. As nothing is lost; every change is merely a suggestion.
While not always common in CSCW software, the power of this ability to efficiently track changes, and to do so in a way that also facilitates asynchronous collaboration, is increasingly recognized and increasingly common. Both the ability the represent changes and the ability to track and record these changes over time set the stage for meaningful collaboration in ways that are important and often essential for effective collaborative work.
Communication is clearly essential to any successful collaboration. The act of working together is a form of interaction and involves transitions and retransmission of ideas between collaborators. Philosophers have gone so far as to define communication itself as the collaborative construction of ideas [Weiss1991]. Empirical studies have backed up this connection by demonstrating that when the social sphere for communication is well defined within a collaborative project, interaction on content is more meaningful and the collaboration more efficient and effective ([Weber1991] 59).
As a result, it's unsurprising that the computer initially emerged as a tool for collaboration through its role as a tool for communication. In fact, early researchers defined computers as useful in collaborative writing simply because they make communication process faster and easier ([Duin1991] [Weber1991]). William Van Pelt's article on the computer in collaborative writing highlights computers' usefulness as a community device as the single most important use for the computer in collaborative writing ([Pelt1991]).
Anne Hill Duin monitored computer communication during collaborative writing. Her group counted more than two messages or documents created per person per day. These messages discussed writing strategy, issues of audience, verification of ideas or sections, discussions of content, questions about the technology and off-task conversation. The majority (sixty-two percent) centered around issues of verification ([Duin1991] 159-60). The study demonstrated that effective collaboration requires both the transmission of the text being authored and the facilitation of extra-textual conversation. These discussions, while not part of the finished document, provide the bulk of written work and lead to an informed group capable of sharing control of the document and engaging in meaningful collaboration.
Communication systems in CSCW systems can be either integrated or separate. Word processors assume discrete communication systems like networked file systems, email, and telephone or teleconferencing technology for transmission of documents and communication. Other systems provide integrated or semi-integrated forms of synchronous communication like chat-channels, video-conferencing and instant messaging. Asynchronous systems like email linked with the ability to make supra-textual annotations.
This ability to communicate in ways that are linked or integrated into the text is immeasurably useful. The nature or degree of integration of the text with extra-textual discussion will vary in nature and effectiveness between CSCW systems, though the functionality is commonly cast as ability to insert"comments" into a document or to attach log messages summarizing the changes as an author checks in a new version. Discrete systems of communication, be they coordinated real-world meetings, instant messaging, or email communication, augment rather than replace integrated systems but are easier to implement and are more widespread.
Strong systems of communication are important in a technology's ability to distribute control over a document for the same reasons that the ability to track changes are essential—both types of functionality create a larger more informed group of collaborators and let authors interact with the text and each other more meaningfully. Through extensive public or group-wide communication, collaborators are able to contribute whenever they feel their input will be useful or appreciated. Both integrated and discrete communication in regards to the text are essential in promoting collaboration. Just as each system facilitates communication or links discussion to the text in particular ways, the interaction of the writing system with communication defines the terms of control and collaboration in an equally individual manner.
CSCW is successful in part because it is a computer mediated phenomenon. Anne Duin Hill's research has found that writing group members who used electronic messages are less inhibited than in face-to-face groups, and that such groups had a reduced chance of one person dominating the conversation ([Duin1991] 161). However, these benefits come at the price of a great deal of non-verbal communication that is important to many involved in collaborative writing. Communicating large amount of extra-textual data can be slow and frustrating, especially using asynchronous communication systems. As a result, the use of CSCW technology proves difficult for many writers.
As a result, James R. Weber and others recommend augmenting CSCW technology with at least one face-to-face meeting if possible, even when the groups are geographically separate ([Weber1991] 62). Weber notes that these meetings can be invaluable in setting deadlines, formats, rhetorical considerations, and beginning discussion on a project. Additional meetings, in most cases, are also beneficial.
Recognizing the potential power of face-to-face meetings, several pieces of software provide methods for integration of these meetings into the collaborative software in a number of ways. A simple mechanism might allow for notes, transcripts, or a recording of the meeting to be archived or made available through the software. Other more complex and creative mechanism vary in their design and implementation. While none of the software reviewed in the case studies below incorporates this sort of functionality, when present, it can shift power and control dynamics within group and prove immeasurable helpful to many collaborators. As a result, it may be an important consideration in choosing or evaluating a collaborative writing system.
Flexibility has been alluded to in many of the sections above. It is so important, however, that it warrants revisiting. Flexibility speaks to the fact that just as every collaboration is different, no CSCW software will be perfect for everyone or for every collaborative endeavor. As a result, the final and perhaps most important area of analysis for any collaborative system is its flexibility—its ability to become what it is not.
Anne Hill Duin breaks the logical structure of collaborative document production into planning, drafting, revising and packaging and then considers each area separately ([Duin1991] 148). Her analysis points to the fact that the production of a single document may be best served by different types of technological facilitation at different points in a document's development and growth. A person in a leadership role at one point may feel the need to change roles or involvement as the project evolves. A flexible system is one that easily change and adapt to fit such dynamic needs.
In her own analysis of writing groups within NASA, Elizabeth Malone found that the tension between a group's normative consensus and the changing demands of the problem-solving process meant that certain individual behaviors and the larger groups' normative consensus were productive and counterproductive in different phases of the project ([Malone1991] 110). As the importance and effect of particular individual behaviors and group consensus changed over the duration of projects, so should their treatment and facilitation by CSCW software. A call for flexibility argues that the answer is not to divide the collaborative process into discrete sections and provide specialized technical solutions for each period, but rather to create a system that is dynamic enough to cater to each effectively and to change when it fails to do so.
When an analyst considers the social and political implications of hierarchies created by a particular writing system, he or she should also consider the degree to which the system, and the particular control structures and roles created by it, can be adapted or modified to fit the dynamic needs of a project. Can a collaborator change roles? How flexible are the definitions of roles themselves? Through the codification of a system of control, this essay has established that CSCW software determines the terms on which collaboration occurs. Emphasizing flexibility ensures that we ave a hand in helping define and redefine those terms and our needs and goals inevitably change.
Recognizing this flexibility is often not difficult. This sort of flexibility can commonly be found in administrative interfaces or technical configuration options. Free and open source software provides another meaningful type of flexibility through assuring the technical and legal ability to make changes to the software and distribute their these modifications. By choosing free software, one rests assured that they will have the ability to collaborate on their own terms and to change or modify the system to reflect their own needs.
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. 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. 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.
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).
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.
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.
Wiki 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]).
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:
In each of these ways, Wiki attempts to facilitate collaboration by making the system as simple, accessible, and flexible as possible.
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).
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. 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.
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.
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.
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.
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. 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.
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 ofall 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 factonature 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 WikiWikiWebhas 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.
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. 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.
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.
Each of the systems evaluated above prove very useful in facilitating certain forms of collaboration and each produces a very different type of document. Their divergent nature seems to imply that an ideal system is impossible. However, they also provide insight into the type of functionality that frames more flexible and meaningful collaboration. Through use or omission, they demonstrate the effectiveness of systems that can produce a single document, work asynchronously, allow for dynamic and flexible role through non-technically enforced hierarchies, provide strong systems of version control, facilitate both intra and extra-textual communication and demonstrate the ability to tie in work in face-to-face meetings. Through analysis along these lines, analysts can take meaningful steps toward the facilitation of meaningful collaboration in their own projects and on their own terms.
There has been error in communication with booki server. Not sure right now where is the problem.
You should refresh this page.