Nov 5 - Baker, Groupware Heuristics (MSc thesis)

Chapter 3
Groupware Heuristics

Nielsen’s existing heuristics were derived from how well they explained usability problems resident within single-user systems. However, these heuristics are insufficient for groupware evaluation since they do not cater to groupware usability, which is distinctly different from single-user usability.

Single-user usability has been defined as the degree to which a system is effective, efficient, and pleasant to use, given a certain set of users and tasks (e.g., Shackel 1990).
Within this context, usability emphasizes ‘task work’: how a person performs the domain tasks and activities that result in the end products like drawings, documents, or models.
Groupware must also support task work to proceed effectively, efficiently, and pleasantly; however, these systems must go one step further and support teamwork—the work of working together—in order to be trulyusable.
Thus we can define groupware usability as the degree to which a system supports both single-user usability and teamwork. While this definition is a starting point, we need a better understanding of what we actually mean by ‘support for teamwork’.

Teamwork involves activities ranging from low level mechanical acts necessary for almost any type of real time collaboration, to those that are social and affective in nature. If we want to apply the heuristic evaluation methodology to groupware, we need new heuristics that identify those interface aspects necessary for effective teamwork.

Using these, the inspector can then examine the interface to see if adequate support is provided to a group. The problem is that developing new heuristics to evaluate teamwork is complicated since—unlike the single-user interface literature that helped Nielsen set up his heuristics—there is no broad corpus of design guidelines specific to teamwork issues.

As a starting point, I have instead adapted two sources as the basis for two potential sets of groupware heuristics.
1. Mechanics of Collaboration (Gutwin and Greenberg 2000)
2. Locales Framework (Fitzpatrick 1998)
These sources were chosen because they contain some of the few theories or frameworks dealing with teamwork that were specifically created with groupware in mind.

Gutwin and Greenberg’s (2000) mechanics of collaboration identifies those activities that support the mechanics of how people interact over a shared visual workspace. These activities include group members communicating, providing assistance, coordinating activity, dividing labour, and monitoring each other’s work.
I believe that heuristics derived from these mechanics can be applied to task-based groupware (e.g., shared whiteboards, brainstorming tools, etc.), which comprise the majority of existing groupware systems today.

In contrast, Fitzpatrick’s (1998) Locales Framework deals more with the social issues surrounding the use of groupware. Because they define social versus mechanical aspects of teamwork, I believe that heuristics derived from the Locales Framework are better suited for evaluating design subtleties of how social interaction is supported in general groupware environments that support a broad variety of tasks (such as Teamwave Workplace) rather than the mechanical aspects of task-specific groupware. While there is some overlap between heuristics suggested by the mechanics of collaboration and by the Locales Framework, they are both inspired by quite different conceptual frameworks.

I divide the rest of this chapter into two main parts. The first part (Section 3.1) provides a brief description of the mechanics of collaboration, and how I adapted them into eight heuristics. The second part (Section 3.2) follows a similar structure; details of the Locales Framework are presented along with a brief description of the five heuristics stemming from this framework.

3.1 Mechanics of collaboration

3.1.1 Background

The mechanics of collaboration frames the low level actions and interactions that small groups of people do if they are to complete a collaborative task effectively. These mechanics are specific to shared workspace groupware. They include communication, coordination, planning, monitoring, assistance, and protection.
Gutwin developed this framework both from his experience building shared workspace systems and how they were used, and from an extensive research of shared workspace usage and theory developed by others (e.g., Bly 1988, Tang and Leifer 1988, Tang 1991, Gutwin 1997, Gutwin and Greenberg 1999).

3.1.2 Heuristics for supporting the mechanics of collaboration

I believe that the framework can help inspectors identify usability problems of both groupware prototypes and existing systems. While the framework was developed with low-cost evaluation methods in mind, I had to adapt, restructure, and rephrase it as heuristics, and augment it with a few other important points omitted from the framework.
I should emphasize that this was done in cooperation with Gutwin and Greenberg, and there has been a mutual debate and evolution of both my heuristics and how the actual mechanics are being articulated by them over time.

The resulting eight mechanics of collaboration heuristics are listed in Table 3.1.

1. Provide the means for intentional and appropriate verbal communication
The prevalent form of communication between group members is verbal conversations. This establishes a common understanding of the task at hand. Support verbal exchanges or a viable alternative.

2. Provide the mean for intentional and appropriate gestural communication
Allow explicit gestures and other visual actions to be visible since they are done in direct support of the conversation and help convey task information. Support illustration, emblem and deixis.

3. Provide consequential communication of an individual’s embodiment
A person’s body interacting with a computational workspace must unintentionally give off information to others. This is the primary mechanism for maintaining awareness and sustaining teamwork. Couple unintentional body language with both the workspace and its artifacts, and the conversation.

4. Provide consequential communication of shared artifacts (i.e. artifact feedthrough)
Make artifacts expressive so they give off information as they are manipulated. Support artifact feedthrough.

5. Provide protection
Protect users from inadvertently interfering with work that others are doing now, or altering or destroying work that they have done. Provide mechanisms to support social protocols and/or implement technical means to ensure protection.

6. Manage the transitions between tightly and loosely-coupled collaboration
Users should be able to focus their attention on different parts of the workspace when performing individual work in order to maintain awareness of others. Provide techniques for making relevant parts of the workspace visible.

7. Support people with the coordination of their actions
Support awareness of others’ activities to ensure people can coordinate their actions in order to avoid conflicts and make tasks happen in the correct sequence.

8. Facilitate finding collaborators and establishing contact
Provide information on potential collaborators so that they can be easily found and their availability for group work can be determined. Initiation of contact should be possible with minimal effort.

======Table 3.1 Mechanics of Collaboration heuristics=======

3.1.3 Summary

In summary, these eight heuristics look at the essential mechanical acts of collaboration. The physics of the everyday world as well as people’s natural actions means these mechanics ‘just happen’. In the computer world, they must be explicitly recognized as well as designed and implemented into the groupware system.


3.2 Locales Framework

3.2.1 Background

The Locales Framework is an approach to help people understand the nature of social activity and teamwork, and how a locale (or place) can support these activities (Fitzpatrick et al. 1996, Fitzpatrick 1998). More formally, the Locales Framework comprises five highly interdependent and overlapping aspects, as summarized below.

1. Locale foundations define a collection of people and artifacts (tools, information, objects) in relation to the central purpose of the social world. A locale within a social world is best considered as a “center” of collective purpose that is part of a dynamic and continually evolving system. Locales are fluid places with social meaning that may be mapped onto physical spaces.

2. Mutuality considers those interactions within locales that maintain a sense of shared place. Mutuality includes presence information that people and artifacts make available to others, and how people maintain awareness of that information. It also includes capabilities that entities have to transmit and receive information, and how entities choose from these capabilities to create a particular presence-awareness level.

3. Individual view over multiple locales acknowledges that individuals can be participating in many locales. Each person’s view is an aggregation of their views onto their locales of interest. People also manifest a “view intensity” onto particular locales as they vary their focus and participation across locales.

4. Interaction trajectories concern how courses of action evolve and change over time. In essence, people come into locales and social worlds with past experiences, plans, and actions.

5. Civic structures concern how interactions fit within a broader communal level. Civic structures can be considered a “meta-locale” that describe how social worlds and locales relate to one another, how people find their way between them, and how new locales are formed and old ones dissipated.

3.2.2 Heuristics for supporting the Locales Framework

The Locales Framework was not originally developed as a usability evaluation method, rather as a means to understand the nature of social practices in the workaday world and to help inform groupware design. Regardless, it seems amenable to expand this framework into a set of groupware heuristics for several reasons.
First, this is a general framework for understanding the fundamental aspects of teamwork. It describes a small set of inter-dependent perspectives of the characteristics of teamwork, where each could be recast as a heuristic.
Second, it has been validated as a way to understand existing work practices, and to motivate the design of new systems.

Greenberg et al. (1999) first introduced the Locales Framework heuristics. Based on the text and descriptions found in Chapters 1 and 8 of Fitzpatrick (1998), each of the aforementioned aspects was rewritten as a separate heuristic asking whether a groupware’s interface afforded certain social phenomena. Table 3.2 presents a brief summary of these heuristics.

1. Provide centers (locales)
Provide virtual locales as the site, means and resources for a group to pursue team and task
work. The system should collect people, artifacts and resources in relation to the central
purpose of the social world.

2. Provide awareness (mutuality) within locales
People and artifacts must make presence information available to others. People must be aware of others and their activities as they evolve.

3. Allow individual views
Individuals should be able to adapt their own idiosyncratic view of the locale or aggregate multiple locales in a way that reflect their responsibilities, activities, and interests.

4. Allow people to manage and stay aware of their evolving interactions over time
People must be able to manage and stay aware of their evolving interactions. This involves control over past, present and future aspects of routine and non-routine work.

5. Provide a way to organize and relate locales to one another (civic structures)
Locales are rarely independent of one another: people need a way to structure the locales in a meaningful way, to find their way between locales, to create new locales, and to remove old ones.

======Table 3.2 Locales Framework heuristics======


3.3 Conclusion

In support of my research goal, I have developed two sets heuristics for the purposes of
identifying usability problems in groupware.
I would not claim that all groupware applications should support all heuristics. Rather, the heuristics can be used to suggest areas of system strengths, and also areas of weakness that might need to be compensated for in other ways.
While these heuristics are tentative, I believe they are good candidates. Unlike Nielsen’s heuristics, each set is derived from a well-defined theory or framework of group work.


Source: Baker, Kevin F. Heuristic Evaluation of Shared Workspace Groupware based on the Mechanics of Collaboration. [Thesis, M.Sc.] University of Calgary, Calgary, Alberta, Canada. May 2002.