Summary: Awareness and coordination
February 16, 2009
Summary of the article “Awareness and coordination in shared workspaces”
Summary: Awareness and coordination
Summary of:
Dourish, P. and Bellotti, V. (1992). Awareness and coordination in shared workspaces. In CSCW ‘92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, pages 107-114, New York, NY, USA. ACM Press.
In this article, as the title says, the authors talk about awareness and coordination in shared workspaces, specifically in the context of collaborative writing. By collaborative writing, we mean in this case that a team of people work together to write a single document. By awareness, we’re talking about one team member’s awareness of what the other team members are doing, and what they have done. This awareness has two aspects: the awareness of the character of another’s actions, and the awareness of the content of another’s actions.
Character refers to the kind of actions a person might perform in the context of the collaborative work: are they an editor, a reviewer, an author; what sections of the document are they responsible for; what part are they working on? Character in this way is like the role that a person plays in the collaboration, although we should be careful when using the word “role”, since character and role are fluid, and can change as the collaboration progresses. A person can use their awareness of the character of another’s actions in order to structure work and avoid duplication of effort. The content refers to the work that a person has actually done: comments and annotations made; text written. A person can use awareness of the content of another’s work to enable “fine-grained shared working and synergistic group behavior” (p. 112).
The purpose of awareness mechanisms within software is to help users see the character and content of their colleagues’ work, presumably without having to look over their colleagues’ shoulders or ask them what they are doing or have done.
Prior models for providing awareness
Previous attempts at building awareness mechanisms into collaborative editing software concerned informational mechanisms via which collaborators explicitly inform each other of their actions (e.g. RCS, CVS, subversion, etc. commit logs) and role restrictive mechanisms which in some way associate a set of possible actions and activities with roles built into the system, and then assign people to roles.
Dourish and Belloti say that informational mechanisms are inherently problematic (cf. subversion commit logs): the posting user gets no benefit from the update; the posting user determines what information to convey; the posting user determines (in some cases) how to convey the information; and the posting user has to do extra work now in addition to the work of actually producing the work product (p. 109) . About roles: don’t enforce roles, because roles are fluid (in collaborative editing anyway), and hard to define. People may be reviewers in one minute and authors in the next. Secondly, different people may have different ideas about what a particular role should do. Some may take “reviewer” to mean purely annotation, others may want to edit the document (p. 108, 113).
The shared feedback model
Instead, Dourish and Belloti propose a shared feedback model, which makes “information about individual activities apparent to other participants by presenting feedback on operations within the shared, rather than the private, workspace” (p. 109). We want the following things (reactions to things in the above paragraph):
- to collect and distribute awareness information passively, with low overhead for sender and reciever (no added work load)
- to make information available as and when needed as a context for individual activities, allowing participants to extract the awareness information most relevant to them
- to avoid strict roles
- to present the awareness information within the shared workspace alongside the shared object, so that users can see the information and object concurrently, and find the information most relevant to the object
Some benefits of the shared feedback approach are that
- one can peripherally monitor other’s activities and comment on them, so that one is constantly both communicating one’s activities and allowing the opportunity for others to comment on them or observe them for themselves.
- users can tailor their contribution to convey collaboration and coordination information and solicit responses
Shared feedback is all about allowing users to see other’s work and actions as they occur, allowing them to interpret, contribute and coordinate more efficiently.
Shared feedback in semi-synchronous systems
What most of the article is talking about is everyone working simultaneously within the same document space, like sharing one single Word window, as opposed to using subversion to check out a working copy of the document, making your changes and then committing the changes. This is synchronous editing rather than asynchronous editing. However, “we can certainly imagine asyncrhonous awareness information presented in the same workspace as the work object” (p. 113). For example: “change bars,” which highlight the area changed by the last editor, which may also include who did the changing, when, and the nature of the changes. We can present past information of activity within the shared workspace at different levels of granularity.
The experiment with ShrEdit
Dourish and Belloti studied a group of designers using an application called ShrEdit, a synchronous multiuser text editor, to solve design problems. ShrEdit allowed people to have both shared and private windows. Shared windows shows a view onto the shared document, and each user has an edit cursor within their shared window. Shared windows show text as it is being input by any of the participants in the shared document editing session. Private windows are like typical text editors and show a document that only the user can see. These were used for notes or for creating text which would later be pasted. One user could see which other users were editing the shared document, and find the current location of their edit cursors. ShrEdit provided some of the shared feedback model that Dourish and Belloti promote, but had some notable lacks: such as that one could not see one’s colleagues edit cursors.
The authors studied groups of three designers (all with previous experience of working together), each placed in a separate location and linked via audio and/or video to the others. After a a training period, each group was given a specific design problem to solve collaboratively in 90 minutes.
“The shared workspace provided a focus for the designers’ work and discussions” (p. 110). Talk was used heavily to maintain awareness of activities, as well as to discuss design ideas. Participants moved between nearly independent work and tightly focused group consideration of specific elements or passages, relying on awareness to know when to do what. The activities of each group member varied continuously and opportunisitically as things changed.
The problems with ShrEdit concerned how much of other’s activities were viewable. Participants preferred to ask where others were, or construct special indexing schemes to refer to, rather than use the provisions built into the software. Having others be aware of what one was doing was very important, and was accomplished through speaking aloud.
Comments
First, I am struck by how subtle the shared awareness in ShrEdit is; I could not really see it the first time through the paper and ended confused. I realize that I expect an explicit, orthogonal mechanism which provides awareness information. But it was in fact the very core of ShrEdit that provides the awareness: that everyone has a window on the same live document and that everyone can see each other’s edits as they occur. That’s the awareness mechanism that ShrEdit provided, primarily. It also provided some explicit mechanisms, but they ended up not actually being used because they were too much work.
Secondly, Dourish and Belloti build voice/video links right into the experiement, and so much awareness information is communicated in speech, with the shared workspace providing shared context so that speech can be very efficient and contextualized. And people universally used the voice/video link to do much of the coordination and awareness maintenance. So they’re not assuming that the software replaces human interaction completely, which is an extremely interesting choice to me, because I’m assuming (in the world of wiki) that I have no direct human interaction but that all awareness information must be communicated via the system.
Third, I’m also struck at how related Cockburn’s osmotic communication, erg-seconds and shared workspaces (Cockburn, 2002) are to the provision of awareness information via software. They’re really trying to solve the same thing. Well, similar things.
There were two incidental take homes for me: try not to add to people’s workloads in order to supply awareness information (p. 109, 112); people tend to want to respect authorship (p. 111).
