|
|
Andrew F. Monk,
Department of Psychology,
University of York,
York YO1 5DD, U.K.
AM1@york.ac.uk
Jean Scholtz,
Intel Corporation, JF2-210
5200 NE Elam Young Parkway
Hillsboro, OR 97124, USA
Jean_Scholtz@ccm.jf.intel.com
Bill Buxton
Alias | Wavefront Inc.
110 Richmond St. E.
Toronto, Ontario, M5C 1P1, Canada
Sara Bly
Sara Bly Consulting
24511 NW Moreland Road Hillsboro,
OR 97124 USA
sara_bly@acm.org
David Frohlich
Hewlett-Packard Laboratories
Filton Road, Bristol, BS12 6QZ, UK
dmf@hplb.hpl.hp.com
Steve Whittaker
Lotus Development Corporation,
One Rogers St, Cambridge
MA 02142, USA
whittaker@crd.lotus.com
Copyright on this material is held by the authors.
The object of this panel is to identify criteria for effective groupware. That is, criteria that can be applied either to guide design or to help a purchaser select from alternative groupware applications. The criteria are expected to be generally applicable and so we take a broad definition of groupware. Panellists have been chosen with expertise in low bandwidth groupware such as email and PDAs as well as higher profile multi-media applications.
Designing and evaluating systems for one person interacting with one computer is still a significant challenge. Designing and evaluating groupware systems is exponentially more difficult. As well as having to consider human-computer interactions, one has also to consider, human-human interactions, computer-computer interactions, and human-another-computer interactions. In addition, the tasks to be supported by a groupware application are likely to be quite different to those supported by a single user application. There must be support for individual work as well as group efforts.
The panel is to identify criteria that can be applied either to guide design or to help a purchaser select from alternative groupware applications. Some criteria arise because of demands on the individual. The need for ease of use and low cognitive effort in human-computer interaction may be particularly important in a groupware application where the user's primary task is communication. Others arise because of demands on the group. A commonly identified problem with software is that members of a group may not be aware what the other members are doing. Finally, some criteria arise because of demands on the organisation, e.g., the requirement for critical mass.
Criterion: Operational transparency
Exemplar: Meeting rooms, the Ontario Telepresence Project
Bill is Principal Scientist at Alias | Wavefront, director of the Telepresence Project, and a professor of Computer Science at the University of Toronto.
It sounds banal to state that the interactions in group activity are complex, but when it comes to supporting such interactions via technology, it seems that even the banal, or seemingly obvious, needs to be made explicit. Perhaps this is because, despite the complexity, we are so skilled in the task, that we take it for granted, or forget how long it took us to learn. A bit like tying up one's shoelace, or riding a bicycle. Note, however, that all of the preceding has to do with the "how" or operational aspects of group dynamics, not the content. And it is just as well that we are skilled in these tasks, or else there would be serious task interference between the "how" and the "what" aspects of interaction.
All of this leads to the point that when group interactions are mediated by technology, the risk of interference rises dramatically. And the simple point that follows, then, is that the objective of good design is to make the intrusive aspects of the technology disappear as quickly as possible. In this presentation, we will discuss how this can be achieved, using examples from the Ontario Telepresence Project. What will unfold is a story of adaptive environments, that have knowledge about domain specific activities, and which are tailored to fit the existing (social) skills of the group - skills already acquired from a lifetime of living in the everyday world.
Criterion: Personal benefit
Exemplar: Communicating personal digital assistants (PDAs)
David is a member of the User Studies Group at Hewlett Packard Laboratories in Bristol.
Some time ago I learned of an interesting comparison between two groupware systems designed to collect healthcare statistics from mobile community care professionals. The first system, called COMCARE, ran on a handheld computer and required workers to input patient and visit statistics primarily for management audit. This took considerable time and effort and workers were very bad at keeping their statistics up-to-date. The second system, called COSS, ran on a laptop computer and required workers to input the same statistics. However this time, the statistics could be used by workers themselves through an additional patient care planning system. Consequently workers were better at maintaining up-to-date records, which management could then use to improve the funding and coordination of group work. Thus the second system was altogether more successful because it provided a personal as well as a group benefit to workers.
Taking forward this simple lesson I argue that personal benefit is a powerful criterion for effective groupware, and particularly appropriate to the design of lightweight tools for remote collaboration. Using data from a video-based study of mobile professional work I show that much personal work is itself interpersonal in nature. This means that substantial personal benefits can be provided through support for communication as well as for personal information management; as shown by the rise of the communicating PDA as the ultimate 'personal system'. I also point to the need for effective groupware to deliver mutual personal benefit across the workgroup so that some members do not use the technology to exploit the goodwill of others to their own benefit. Taken to its conclusion, this argument suggests a new paradigm for groupware in which group benefits are specified as emergent properties of tools supporting individual collaborative work.
Criterion: Adaptability
Exemplar: The PARC Media Space
Sara is an independent consultant in the areas of user interfaces for individuals and distributed groups.
Adaptability is a critical criterion in determining the potential success of a groupware application. Applications that allow users to adapt the technologies to their own needs and uses allow social behaviours to rule interactions as appropriate and provide the opportunity for codevelopment of the technology and the work activity. In particular, it means not building a set of procedures and structures into the technology that dictate group behaviour. At one point in the history of the Xerox PARC Media Space, monitors were configured so that one could not see the display screen without also being on camera. While this offered a good basis for ensuring reciprocity in viewing, it also constrained the camera position. The technology had taken on the responsibility for enforcing the rule that "If you can see me then I can see you". In fact, the group had used the technology in many interesting and useful ways precluded by such a ruling. Participants moved cameras to bring attention to something they wanted to share (a view outside of a pretty day, a whiteboard illustration of a discussion underway); participants glanced at monitors from a variety of positions to stay aware of remote sites; participants situated cameras for interesting office overviews.
To meet the adaptability criterion, we must allow users as much control over the technology as possible. This is not to say that applications should leave all decisions to users but rather to provide configurations that can easily be changed. For example, privacy is certainly an important issue in groupware applications. Looking at it from the adaptability point-of-view suggests that the technologies support the users in establishing their own modes of behaviour. Most of us would find it silly to enforce locked doors in all workplaces despite the fact that an open office offers the possibility of intrusion. Groupware applications should offer tools rather than rules.
Criteria: (i) Critical mass and (ii) Awareness.
Exemplar: Lotus Notes
Steve is a Research Scientist at Lotus Development Corporation.
Critical mass means having enough users of the product/prototype, furthermore these must be people the user wants to talk to, and collaborate with. The importance of critical mass can be illustrated by a number of examples of both asynchronous and synchronous groupware: a Lotus Notes discussion database can fail as a forum for exchanging ideas because there is an insufficiently large number of contributors so that discussions and topics rapidly become stale. Research prototypes we have built have also suffered from lack of critical mass: there is little benefit to having desktop videoconferencing, or lightweight electronic paging technology if your recipient lacks the hardware and software to communicate using these. This makes it difficult to test the utility of these more advanced features and systems. The solution is not a technical one: it requires corporate selling of the product individual sales are unlikely to be successful until there is a large enough user pool.
Awareness is being informed about when others are active, or when critical events occur in a shared application. For asynchronous shared applications such as Notes, users need to be notified of such changes without necessarily having to open the application and inspect its contents for changes. Again Notes discussion databases have been unsuccessful because users are uncertain when and whether their contributions have been seen and responded to by others. Users may contribute to a discussion, but in the absence of notification it may be some time before others become aware of the change. Furthermore, the absence of notification means that such databases cannot be used for urgent or time critical interactions. Solutions discussed include polling and specialised server processes.
We are keen to elicit criteria from the audience as well as the panellists. Forms will be distributed at the beginning of the panel. These use the following headings.
A. Name and affiliation
B. Possible name for criterion.
C. Illustration of the problems that arise if this criterion is not met. (This is best presented as a story including a brief statement of the context.)
D. Examples of the kinds of inventions, features or strategies that can meet this criterion.
E. To what categories of group does this criterion apply?
F. To what categories of application does this criterion apply?
Clearly, much of the information entered under these headings will be necessarily "sketchy". In the session the audience and panellists will fill out the missing details. Please try to confine the criteria to things that apply to particularly to groupware rather than HCI in general. Contributions given to the organisers in advance will be most welcome.