A Post by Michael B. Spring

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

What we still don't do in collaborative authoring (August 13, 2008)

In the post prior to this one, I tried to answer the question "What happened to the research on 'collaborative authoring.'" In that post, I made a casual claim that today's web systems are lacking in several ways. This post speaks briefly to what we haven't yet gotten a grip on as we explore wiki and blog spaces. It is a possible roadmap for development of these new web based systems.

  1. Document locking. Ever try to have people really work on a document together. It is damn near impossible. We struggle to define schema that really model complex documents. Most people like html because it has no structure. On the other hand, good xml documents are real rich complex trees. They have a predictable structure. This allows branch pruning and grafting that allows for fine grained and coarse grained locks. We still do not see intuitive and easy to use document locking models.
  2. Document access controls. When we built CASCADE, we used five access levels -- executive, authoring, editing, commenting, and reading. Subsequent work suggests that it may be appropriate to have as many as seven. Given these new models it is relatively easy to use the existing work on role and time based access control to begin to build an easy to understand an use access control system.
  3. User and group awareness. Increasingly, systems are tailored to individual needs. It is the only way of dealing with information overload. What has happened since the last time I looked at the system and what demands my attention. Tell me only what I want/need to know and hide the rest. Similarly, whether I am a leader or follower, I need to be aware of what my teammates are doing in some meaningful and simple to interpret way.
  4. Wow tools. There are any number of tools that can be built once a base framework is in place. One of my favorites from a decade ago was what we called the comment report. Basically, every comment made in CASCADE was classified along up to four dimensions. I frequently used the dimensions of target audience, status, and type. So, a given comment might be an objection, which was open, and targeted at the editor. The comment report allowed you to select any number of pieces of the document, any or all classes of all the dimensions, and then have the system build a summary or detailed report. So, I could ask for all objections that were open and targeted at the editor. The system would produce a list of the 3 or 300 comments in a second and build a report that acted as an ad hoc hypertext document that would with a click take me to that portion of a vast document where the comment was located. Similarly, the data structures allowed me to access information about what a group, individual, set of groups, set of individuals were doing in terms of a large enumerated set of action types, across the project as a whole or any subset of files or folders. Again, the results were an active hypertext report. There were dozens of these tools that reduced hours of drudgery to seconds. But they were all dependent upon the infrastructure.
  5. Enhanced Communication. The term deixis refers to aspects of a communication whose interpretation depends on knowledge of the context in which the communication occurs. So for example, a commenting system that places the comment in context allows a comment like "what's this". It is easy to type with the meaning based on context. When one looks at wikiís that allow comments only on the page as a whole or big sections, deixis is much more difficult. Would it be nice to comment on a word, a sentence, a person in an image, a small fragment of a video, etc. These add complications in coding and nightmares related to editing, but they are all theoretically possible. Of course context is potentially far more complicated. Who am I, who is the communication with, what is the nature of the hat I am wearing, etc. all impact what the communication means. Our auxiliary communication tools are all relatively primitive and isolated. Imagine systems that switch from voice to text to images as needed by the context. Imagine that people receive information in a form appropriate to their preferences.
  6. Lost in space. Perhaps one of the most frustrating parts of blogs and wikis for me is the lack of a visual navigation structure that allows me a high level overview of the structure. I am not pushing CASCADE, but it had a feature I really like. It began with the login. I was presented with a list of all my projects and a summary of the activity in each project since I last visited. The summary was a number that reflected the number of distinct atomic activities since my last visit -- examples of atomic activities included comments made, comments answered, comments reclassified, documents added, documents edited, documents deleted, etc. There were about 40 of them. For each project I would get a single number which aggregated them all -- and keep in mind, one of the wow tools allowed me to see a list of those of interest to me that was an active hypertext structure. Next, I always entered the project at the root, and could always get back to the root. (Never too lost in space) At the root, one would normally find a set of folders and a few documents. Folders had light type on dark backgrounds. Documents had dark type on light backgrounds. Dark Blue folders were like those you know. Dark brown folders were ordered -- i.e. you could add a folder or document without specifying the order. The system allowed for other folder types of be defined. Images were generally light blue, GIF's had red type, TIF's had blue type, etc. Text was light yellow, XML used blue type, ASCII, used black, etc. You get the idea. Finally, there was a thin red line across the bottom of the icon that indicated the number of document in a folder or the number of comments in the document. It was amazing how with a little practice and orientation, this system of visual navigation greatly reduced the feeling of being lost in hyperspace.