Case Study: Evaluating Groove Using Scape

---

We evaluated Groove^TM to understand how well it can support the awareness and privacy needs of a retail buyer/supplier team. Groove was chosen because there is currently a lot of interest in using Groove (Groove’s customer list, as published on its Web site, shows approximately 100 organizations, including large and small businesses, nonprofits, educational, and government entities). Also, Groove’s functionality is similar to that of several others in its class; it is a general-purpose collaboration application intended to be used by a wide variety of organizations.

After the Groove overview, we discuss how we performed the case study and summarize its results.

Overview of Groove Functionality

Groove peer-to-peer collaboration software provides users with synchronous as well as asynchronous collaboration. Groove uses the metaphor of shared spaces to create collaboration environments. Templates are provided for spaces, and a number of different functionalities can be incorporated into a space. Functions provided by Groove include file storage, calendar facilities, discussion spaces, sketch pads, project planning, and meeting spaces with support for agendas, minutes, and action items. A built-in browser lets participants pull up Web pages within Groove and browse the pages together.

Many of the tools available in Groove are compatible for use with Microsoft Office; these functions provide asynchronous collaboration. In addition, Groove provides text chat and audio chat for synchronous collaboration. Microsoft NetMeeting can be launched from within Groove as well.

Figure 7 shows a Groove shared space with the files tool open. The participant bar is to the left, and the audio chat tool is at the bottom left. A portion of a text chat message is shown at the bottom of the window.

Figure 7: A shared Groove space

Groove provides role-based access for three predefined, standardized roles. A manager sets up the shared space and can invite people as participants or guests. The privileges that one has in a shared space are based upon these roles. In general, guests are allowed read-only privileges, while participants are able to post and edit as well as read.

Groove has two models of working. In tools such as the sketchpad, multiple users can work together at the same time and they see each other’s contributions in real time (as they are made). However, in tools such as the file space, participants open a file that creates a local copy on the user’s machine. Groove contains synchronization detection that updates the document when a user stores a modified file back to the file manager.

Document creation and revision is supported via a document revision tool and an outliner. Document revision automatically creates a folder for the participants who have edited a document, separate from the folder for the original document. Documents in Groove are marked as to whether they have been read or not; this feature enables users to keep track of work they have done.

Groove also provides a “navigate together” feature. All participants who selected the “navigate together” feature will be taken from one tool in the space to another when one of the participants changes location within the space. This feature can be used during a meeting to make sure that everyone is working in the same location.

Groove provides some mechanisms for being aware of the presence, identities, and activities of fellow Groove space users. For example, there is a persistent part of the display showing the participants who are logged in, those who are active, and those who belong to the space but are currently logged off or have been inactive for some time (suspended). The toolbar shows the number of participants viewing any particular tool space. A notice is shown when someone enters a tool space. When users are engaged in text chat, Groove shows when one of the participants is typing.

Evaluating Groove Using the SCAPE Method

Prior to evaluation, we became familiar with Groove functionality and the users’ tasks/roles and prepared the SCAPE materials described earlier in this chapter. We (the two evaluators) decided upon the roles we would play and recruited a third person to assist us. While not an evaluator, this third person agreed to play a role and answer specific questions relating to the levels of privacy and awareness that he observed in the Groove shared spaces during the session.

During the evaluation session, the three of us logged into a shared Groove space from three different geographic locations. We assumed the roles of a buyer, sales representative, and product manager. The buyer created the space and thus was considered the Groove Manager. The other two people were given Groove Participant privileges at first. Over the course of the session, the manager changed their Groove roles to Guest and back to Participant to see how these changes affected their awareness and privacy.

We followed the Master Scenario excerpted in Figure 6, beginning with a discussion of the new juice flavors. After performing the actions indicated in the Master Scenario worksheet, we checked to see if the privacy and awareness requirements highlighted in the worksheet were supported by Groove. We made note of the situations and conditions under which the requirements were not supported.

We communicated with each other nearly continuously during the evaluation session using the Groove chat tool. This tool provides a persistent transcript of all messages; we noted our evaluation observations in chat messages to each other and saved the chat file for post-session analysis. During the main evaluation session, we used Groove for approximately 4 hours.

Results of Evaluating Groove

We combed through the chat file notes and compared our observations to the Awareness and Privacy Policies and the specific requirements noted in the Master Scenario worksheet. Highlights of the results are presented below.

Groove does a reasonably good job of providing awareness but does not support many of the privacy needs for the case in which proprietary information needs to be seen by some collaborators but not by others. For example, Groove provides at least read-only privileges to all users for all documents. It is impossible to mark documents as being readable by only a subset of Groove users. This means that the Sea Spray team members cannot work on a document in a shared Groove space and keep that document private from members of Wal-Store’s team. This situation violates the privacy need specified as, “it is OK to be able to read some documents but not others.”

Of course, the problem of keeping some documents private from some collaborators can be resolved by creating new Groove “spaces” for subgroups of collaborators, such as the Sea Spray team members. This approach has the drawback of requiring collaborators to remember what documents and other information were stored in what spaces, and manage version control of documents that are stored in both spaces for the convenience of avoiding moving back and forth between spaces.

Similar to the document privacy issue, chat messages in Groove cannot be addressed to a subset of the shared space users; the messages are displayed to all users. Thus, team members from the manufacturer cannot caucus privately among themselves using the shared chat tool. This means that the privacy need specified as “The buyer cannot see the sales representative’s bottom price; the sales representative cannot see the buyer’s top price” cannot be satisfied if the relevant pricing material is included in the Groove space.

Groove does not provide the means for two people to have management privileges in a shared space; thus, either the buyer or sales representative would be the manager, and the other could be a participant, at best. While not violating an awareness or privacy requirement, such a situation would not be palatable to two people who are trying to achieve a status in which they are equals in their collaborations.

By default, Groove participants are allowed to invite others into the shared space. Unless the manager revokes this “invitation” privilege for everyone, it is possible for a participant to invite another to be a participant, who invites someone else, etc. Thus, it may not be known to everyone who has been invited and may subsequently join a session. Once someone has joined, their user name will be visible to everyone in the space unless that person restricts what group can see their online identity; but by that time, the damage may have been done if they were not supposed to have had any access to the materials in the shared Groove space. Imagine the consequences of the relatively uncontrolled invitation mechanism for a sensitive shared space containing pricing or budget documents.

While Groove provides awareness of who has revised documents, it does not provide notification of who has revised other shared artifacts. For example, a meeting agenda can be erased or revised by anyone—even a guest—and there is no indication that such a revision has taken place. In fact, most people would be likely to assume that the agenda was authored by the person who scheduled the meeting; this may not be true. Also, the original author does not have any notification that their work was changed. This situation violates the heuristics in he awareness policy: “Show the participant(s) making changes” and “Show the participant(s) who made each historical change.”

---