Design for individuals, design for groups: Tradeoffs between power and workspace awareness
Citation: Carl Gutwin, Saul Greenberg (1998) Design for individuals, design for groups: Tradeoffs between power and workspace awareness. Proceedings of the 1998 ACM conference on Computer supported cooperative work (RSS)
DOI (original publisher): 10.1145/289444.289495
Semantic Scholar (metadata): 10.1145/289444.289495
Sci-Hub (fulltext): 10.1145/289444.289495
Internet Archive Scholar (fulltext): Design for individuals, design for groups: Tradeoffs between power and workspace awareness
Tagged: Computer Science (RSS) CSCW (RSS), shared workspaces (RSS), design (RSS)
Gutwin and Greenberg's article makes a very simple argument in this paper: synchronous groupware software supports work that is both of and for an individual and for a group, and that the requirements of supporting an individual and a group often conflict. Using the example of shared workspaces (where the authors are active), they show that the needs of the user to have a customized and powerful interface will often conflict with the need to provide awareness of what others are doing. In particular, the authors consider this trade-off in regards to workspace navigation, artifact manipulation, and view representations and offer sevearl ideas of how to address these.
The key tension is set up between two desires or requirements of a groupware system (with a focus on shared workspace):
- Support for individual control over the application.
- Support for workspace awareness (e.g., Dourish and Bellotti's (1992) Awareness and coordination in shared workspaces).
The authors then breakdown this effect into workspace navigation (WYIWIS versus more relaxed versions which give users more flexibility), artifact manipulation which might be designed to give an individual more power or a group more information, view representation which can either simplify individual work but complicated communication (see Tatar et al.'s Design for conversation: Lessons from Cognoter).
On some level, these are unavoidable. Designers can use "radar" views or "viewports" but there will be a tradeoff on the amount of screen real estate devoted to each of these. The authors argue strongly for what they call process feedthrough which is similar to feedback except it is received by others rather than just the individual doing the action. These might be implemented in a variety of ways including "action indicators" and animations (e.g., imagine how to represent something being deleted by a user). In terms of view representation, they suggest focusing on building location transformations that can represent actions symbolically in a slightly different situation by focusing on the semantic meaning of the action and transforming it. For example, imagine updating text in in a collaboratively text editor that has been resized.
The authors argue that a stronger understanding of collaboration will make handling these issues easier, that improved technology can both help and aggravate these projects, that increased demands will be put on designers in addressing these, and that some degree of a tradeoff will stay in any solution.
Theoretical and Practical Relevance
The basic argument about a tension between the two is hinted at in Grudin (1994)'s influential Groupware and social dynamics: Eight challenges for developers. Alternative, Grudin's very strong argument to integrate the two may downplay, or even aggregate the core argument.
The article has been cited 260 times since it was published 12 years ago in the CSCW literature with a strong showing by those also working shared workspaces.