| 
View
 

Collaborative Authoring

Page history last edited by Nancy Neff 4 years, 1 month ago

I.  INTRODUCTION

 

Given the globalization of business and the rise of the Internet, the need has been steadily growing for virtual collaboration and tools to facilitate the process.  Rarely are essential company documents and deliverables authored by one individual. Rather, they are authored by various employees and consultants from locations across the country or globe. Collaborative authoring is the process by which multiple users employ virtual tools to create a written document, or deliverable. 

 

In this section, we will examine collaborative authoring from several angles.  We will look at key developments in collaborative authoring and general workflow structure.  We will review the four main types of collaborative authoring -- single author environment, single author sequential, parallel work and reactive writing -- and the conditions under which each might be used.  We will discuss human factors, their impact on the collaborative authoring process and how to mitigate the attendant risk.  Finally, we will examine a range of collaborative authoring tools, their strengths and limitations, and how they line up with different collaborative authoring scenarios.

    

II.  AN OVERVIEW OF COLLABORATIVE AUTHORING

  

Background 

 

Collaborative authoring didn’t begin with the Internet or even with the PC, but it certainly has improved with online technologies.  Authors worked collaboratively before the advent of the Internet but the process was much slower and more inefficient.  Work was more iterative and less collaborative.  Authors in dispersed locations exchanged printed documents and hand-written revisions by mail or fax.  When desktop computing became widespread, authors could swap floppy disks with files in progress. 

 

In the early days of the Internet, authors shared documents via email or FTP (file transfer protocol).  In each of these stages, there were limitations on the authors’ flexibility and productivity.  These early methods of collaborative authoring created significant delays in sharing and incorporating information in a timely and efficient way.  Authors could only work sequentially, and they had to wait until one person’s work was done before either starting theirs or correcting, modifying or building on the work of others.  There was significant downtime where no work occurred, as the document transfer took place.  There were version control issues, as changes had to be accurately recorded or reflected for others to review.  Even when web publishing became available, team projects were authored and published online in read-only format.  Once the document was published, it became frozen in time and space; no further collaborative was possible unless the whole process began anew.

 

That changed with the advent of the a  new Internet protocol called WebDAV, or Web-based Distributed Authoring and Versioning protocol.  WebDAV is a set of extensions to HTTP (Hypertext Transfer Protocol) that allow computer-users to edit and manage files on remote servers.  WebDAV gave multiple members in different geographic locations the ability to edit a published document directly on the HTTP server.  Thus, the web moved beyond being a read-only interface that facilitated information delivery and exchange to serving as a writeable collaborative medium.  “HTTP gave [users] read access, while DAV gives them write access,” according to George Stein and Jim Whitehead, who founded the developers community WebDAV Resources.


In 1995, War Cunningham invented a group communication mechanism called a wiki, which allowed users to create and edit web documents using a web browser.  In a wiki environment, all users are potential authors or editors.  Some wikis require registration, some don’t.  In either case, users can make changes simply by clicking an “edit” link and submitting their changes, which are converted to HTML by the wiki system.  One key feature of a wiki is that it keeps a list of all changes and who made them so that it is easy to revert to an old version if necessary  (“Collaborative Authoring on the Web: A Genre Analysis of Online Encyclopedias,” 2005).

 

The software behind wikis is often used to create collaborative wiki websites, to power community websites, for personal note-taking, in corporate Intranets, and in knowledge management systems. All of these uses incorporate some form of collaborative authoring

 

Benefits and Challenges

  

Authoring a document on one’s own can necessitate a highly complex thought and work process.  With multiple authors, the complexity increases exponentially. Collaborative authoring can bring numerous benefits, such as diversity of viewpoints and knowledge sharing; increased creativity; efficient use of a team’s time, skills and expertise; dispersed risk; and potential cost savings.

 

However, collaboration can also bring its share of challenges, as anyone who has ever worked on creating a group document can attest. These include, but are not limited to: 

  • Lack of communication
  • Time spent in review and feedback
  • Difficulty in arriving at common goals and shared understanding
  • Uneven quality of output 
  • Variety of styles within one document
  • Lack of engagement or conflict among co-authors
  • Technical issues with tools and training

 

While there may be issues with picking the right technology or getting up to speed on a tool, the primary challenge seems to be social and organizational factors. "The majority of problems aren’t due to the tool, they are due to people, cultural, and organizational issues that need to be dealt with first," according to industry analyst Craig Roth. 

 

Specific pros and cons will be addressed for each type of collaborative authoring later in this section.

 

Workflow Overview

  

Collaborative authoring is not simply the process of authoring a document from start to finish; it’s a holistic approach to completing a document.   Collaborative authoring can be broken down into three phases: pre-collaborative authoring, collaborative authoring, and post-collaborative authoring.  Each stage of the process is essential to the success of the project.  Tasks carried out during each phase are outlined in Figure 1 (below). Notice the numerous activities that occur before the documentation production stage even starts.

 

 Source:  PM 440 Lecture Notes

 

The first phase (pre-collaborative authoring) focuses on planning: review of tasks, assembling documentation, identifying team components, selecting tools, etc.

The second phase (collaborative authoring) contains the majority of teamwork and content creation: team formation and bonding, setting goals and objectives, creating work plans and milestones, brainstorming, outlining, writing, editing and review and approval.

 

The final phase (post-collaborative authoring) revolves around project archiving: finalizing documentation, reviewing lessons learned, and planning any remaining steps. 

These phases are present during all types of collaborative authoring, but they may be ordered somewhat differently, depending on the type.

 

III.  FOUR TYPES OF COLLABORATIVE AUTHORING

  

Collaborative authoring can be broken into four essential types, which we will describe in detail in this section:

  1. Single author environment
  2. Single author sequential
  3. Parallel Work    
  4. Reactive Writing

 

The type of collaborative authoring required depends upon the nature and goals of the project.  Each type has advantages and disadvantages, and care should be given by team members in selecting the type best suited to a project.

 

Single Author Environment

 
In this setting, a group of collaborators discusses and makes decisions on all aspects of a document or project, and one person authors the entire document. The content discussions may take place in person or via a virtual medium, but the final deliverable is written by just one individual, who incorporates all the feedback, structure, suggestions and ideas of the group.  This is considered collaborative authoring since multiple authors are influencing decisions.

 

The pros and cons of single author writing include:

 

Pros

Cons

Unified voice and style

Fast

Allows for group input 

Overly reliant on one person's perspective

Unbalanced workload 

 

An example of single author writing is a corporate annual report.   Information and input is gathered from sources and departments across a company, and one author synthesizes this into a cohesive single report, often revising after additional feedback.

 

Single Author Sequential

 
In this collaborative authoring scheme, each author works on a different part of a document in sequential stages.  For example, author No. 1 completes one-quarter of the document, then passes it to author No. 2, who completes the second quarter of the document and passes it to the third collaborator, and so on (see Figure 2, below). However, one disadvantage with this authoring structure is that not all authors may share the same objectives for the project, and consensus as to the overall goal may be difficult to achieve.  In addition, the voice and tone of each section will vary by author, which can be confusing or off-putting to the reader. 

    Source:  PM 440 Lecture Notes

 

The pros and cons of sequential writing include:

 

Pros

Cons

Easy to use common tools

Easy to understand

Little wasted effort

Slow, lots of wasted time

Only one person active at a time

Some people miss out on final edit

Procrastinator can halt project

 

(Source: PM-440 Lecture Notes)

 

Examples of sequential writing include works of fiction by multiple authors, such as Naked Came the Manatee, a 1997 crime novel written by 13 Florida writers, including Carl Hiaasen, Elmore Leonard and Dave Barry.  Each chapter was created by one author, and then the work passed to the next author, who added to the story as he or she wished.  "Amazingly, the writing is mostly as neutral in tone as it is seamless," said Kirkus Reviews. 

 

Parallel Work

 
In this collaborative authoring scheme, work can be divided into sections or competencies, and authors work concurrently on their sections or activities.  There are two types of parallel work: horizontal-division writing and stratified-division writing (“Building a Taxonomy and Nomenclature of Collaborative Writing,” Lowry, Curtis and Lowry, Brigham Young University, 2004).  In horizontal-division writing, authors are assigned subject areas and work concurrently on their sections (see Figure 3, below).  This approach works well if an author has an expertise or passion for their assigned subject area, but less well if an author is unfamiliar with or lacks enthusiasm for his or her subject area.   In the second type, stratified-division writing, work is divided by tasks, or competencies.  For example, one author is responsible for research, one for authoring, one for formatting, one for team coordination, etc.  As with the first tupe, this structure requires good communication and works best when authors are assigned tasks with which they have experience or an affinity. 

 

 

Source:  PM 440 Lecture Notes


The pros and cons of parallel writing include:

 

Pros

Cons

Fast
Everyone is active

Often reads like multiple, separate documents
Much editing required to assemble
Overlap and omissions in text
Subject to whims of free riders 

(Source: PM-440 Lecture Notes)

 

A good example of parallel writing is the Book Sprint, the brainchild of developer Tomas Krag, who set out to create an authoritative source on wireless in the developing world by drawing on experts throughout the field.  The experts gathered in person at a 2005 industry conference in London, where they created an outline, scoped out details and content, and received assignments.  The authors all completed their chapters in one month, and the book, Wireless in the Developing World, was professionally published shortly thereafter in its first edition.  Krag called it a project to create "a book in a week."

 

Reactive Writing

 
In this writing structure. all authors work synchronously in real time on all sections of a project (Figure 4, below).  This structure allows for increased input by team members, as well as expanded give and take during the writing process – the writing process, in fact, could almost be considered a brainstorming session.  There are sensitivities to be considered when editing others’ work – one author may prefer a certain sentence structure or style, whereas another author might not.  The ability to edit – and re-edit – can result in hours spent on relatively minor issues and can impact trust among team members.  As with any collaborative effort, dealing with other human beings and their idiosyncrasies can be more challenging then the substance of the work itself.  Reactive writing is useful for small to medium groups that need a lot of creativity and discussion, such as in creative writing efforts and marketing documents (“Using the ThinkLet Framework to Improve Distributed Collaborative Writing,” Lowry and Nunamaker, Jr., 2002). 

Source:  PM 440 Lecture Notes

 

The pros and cons of reactive, or reciprocal, writing include:     

 

Pros

Cons

Single voice emerges
Fast
Little wasted effort
Supports many authors

Need to relearn how to write with others
Need to use tools other than word processing

(Source: PM-440 Lecture Notes)

 

The most well-known example of reactive writing is probably Wikipedia, which reflects the collective efforts of thousands of users, all working synchronously on the same content.  Any registered member of Wikipedia can create a page on the site (within site guidelines), and edit or re-edit other pages.  Content on Wikipedia is constantly changing and reflects the efforts and expertise of thousands.  There is a high level of give and take among authors, and mistakes are quick to be pointed out or corrected.  At the same time, the sheer numbers of people involved has led to arguments and debates over content of the pages -- the back and forth can reach an unproductive level and can result in the publishing of unreliable information.  Wikipedia is not viewed as an unqualified, reliable source, but the input of the crowd makes it a dynamic and widely used tool.

 

IV. UNDERSTANDING THE USER EXPERIENCE

  

Understanding the user experience in any project starts with looking at the problem we're trying to solve. In collaboration software, we want to address how people use software to collect, organize, synthesize and manage a collection of partially completed thoughts and ideas from a group of two or more people to achieve a specific document deliverable.  Software is built by people, and for people, to make people’s lives better. Software is merely an intermediary. It’s important to keep this mindset at all times when choosing, developing or using a co-authoring tool. We need to understand the real problems people face and what the priority may be in a given situation – both in and outside of a defined process.

 

For this section, user experience can be defined as how a person feels about using a system based on their perceptions and responses measured against their individual expectations of software.  User experience as a whole is both subjective and dynamic by nature. It is subjective because it’s tied to an individual’s perception and dynamic because it’s constantly changing based on an individual's exposure to more information.  In order to address the user experience of a coauthoring tool, it's ideal to consider other factors outside of the standard process itself.  Understanding user experience is beyond the process and the application.

 

Human Factors in Collaborative Authoring Software

 
In any co-authoring process, participants bring to the table a set of human factors. Human factors can be defined loosely as the sum of an individual’s perceptions at the time of a given activity. These include feelings, prior knowledge and experience and positions in regard to given factors both in and outside the process. Human factors can be seen as both an advantage and a disadvantage in the collaborative authoring process.  

Inside the process, a participant may have preconceived notions of what a successful co-authoring process looks like. There may be expectations that aren’t relevant or a bias against the process in general, all things that need to be considered. Outside the process, a participant may have feelings or motives in relation to an author, an idea or the process itself again. The software or the process may not be designed to address these factors directly, but they are real and need to be considered, and their risk needs to be mitigated.

 

Mitigating Risk with Human Factors

 
Since we can't remove human factors from the collaborative equation, we need to find ways to mitigate the risk associated with what people bring to the table. There are steps that can make the experience better for each participant. It's important to note that these are not best practices, but they are relatively reliable approaches people can take. Generally, mitigating risks starts with communications around a variety of areas, including:

 

  • Defining roles
    When starting any collaborative authoring exercise, it's important to make sure people understand their roles, even if those roles may remain unchanged during the entire exercise. Being assigned a role can be a time when a participant establishes a baseline of expectations for the role: my role includes this, but not that.  If expectations are not clearly defined for participants, they will work to their own standard and not the necessary standard of the group. In a collaborative authoring environment, one way of accomplishing this is to assign roles during the process when a user creates a profile. The assigning of roles within the system should be flexible, as they may change across an exercise.

  • Defining objectives
    One of the biggest challenges collaborative authors face is clarity on objectives. Since each person on a project has a different view of the deliverable and different motivations,  objectives need to be clearly defined up front. Once defined, that clarity should be checked and maintained at both the individual and group level throughout the course. The goals work on two levels: Individuals should be able to achieve a sustained sense of accomplishment throughout a project, while at the same time helping the group achieve its stated goals. Part of defining objectives for a group means breaking down the main objective into a series of achievable goals and rewarding small achievements. In collaborative systems, the mechanism for doing this is often a to-do list that's assigned to an individual with a date and time on each deliverable.

  • Setting rules and expectations
    Rules and expectations create boundaries for accepted behavior, whatever that may be. Rules and expectations vary by project and by role but should be in place at each level.

     
  • Accountability
    Accountability is the measure of how a participant performs against stated objectives and expectations. This needs to be defined up front in a co-authoring exercise and is closely tied to defining objectives, but it also impacts the quality of a deliverable. While quality is different in every project, the standard should clearly communicated.

 

The Collaboration Process


There are established patterns in the co-authoring process that can easily be identified and understood: ideation, researching, verification, documenting, drafting, editing, approving, versioning and, finally, publishing.  For each of these parts in the process, a set of controls can be put in place for each of these parts, allowing it to be governed in a linear fashion so that it can easily be understood and managed by people as well as automated by software. Simply understanding and documenting the process and patterns is easy, but finding the right controls to put in place to make sure the process works is where the magic happens.

 

 

Controls

 

Controls exist in the collaborative authoring process both in and outside of the tools used to help aid the process. Controls can be as simple as documented guidelines that outline expectations or as complex as tool that collects and documents time spent on a given exercise. Controls exist at all levels of co-authoring starting from the top and working their way down and can be broken down into two categories:

 

  • Primary controls govern the entire process as a whole and consist of project management, document management, people management, workflow management, etc.

  • Secondary controls exist at the individual process level and are put in place to govern individual components. If we look at one of the standard patterns such as research, we can append a mix of secondary controls based on the needs of the exercise itself. Examples of controls on research are standard annotations, sources, timeframes and vetting. 

 

In collaborative authoring, the primary controls fall generally into four types. First, there is document management. Document management can be as simple as a repository that is managed by an individual or as complex as an interactive tool that allows people to edit and save a given document in a certain state. Google Docs is a good example of a simple repository. A wiki is a more complex tool.

 

Second, there is a level of project management associated with any project. At the most basic level, this includes documented start and end dates and project milestones. Project management can be as simple as follow-up e-mails to individuals or as complex as a complete to-do and milestone list.

 

Third, there is a level of people management. Communication has to occur throughout a project. Controls in place can be scheduled meetings, emails, phone calls or one-on-one discussions. People management addresses the risks that come with human factors.

 

Finally, there is workflow management, which, unlike project management, addresses the approval points in a project. At what point is the document complete and at what point does it need to be moved? These are questions addressed in workflow management.

 

Sample Control Matrix

 

In a user experience exercise, it's important to understand what controls are either in place or can be put in place to impact behavior. Below is a sample matrix that identifies a mix of activities associated with co-authoring and associated controls. This is meant to illustrate the difference between primary and secondary controls:

 

Activity Control Type
Ideation Scheduled Meetings Secondary
Ideation Standard Questions Secondary
Ideation Schedule Primary
Research Restricted Materials Secondary
Research Standard Annotations Secondary
Research Vetting Secondary
Document Standard Templates Secondary
Document Standard Tools Secondary
Draft Editing Rules Secondary
Verification Findings Review Secondary
Editing Review Periods Primary
Editing Assigned Areas Secondary
Editing Grammar Review Secondary
Versioning Version Control Secondary
Versioning Workflow Primary
Approvals  Review Periods Primary
Publishing Document Restrictions Secondary

  

Having an optimal user experience in any activity will lead to a better deliverable. A better deliverable in business is one that is on time and on budget. Often, if the underlying business idea is sound, this leads to increased revenue. The easier it is for people to understand and accomplish a task, the more likely a project is to succeed.

 

Additional Resources

 

Numerous books have been written on improving the user experience.  Now that we understand what to look for in co-authoring applications -- mainly what's driving the experience -- we now need to look at ways to improve key areas. Properly addressing some of the areas outlined above involves a variety of disciplines, including cognitive science, design and computer science. Discovery of the user experience covers established areas such as research, personas, use case development, prototyping and testing.  Those interested in delving further into user experience can start with these standard sources:


Jacob Nielson

http://www.useit.com/papers/heuristic/heuristic_list.html

 

The Humane Interface

http://en.wikipedia.org/wiki/The_Humane_Interface

 


V.  TOOLS FOR COLLABORATIVE AUTHORING

 

As previously mentioned, collaborative authors in the early days of the Internet shared documents by email or FTP.  Authors took turns making changes and waited their turn in between.  The team's final product was usually published online at a specific location, usually where it had originally been uploaded to the web. This was an inefficient system that led to delays and difficulty in sharing of timely information.

 

Collaborative authoring software has evolved over time, and many applications now include functions to support project management, ideation, authoring, editing, commenting and change tracking.  With all of the functions now available, it can be a daunting task to choose one tool that meets the requirements for a specific collaborative authoring project. This section will look at several tools and how their features line up with detailed design requirements.

 

For the purposes of our discussion, collaborative authoring tools can be defined as primarily web-based authoring applications that allow instantaneous and real time virtual collaboration on a project by multiple members in a group.  The goal of this section is not to provide an exhaustive list of products but rather to give a way to compare and evaluate collaborative authoring tools.


Below is a list of collaborative authoring software design requirements from “The User-centered Iterative Design Of Collaborative Writing Software,” Baecker et. al, 1993.  The researchers studied how people write together and developed a set of design requirements to match those needs.  Their research examined seven different collaborative authoring tools and and determined at what level these tools supported the requirements.  The rankings were: 1) system provides good support; 2) system can handle; and 3) system goes not support a particular function (see key, below). 

 

 

 

 

Requirements Concepts Defined

 

In order for the requirements to be useful for evaluation and comparison, terms must first be defined so there can be a shared understanding of meaning.  The following are requirement terms as defined in the Baecker et. al. paper (Baecker, Nastos, Posner, & Mawby, 1993). 
  

Requirements for Individual Writing

 

The general requirements for an individual writing system are a basic word-processing program and seamlessness with other work media.

 

Requirements for Collaborative Writing

 

The following features are requirements for a collaborative writing system:

 

●      Preservation of identities
Collaborative writing incorporates contributions from several individuals. A collaborative writing system should record and display the identities of the contributors. 

 

●      Enhanced communication
Essential to collaboration is communication among individuals working together. They may communicate about the object of their collaboration (substantive communication), exchange questions, revisions, and acceptances (annotative communication), or discuss courses of action and process plans to achieve their goal (procedural communication). 

 

●      Enhanced collaborator awareness
Collaborator awareness can be defined as the knowledge of the state or actions of one’s collaborators. Two dimensions that characterize levels of awareness are the degree of engagement and the amount of planning. Depending on how focused and planned shared work is, collaboration may vary from focused collaboration (where people work together closely) to general awareness (where people know roughly what others are doing). A preferred term is peripheral awareness. 

 

●      Annotations
Contributors such as reviewers of a document often record their suggestions as annotations. Ideally, a system should support several kinds of annotations — text, voice, or hand-drawn markings. 

 

●      Undo
Interactive systems such as writing and drawing tools must provide the ability to undo changes made by a user. Undoing, however, can become difficult when changes are interleaved (or arranged in layers) and originate from multiple sources. 

 

●      Session control
A collaborative writing system should allow users to create, join or leave editing sessions at arbitrary times.  It must also ensure that all users access the same version of a shared document. 

 

Requirements for Roles

 

●      Explicit roles
A shared writing environment should support the different roles individuals may play in document creation. 

 

Requirements for Activities

 

●      Variety of activities
A document is created through a number of activities, including brainstorming, planning (both outline and process plans), writing, editing and reviewing. Each activity requires different support and functionality from a writing system. A shared writing system should be flexible enough to allow different writers to perform different activities at the same time. 

 

●      Transitions between activities
A writing system should allow seamless transitions between activities, since they do not always occur in a sequential manner. 

 

Requirements for Document Control Methods

 

●      Several document access methods
It may be appropriate to have different types of accessing documents, such as read-only, write and comment. 

 

●      Separate document segments
Individuals working collaboratively often subdivide a document and work on pieces independently. Systems should provide support for multiple document segments as well as maintaining connections and accessing the entire document. 

 

●      Version control
Knowing who wrote or changed a specific part, what changes were made, and when they were made is essential. 

 

Requirements for Writing Strategies

 

●      Single or multiple writers
Although designed for multiple writers, a shared writing system should also support a single writer so that one need not use a different system for this activity. 

 

●      Synchronous and asynchronous writing
Participants on a project may want to access the document concurrently or sequentially. Support for synchronous writing is essential especially during the stages of brainstorming and outlining. Support for asynchronous work is particularly important in the stages of writing, editing and reviewing.  

 

Now that we have defined some common terms, we can use them to compare and evaluate more recent collaborative authoring tools.  We will briefly discuss several collaborative authoring tools before applying the requirements in the much same way that Baecker et al did.

 

Examples of collaborative authoring software

  

Google Docs is free, web-based word processor, spreadsheet, presentation, form and data storage service that allow users to create and edit documents online while collaborating in real-time with other users. It can be access online at http://docs.google.com. Google Docs allows users to upload existing files or create basic documents from scratch or from a template, utilizing text editing attributes. Its collaborative authoring interface allows users to share documents by sending invitations via emails to multiple team members; members can view and make changes to the same documents.  In addition, there is an on-screen chat window and a document revisions feature that tracks changes by a log of authors and changes made to the document. Documents uploaded to Google Doc can be stored online, and accessed for future use when published on the web.

 

Zoho Writer is a free online collaborative authoring tool that allows users to edit, store and share documents remotely in a word-processing environment. It allows multiple users to work on a document, both online and offline at the same time.  When offline users go back online, their offline changes sync with the online document. Zoho Writer integrates with other Zoho Apps plug-ins, as well as plug-ins for Microsoft Office that allow edits to documents created in Microsoft Word or Excel to be saved in a Zoho writer format. 

 

Wikis are web-based applications that allow users to collaboratively create and edit web pages using any web browser.  A Wiki is enabled by server software that allows users to create and edit the contents of a web page in the browser. The next three products are collaborative authoring tools generated by a Wiki engine.

 

PB Works (formerly PBWiki) is a commercial collaborative service that allows users to create free basic wiki workspaces or to upgrade to premium access to additional features. Its business component comprises features that foster collaboration with customers and partners. These features include the sharing of online workspaces, collaborative page editing, voice collaboration and other business-related features. The educational component facilitates hosting of educational workspaces for institutions such as DePaul and other major universities. It features include collaborative editing, history and audit trail, student invitations, and features categorized into security and customization.  The personal components are similar to the educational ones; a free trial is available at http://www.pbworks.com.

  

Wikispace is another commercial wiki hosting services that provides wiki space for businesses, educational institutions as well as personal wiki spaces. Its main features include a page editor with attributes for text format, file uploading, links to other pages, widgets and other features. In addition, the "manage wiki" function establishes a collaborative authoring environment for invited teams.  There are also features that foster effective collaboration, including sections for content, people, settings and tools

 

Wetpaint is a wiki hosting service that provides free space for wikis and website-building capabilities.  Its outstanding features include the ability to create a collaborative authoring tool via a website that provides invitations and access to other contributors. Below are screen shots of these features; members can apply for authoring privileges. 

 

Below is a chart that looks at each of these tools a little deeper in term of how well they meet the the requirements previously discussed. 

 

Requirements  Google Docs  Zoho Writer  PB Works  Wikispace  Wetpaint 

Individual Writing

Basic-word-processing

Seamless with other media 

 

++

++

 

++

++

 

++

 

++

 

++

Collaborative Writing

Preserve identities

Enhance Communication

Enhance Collaborator Awareness

Focused collaboration

Peripheral Awareness

Annotations

Undo

Session Control  

 

++ 

++

 

++

++

++

++

++

 

++ 

++

 

++

++

++

++

++

 

++

+

 

++

++

-

++ 

++

 

++

+

 

++

++

-

++ 

++

 

++

+

 

++

++

-

++ 

++

Roles

Explicit roles  

 

 

 

++ 

 

++ 

 

++ 

Activities

Variety of Activities

Brainstorming

Researching

Planning(outline)

Planning(process)

Writing

Editing

Reviewing

Transitions between activities

 

 

 

-

-

+

-

++

++

-

 

 

-

-

+

-

++

++

++

 

 

-

-

+

-

++

++

++

-

 

 

-

-

+

-

++

++

++

-

 

 

-

-

+

-

++

++

++

-

Document Control Methods

Several Access Methods

Separate document segments

Version and change control  

 

+

-

++ 

 

++

++

 

++

-

++ 

 

++

-

++ 

 

++

-

++ 

Writing Strategies

One or several writers

Synchronous writing

Asynchronous writing  

 

++

++ 

++

 

++

++

++ 

 

++

++

++ 

 

++

++

++ 

 

++

++

++ 

 

We have looked at only a small sample of free collaborative authoring tools.  As you can see from their features and how they map to the requirements above, they have many functional similarities and short-comings.  One of the main areas in which all seemed to fall short was in support of other writing activities such as brainstorming and process planning.  As mentioned in the human factors section, these can be important aspects of many writing projects. 

 

In addition, the four wiki products examined here do not support seamless integration with other media, which would make it difficult for users to work offline.  Other products can handle some of these requirements -- for example, Author-it Live, Sharepoint, Alfresco or Confluence, which are available for purchase. Additional software can also be used for some of these functions if it is not readily available in a given tool. 

 

The important thing to keep in mind is what goal you have and what system functions are essential to reach that goal.  For example, if the ability to work seamlessly with other media is essential to the success of a project, then choosing a tool such as a wiki that does not support that would be detrimental. 

 

There are many software options to support collaborative authoring, and there is not likely to be one single solution that incorporates all requirements discussed in this section.  Nevertheless, the usefulness of these tools should not be discounted.  Not every collaborative project will require all of these functions.  These requirements should help you evaluate and choose an appropriate tool to support varied projects, depending on your needs.  Your first step should always be to decide what is important to you in a system and match those requirements to a software solution. 

 

VI. CONCLUSION

 

Collaborative authoring has evolved considerably in the age of the Internet.  The advent of wikis and other tools that enable both synchronous and asynchronous collaboration among disparately located authors has increased the flexibility and efficiency of collaborative authoring.  It has allowed more complex forms of collaboration, such as parallel and reactive writing, though single author efforts remain common.

Despite increasingly robust tools, however, human factors still remain an important consideration in any collaborative authoring effort. Defining roles and objectives early in a project and clearly communicating those to participants are essential in mitigating the risks that naturally come with a group of people working together.  The collaborative process itself is governed by a series of controls, both primary and secondary, that can be designed and implemented to impact behavior.

Finally, when selecting a tool for a collaborative authoring project, it's important to understand and define all requirements for both the process and the end product ahead of time, and find a tool that closely aligns with both.  Careful consideration of the requirements will help identify a tool that can meet the needs of the group and provide a satisfactory experience in getting to that shared goal, the co-authored document.
 

 

 

References

 

Emigh, William, and Herring, Susan C. “Collaborative Authoring on the Web: A Genre Analysis of Online Encyclopedias,” Indiana University. 2005.

Lowry, P.B., and Nunamaker, J.F., Jr. “Using the ThinkLet Framework to Improve Distributed Collaborative Writing,” Center for the Management of Information, Arizona University. 2002.

 

Baecker, R., Nastos, D., Posner, I., & Mawby, K. (1993). The user-centered iterative design of collaborative writing software. Interchi '93, 399-405.

 

Don Tapscott, Anthony D. Williams. Wikinomics: How Mass Collaboration Changes Everything

URL Accessed 7/9/2010

http://books.google.com/books?id=DVomiOeBg_YC&lpg=PA1&ots=45pHATOdmd&dq=youtube%20collaboration&lr&pg=PA1#v=onepage&q=youtube%20collaboration&f=false

 

Aunger, Robert. 

The Electric Meme: a New Theory of How We Think. Free P, 2002.  

 

Joakim Danung, Lissa Holloway Attaway

All Your Media Are Belong To Us: An Analysis of the Cultural Connotations of the Internet Meme. 17 April 2008

URL Accessed / Downloaded on 7/9/2010

http://bth.danung.com/danung_rsch.doc

 

Vodafone.com  Beatclips#02, the new music clip created by 1,000 internet users and Kutiman, 26 October 2009

URL Accessed 7/9/2010

http://www.vodafone.com/start/media_relations/news/local_press_releases/spain/spain_press_release/beatclips_02__the.html

 

MICHELE KNOBEL AND COLIN LANKSHEAR

Online Memes, Affinities, and Cultural Production

URL Accessed Downloaded on  7/9/2010

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.3508&rep=rep1&type=pdf#page=209

 

Moor, Aldo. Kleef, Rolf.  Authoring Tools for Effective Societal Discourse.  URL accessed 9 July  2010.      

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.9583&rep=rep1&type=pdf.

Wikipedia.  Mass Collaboration.  URL accessed 9 July 2010.   http://en.wikipedia.org/wiki/Mass_collaboration.

Zhang, Z. Haffner, E.  Role-based Access Control in Online Authoring and Publishing Systems vs.   

Document Hierarchy.  URL accessed 9 July 2010.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138.7104&rep=rep1&type=pdf.

Wikipedia.  WebDAV. URL accessed July 9, 2010

http://en.wikipedia.org/wiki/WebDAV

Sipro, L. Collaborative Authoring. URL accessed July 10, 2010

http://digitalresearchtools.pbworks.com/Collaborative+Authoring

Derouin, T, Viren Tom. How to Start a Wiki URL accessed July 10, 2010

http://www.wikihow.com/Start-a-Wiki

Zoho Writer, Easy Online Word Processor-Create-Connect-collaborate. URL accessed July 10, 2010

http://writer.zoho.com

Wikipedia. PBWorks, URL accessed July 9, 2010

http://en.wikipedia.org/wiki/PbWiki

Wikispaces. Wikis for Everyone. URL accessed July 10, 2010

http://www.wikispaces.com/

Wetpaint. URL accessed July 10, 2010

http://www.wetpaint.com/

 

10/3/2010 Revised Outline: Chapter 10 Collaborative Authoring (Revision)

10/24/2010 Revised Chapter Draft 1: Collaborative_Authoring_V1.doc 

 

Copy of Collaborative Authoring 

 

Return to Book

 

 

Comments (6)

terbush@... said

at 2:01 pm on Jul 14, 2010

Be sure to provide citations for all graphics.

jeneesaunders@... said

at 5:04 pm on Jul 12, 2010

While their is only so much one can do with an outline I do have some suggestions. First let me start by saying that your outline flows very well and that is one of the key aspects of this book. The only thing I could think of in this outline stage would be to combine "The types of Media in Collaborative Authoring with the actual collaboration tools. One could give examples of tools while explaining for example "The Visual aspect".

William Douglas said

at 5:26 pm on Jul 11, 2010

Hard to comment on this at this point as this outline is really just notes. I am assuming they are expanding on this further. Other than that, I feel that the introduction and why it is necessary are one of the same.

Jerry said

at 6:31 pm on Jul 10, 2010

I've noticed a problem with all chapters of the book, not just this one. The book is always trying to justify Collaborative ______. It feels like this should be done in a completely different chapter and then subsequent chapters can assume that it's a good idea. By not doing this many chapters just repeat the same information.

I'd also talk about Google Docs new collaboration features. My group will present about them on Monday, so I am probably biased. You can do real-time chats and see real-time edits.

Teonna I. said

at 3:16 pm on Jul 10, 2010

When reading the outline I thought of a couple of questions. When I think of collaborative authoring advantages, I think multiple point of views are better than one; editing can be done by all involved; expenses are minimized; everyone can build upon each others ideas and suggestions. As far as disadvantages, it can be a lack of focus and it could take longer to complete the project. The current adv/disadv listed in the outline may be too narrow but this is just my opinion. Also, aren't there more roles assigned in a collaborative authoring project than the one's listed here?

terbush@... said

at 5:01 pm on Jul 2, 2010

A little more about the theory/basis of collaborative authoring (types of CA) see my early slides. If you need more references, let me know.

You don't have permission to comment on this page.