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.

The Product

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.

Access Control: Hierarchical vs Peer

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, for example, have no explicit system for controlling access—if you have the ".doc," you control it totally (this is discussed in more detail in the Section called Modern Word Processors: Microsoft Word and 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.

Decision Making Roles

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 editors technically? 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:

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.

Synchronous and Asynchronous Collaboration

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 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.

Tracking Changes and Version Control

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.

Intra-Project Communication

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.

Face-to-Face Meetings

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.