A Post by Michael B. Spring

(A list of all posts by M.B. Spring)

The research on collaborative authoring (August 10,2008)

I was recently asked what happened to the research on collaborative authoring that seemed to have died out around 2000. The question came to me because of the work I and my PhD students -- notably Bordin Sapsomboon, Wasu Chapanon and Marut Buranarach, had done on a system called CASCADE -- Computer Augmented Support fro Collaborative Authoring and Document Editing. I was reminded of a literature search this past summer on web-based group decision support systems undertaken by a beginning PhD student who was visiting for the summer. Much of the significant literature seemed to have been developed in the early to mid nineties. Since that time, there has been little new work. It is all to easy to simply blame the web. It does indeed seem that much of what students want to do today is simply build little toy systems that provide one small aspect of a solution to problems studied more seriously in the pre-web years. As with most situations, the question would appear to have a more complex answer.

What happened to research on collaborative authoring? Over the years personal reflections have included several reasons why more is not being done.

  1. Maybe we were fooling ourselves. The research that many of us were doing in the mid to late nineties looked to "augment" the "collaborative authoring" process and make it better. My own system, CASCADE was designed to be both a functional system and a testbed for research on the complex phenomenon. At the heart of our work was the assumption that there are people who do, or want to, write collaboratively. Our prototype documents were national and international standards. When all was said and done, despite committees of hundreds, the writing was really still done by only one or two people with lots of comments from others. Indeed, the same seems to hold true in the academic world. While there may be many authors on the proposal or the paper, the vast majority of the work is done by one person. So, observation one is that "collaborative authoring" may be a pipe dream. Generally speaking individuals write, and depending on their situation, make use of comments and feedback from other people. Word with commenting and change tracking facilities may be enough.
  2. The demands of group authoring. In order to accomplish many of the goals of collaborative authoring, such as fine grain locks and style consistency, we needed editors that were somewhat more structured than people were used to -- e.g. we were using xml as the basis of our locking system. User feedback made clear that any editor was great so long as it was exactly like Word, or whatever editor the user was familiar with. At the time, and to a lesser extent still today, Word couldn't do what we needed to do, so we built our own more structured editors. It was an uphill struggle to get end users to accept a more structured approach. Beyond this, even if we could have mimicked Word, we still would have imposed more structure. Corporate documents are not like personal documents, but people don't like to hear that. (As a plug for my own work, I tell my students that the best way to classify documents is as personal, group, corporate, enterprise, or archival. Each is increasingly more restricted and standards bound. It may not be important how you write a personal love note, but documents that flow across enterprises have to be understood by all who encounter them. The penultimate demands for structure occur when a document -- a birth certificate or an academic record has to survive time and space for uses that may not yet be defined -- a requirement for archival documents. Our reality suggested more structure was needed. The user demand was to be able to do whatever they wanted.
  3. Microsoft does what people want. Word got a lot better at supporting informal collaboration. The emergence and refinement of the track changes and SharePoint linkages for word are a real boon. As refinements to the de facto standard -- Word got better, the demand for specialized software diminished. Even if Word is still less than what we were trying to do, it was close enough.
  4. We all fell in love with the Web. I was actively engaged in collaborative authoring research when the web appeared. I was well aware of Berners-Lee's vision of the WWW as an interactive system. When WEBDAV extensions came along, we moved a little closer to authoring as well as dissemination, but it clearly was not enough. Given a few more years we got blogs and wikis. While a wiki does only a tiny fraction of what we wanted to do, for the class of people who like a little collaboration with minimal structure, it was more than enough. So the Web took the low end of the market out. In addition the people who would be the early adopters -- the young people -- think wikis are great and see no reason for real collaborative tools. With time, the growing array of content managment systems will fill much of the gap. It still turns my stomach when I ask PhD students to assess the capabilities of the best wikis. They seldom if ever come up with the dozen or so things they don't do that we were working on in the late 90's. For today's generation concentrated analysis of what would make for great collabortative systems is weak.
  5. The rise of the firewalls. Related to the web, our software was connection oriented client server software. We has state information and knew who was working on what and when. This required a concurrent connection oriented client server system. The protocol ran on a port of its own -- i.e. it did not piggy back on a well known protocol. This was common for client server systems design in the pre web era. As our project moved forward, so did corporate firewalls and between 1996 and 2000 they were being locked down tightly to prevent the growing cadre of hackers trying to penetrate corporate resources. Nothing could get out from individual desktops unless it was directed to port 80. (At one point I wrote a tunneling proxy program that maintained state, but worked through idempotent http connections to satisfy the network Nazi's.) The situation has improved a little since then, but not much. The rich array of distributed software using sophisticated client server protocols were sent into oblivion as firewalls emerged and demanded that anything that was to be done would have to be done through the web protocol -- a stateless request/response protocol.
  6. Research on the social periphery. Some of the most exciting work we were doing was related to adaptation and the social periphery. That is, in face-to-face collaboration you begin to work as a seamless team and you get to read your teammates eyes and perspiration levels -- you can sense who is with you and who is against you. We were working to infer that social periphery based on micro actions and make it visible to team members. As you might guess, trying to make explicit what the best team leaders have been doing for years was not exactly something people endorsed. Too much like big brother. This was the most exciting research, and the most controversial.
  7. The mistaken belief that the goal is efficiency. My work was based on the fact that it takes about 10 years and 10 million dollars to produce a national or international standard in IT. We were going to reduce that to 5 years and 5 million dollars, and I am still convinced we could. The big savings came in supporting synchronous and asynchronous collaboration on the document via the computer rather than traveling to cities like Paris, London, Tokyo, San Francisco, etc, three times a year to meet and iron out details. We also eliminated all the formal paper ballots and mailings. Well guess what. The senior engineers really didn't want to be that efficient. They were at a point in their career where regular travel to global cities for meetings with old friends -- look at the rosters of standards committees -- was a boon not an obstacle. Further, the SDO secretariats at the time were made up of older engineers and the notion of substituting computer based systems for the paper systems that justified their large staff and corporate existence was not quite what they had in mind. ANSI, ISO, and the ITU also had regulations that were paper based in actual specification. Much of this has now changed with the relentless pressure to adopt technology into work processes. While IT standardization is the world I am most familiar with, if you look at the FDA requirements for new drug applications, or FAA requirements for plane documentation, a lot of them during that period were still dependent on paper trails for auditing.