Structuring Feedback for Groupware Use: Memory-Based Awareness Gloria Mark GMD-FIT Schloß Birlinghoven 53754 Sankt Augustin, Germany E-mail: {
[email protected]}
Alex Bordetsky TELCOT Center for Research California State University Hayward, CA 94542 E-mail: {
[email protected]}
Abstract Many awareness mechanisms in groupware systems provide a limited range of information. Awareness information can, however, benefit users in a wide range of system activities. We provide examples of such activities based on experiences with users working with a groupware system in a real work setting. We present a model of awareness which incorporates user feedback and activity information and implement a computerized organizational memory for capturing the feedback relationships. The lowest level of memory that associates different user views and profiles with the group task is illustrated on the basis of a case memory prototype.
1. Introduction In the last several years, there has been an increased interest in the problems that groupware users face due to restricted feedback and activity information of collaborating partners. In a face-to-face group, communication, visual information, and feedback sources are rich and spontaneous. Information about the people, the group atmosphere, and the work context is readily available both through visual cues and tone of speaking. In contrast, when people conduct work processes electronically, especially in distributed locations, the amount of information about people, the artifacts that they handle, and their work practice is very restricted. Whereas in face-to-face groups even informal feedback such as acknowledgements can serve as coordination devices, electronic groups need extra aid to coordinate themselves. For example, observations of group members in a faceto-face setting, working in a control room in the London Underground, revealed that awareness of others’ activities can result by having changes to a common object made visible to all. By monitoring other members’ changes to a common information display, the workers gained awareness of the state of others’ work [10]. Another example is found in [20] who reports on the use of conventions for managing files: group members checked out files by using a whiteboard in a common office as a mediating mechanism; each persons’ activities were visible to the group. The convention enabled the group members to adjust their own work practices as they became aware of others’ actions. Rogers’ example
illustrates explicit dissemination of awareness information, whereas the study by Heath and Luff shows that awareness may also result from implicit means. A few studies have addressed how groupware can provide features to aid coordination. Some examples include Quilt, which offers users a choice of styles to coordinate editing [12]. In the Colab project, the need for a shared reference was realized as an important design consideration [27]. PREP is a collaborative editor which employs role assignment and explicit annotation to aid coordination [17]. To provide activity information to aid users, some systems have incorporated awareness facilities, e.g. [6, 7, 8, 22]. Awareness widgets are a means to provide various individual and group views in a shared workspace [9]. However, most of these applications provide information in a limited range, such as supporting synchronous awareness while ignoring asynchronous activities. One notable exception is the POLITeam awareness client, which provides both current and past awareness information, supporting both synchronous and asynchronous work [23]. The system shows changes in current activities as well as an event history record. In addition, users can specify their own awareness profile according to their interests. It is our position that awareness information must be comprehensive to support the multi-faceted use of a groupware system such as a shared workspace. In this paper, we present examples of how computerized organizational memory could benefit shared workspace collaboration awareness. Experiences with users of a large
1060-3425/98 $10.00 (C) 1998 IEEE
groupware system, POLITeam, led us to develop a model for how a broad range of feedback and activity information about other participants can be incorporated into collaborative work by means of computerized organizational memory. Designing an effective system of computerized organizational memory is associated with a known challenge of integrating informal and documented knowledge [4]. We address this issue by structuring organizational memory based on the feedback relationship of events in a shared workspace. We capture the feedback relationships using a case-based reasoning technique for indexing and retrieving collaborative objects.
1.1. The user group POLITeam is a groupware system designed to supplement paper work processes with electronic processes among government employees in the German government. Since the capital of Germany is moving from Bonn to Berlin, there is a need to support communication and collaboration between employees remaining in Bonn and those moving to Berlin. POLITeam is based on the groupware system LinkWorks1, and a shared workspace and electronic circulation folders were adapted to the users’ work requirements. For further information, see [11]. POLITeam is currently running in three locations. The focus of this analysis is based on experiences with 12 users in the Federal Ministry of Family Affairs, Senior Citizens, Women, and Youth, in Bonn, and in a corresponding ministry department in Berlin. Although we are basing our case study on a limited number of users, we have had the opportunity to observe them for about two years in a longitudinal study. It is for this reason that we feel that their experiences, and user requirements that we have gained, can serve as a basis for developing our model.
We present our results from a collection of material: workshops, site visits, discussions between designers and users, and user interviews. Transcripts were also used from four workshops, in which the design team met with users: the first workshop was held shortly after the first system version was finished; the second workshop was held six months after the system introduction; a third workshop was held in February of 1996 to present the new system version; and the last workshop was held in June of 1996 to discuss specific features with the new system. A long list of user requirements for conventions emerged during this workshop. This last workshop was followed after five months by a series of semi-structured interviews with the users, which lasted from 1 ½ to 3 hours each. The interview questions
LinkWorksTM is a groupware product by Digital.
1.3. Cooperation in a shared workspace With POLITeam, communication and cooperation are supported by shared workspaces and email. The shared workspace supports document production between two units in the ministry: the writing office and a ministry unit. The task of the writing office is to type a draft provided by members of the ministry unit. The shared workspace has two purposes: First, it provides shared access to documents for the writing office and the unit members for the following: to exchange a text initially produced by the writing office, and to have access to a text for the production of a clear copy that has been produced or that will be modified later by a unit member. Second, it provides access to all documents that have been produced within the unit to the unit leader. In the case when the electronic version of the document is modified and then forwarded on paper for further processing, the writing office must incorporate the annotated paper changes into the electronic version. Therefore, the writing office requires that it retain access to the latest electronic version of the document.
2. Problems with restricted feedback In this section, we present examples of problems that occurred with our users as a result of limited information about the activities of their collaborating partners.
1.2. Methodology
1
were developed based on the workshop experiences and consultations with the user advocates. During the interviews, users were asked about: training and support, individual and collective work with the system, cooperation and use of information, the search facility, awareness of others, the shared workspace, and conventions. Questions about conventions included: conventions the users had established and how, disturbing actions from others, conventions needed, violations, views on conventions, and how work styles were affected with (and without) conventions.
2.1. Understanding system behavior The design team approach incorporates three distinct aspects: an evolutionary cycling approach, direct designer-user interaction, and user advocates who serve as mediators between users and designers [13]. The user advocates make regular site visits to the ministry where they discuss user problems and refresh the users on system usage. In addition, a user hot-line exists where users can receive immediate assistance when needed. The following are examples of common problems that the user advocates solved for the users. A typical example which occurred often is that users did not understand that the status of documents in a workspace are affected by other members’ actions. A case scenario can be described from one typist, who reported
1060-3425/98 $10.00 (C) 1998 IEEE
that a document had disappeared from a workspace, which actually occurred through the actions of another workspace member [19]. The typist did not understand that the document was removed by another person, since she received no information that another person had worked on it. The users also had difficulty understanding the processes by which they could manipulate files without visually seeing the documents [19]. For example, the access rights of a folder can be changed from public to private, which affects all files which are included in the folder. When a document becomes private, then it does not appear visually on the desktop to people who do not have the access rights. Awareness information could benefit users in this case since it could inform them of the consequences of their actions. This could help them understand the processes that they cannot see, in this case, understanding that access rights have changed for the files within a folder. It could also inform users when others have changed access rights, which could help people to learn the relationship between changing access rights in a folder and the files within that are affected.
2.2 Forming and maintaining conventions In workshops and interviews, the users described a significant problem they have in forming agreements, or conventions, about conducting their work using the system [14]. Awareness information could be useful in helping users understand how others are using the system, to help them define common usage rules, as well as informing others about violations of such rules. The following are some examples of conventions that the users named as necessary. The typists and unit members use different methods for structuring their files in the shared workspace. The files are structured according to the work role of the users. The typists structure their files according to the members that they type documents for, using a relatively flat structure. The unit members structure their information according to their work processes, using relatively deep fine-grained structures. Similarly, different users prefer to store and access documents using different naming conventions. The typists preferred naming a document by the creator (or owner) whereas the ministry employees preferred naming documents according to content and semantics. The problem arises when group members refer to the same documents in the shared workspace. Awareness information could help users in providing a common view of a document file structure so that users can refer to the same document. Another problem with conventions is that they are often violated. An agreement had been reached among the users during one workshop that documents would not be removed from the shared folders. In other words, members would work on documents within the shared folder. However, commonly members would remove documents and not put them back. With the provision of
feedback information, users could inform others of convention violations. Despite violations, most users report that they do not want to be controlled to follow conventions. Nor does the unit leader want to be an “enforcer“. He argues for the users to inform each other of violations in “subtle and sensible“ ways. This requirement suggests the need for a feedback mechanism for users as a medium to enable them to communicate about convention violations. Feedback is also necessary for determining borders between public and private work in a shared workspace. Users can voluntarily inform others of their activities, such as which document they are editing, while still being able to keep their work private (e.g., when working on early drafts). A third problem that users have is in forming and defining conventions. During the interviews, many users cited the problem as due to the lack of understanding that they have of how others are using the system. As one user described: We must think over, depending on the information that we have, which shared work areas would be sufficient. But I’m not in the situation where I can see that, i.e., where I get information other than that for my own closet. Thus, activity information and feedback could help users understand how conventions could be defined by providing them with a broader perspective of how others are using the system.
2.3 Notification of changes and finished work The typists complained about the extra work required for them to inform a unit member via email when a document was finished [19]. The unit members, on the other hand, complained as well, when they did not receive timely notification. A requirement that emerged was that users wanted the shared workspace to automatically inform others when a document is finished, or when changes have been made.
2.4. Emerging work processes Another area in which feedback and activity information would be useful for the POLITeam users is in establishing new work processes. A work process that is changing concerns the connection that has recently been established between ministry departments in Bonn and Berlin. A shared workspace has been established between the two departments, and is used to exchange information. For example, when someone from Berlin recently requested information about donors to an Institute, then an economic plan was placed in the shared workspace from Bonn, providing immediate access for Berlin. However, this emerging work process again points to
1060-3425/98 $10.00 (C) 1998 IEEE
the difficulty of knowing what conventions are needed, in particular, how the shared workspace between Bonn and Berlin should be organized. Since the fast transaction of information is a new experience for both locations, it is not clear yet what role the shared workspace will have. As one unit member reported: When we use more information together with Berlin, then we must really think what (shared work areas) would be useful. For example, should we have things where we pack five things inside, or something else? It also depends on what it is, i.e., what kind of information. I think that in certain folders, it must be this way. It is necessary. Otherwise we have chaos. Or someone has chaos for themselves.
3. A model for awareness A requirement for an awareness mechanism of a shared workspace is that information should be provided that will facilitate for users the learning of relationships between actions and effects [14]. In a synchronous shared workspace environment, the effects of users’ actions can be immediately seen. For example, ShrEdit, a multi-user text editor, enables users to see the views of others, or to “find“ other users in the shared document [18]. Additionally, one has access to activity information; users can see who is tracking whom. This provides information on other users’ actions, but not their effects. In a study of ShrEdit use, the users asked each other about effects, such as who had written certain parts, or they cautioned each other about the consequences of their actions [5]. The relationship between action and effect is easier to learn in a synchronous, as opposed to asynchronous environment, since actions and effects are contiguous in time, e.g. [15]. However, an asynchronous shared workspace inhibits learning the relationships of actionseffects, due to the multiplicity of events and their time separation. For this reason, an event history which records the actions and effects can be useful to aid users in pairing together the relationships [23].
3.1. A prototypical implementation In this section we describe a prototypical implementation of awareness facilities. Let us consider the model of a support mechanism capable of facilitating the establishment of explicit and implicit conventions in accordance with individual preferences. By explicit conventions, we refer to the idea that the system knows the conventions used, and it can guide their usage and inform users of violations. By implicit conventions, we refer to the system as not knowing the conventions. Rather, the system supports conventions by providing users with enough information about other users’ activities to allow them to establish and maintain them on their own.
In the latter case, the system provides awareness information. Since one of the major problems in establishing conventions for the POLITeam users is lack of feedback in the generic groupware environment, we define such a convention support model as an awareness mechanism. The next question is how the model for an awareness mechanism could be structured. Are there any known examples of successful software mechanisms for convention support? Surprisingly, one of the best known examples of convention support could be found in the area of telecommunications management. It is well known that one of the most successful solutions that provides interconnectivity of heterogeneous networks (i.e., establishes the conventions for LANs “talking“ different protocols) is a TCP/IP control mechanism. Why is it easy for heterogeneous nodes to communicate via the TCP/IP protocol? Because it breaks down the communication relationships to one that is basic and simple: the nodes exchange the packets that are enveloped by all necessary address attributes to reach the destination independently. The routing table (a version of memory) advises where to direct the packet first (the method is connectionless). The control (the feedback) on packet transmission is almost immediate; the packet with an unresolved address, or error detection immediately gets sent back. In the interactive environment of POLITeam, the activities are diverse and driven by individual and group task-related differences. The role of simple basic relationships that could be understood by POLITeam users with different backgrounds and different views on the process, becomes especially important.
3.2. A feedback representation for awareness Based on the above considerations, we suggest constructing the representation for an awareness mechanism by structuring the communication events (relationships) in the categories of attributes for the feedback control process. Definition #1 Let P(t)={X(t), U(t), I(t)} describe the POLITeam supported collaborative task process at any given moment of time t, where X(t) is a set of collaborative process state variables. Examples include: -responsiveness variables (asynchronous, synchronous), -reach variables (communications log), -range variables (sharing pattern (broadcasting, multicasting, routing), membership), U(t) is a set of user input controls. Examples include: -selecting a different circulation path, -sending a new document to the shared workspace, -invoking a desktop video conferencing call,
1060-3425/98 $10.00 (C) 1998 IEEE
I(t) describes the environmental impact to the group process. Examples include: -organizational changes, -deadline changes, -introduction of new information and communication technology, Memory Type
processing and decision-making transactions. Correspondingly, we need to generalize the input, output, state, and environmental categories of the feedback model to be applicable to data processing and decision making transactions. For example, one document is an input to the others. One user has a certain folder to take, and the other must sign it. It is also the case that these multiple Nature of Support
Group/team memory
Small business team support across time and project
Design rationale /discussion memory
Preserves the evolutionary order of product design
Project memory
Support of a large project, usually with distributed participants
Meeting memory
Provides continuity to a series of meetings
Topical memory
Accumulates answers on a targeted range of topics
Document memory
Provide access to a targeted set of documents
Environmental memory
Assists in interacting with the organizational environment
Table 1. Organizational memory types and corresponding applications
P(t) denotes the group process (task) outputs. Examples include: -document, -transaction, -decision(s). Based on this model we can identify the POLITeam Event list as a representation for the following list of structures: POLITeam_Event(t)={ I(t)},t=1,2,….(1)
U
(t),
X(t),
P(t),
At any given moment t of group task processing the structure (1) enables to associate the group output P(t) with the observed state of group communication X(t), individual inputs U(t), and potential environmental impacts I(t). We will use the described structure to represent the instances for all POLITeam objects that we suggest to use to map the cooperative process: -user profile object, e.g., user’s role, scheduling preferences, expertise -document profile object, e.g., date of production, subject area, state of completion -task profile object, e.g., members involved, timeline, document, transactions, decision -folder profile object, e.g., documents that it contains, links to other folders -path profile object, e.g., circulation path, shared workspace, desktop conferencing call The feedback model frame initially maps the relationships for communication transactions. We define conventions as rules that extend further up to the data
relationships cannot be defined prior to system deployment. They could be captured and upgraded only during the run-time sessions with the groupware. It means that we need to add the features for capturing and transferring feedback-based knowledge from the past. Computer-aided organizational memory presents one of the most powerful solutions for delivering the features of the structured awareness mechanism to support groupware convention-making. In the following sections we describe the concept of organizational memory.
3.2. Computerized models of organizational memory and design issues The body of organizational memory (OM) literature is rapidly growing. The definitions of OM vary, but many of them clearly put knowledge management, i.e., knowledge capturing, and knowledge transfer in the center of an organizational memory framework [1, 3, 4, 16, 21, 24, 28]. For example, according to Stein and Zwass [25], through organizational memory, past knowledge is utilized for current activities, in order to increase the effectiveness of an organization. In a groupware environment, in which information technology naturally complements the organizational process, the resources for knowledge management include individuals, teams, procedures and policies, software, hardware, and telecommunication resources. Since this paper addresses the issues of computer models for organizational memory, we look first to previous models. Are there any known computerized organizational memory models that could be directly applied to the specified needs of knowledge management in POLITeam? According to [25], the different computerized models of
1060-3425/98 $10.00 (C) 1998 IEEE
organizational memory could be structured relative to the application tasks as in Table 1. It is easy to see that none of these memory models addresses directly the application targets for the POLITeam memory which are necessary to carry out activities such as speech writing, document approval, and document retrieval and exchange. Nor do these examples represent the solutions for explicit representations of the described feedback structure for POLITeam guided collaborative events, controls, and outputs. The model presented in the next section proposes to provide a representation of events occurring in the shared workspace that can be easily processed by users. However, to better illustrate the value of the model, we need to provide some more background on the POLITeam system usage. Tasks performed in the shared workspace, such as collaborative writing, often involve multiple users and multiple operations. A typical collaborative writing task may involve, for example, two ministry employees composing the speech, exchanging versions with each other, and with the Unit leader, who gives his or her comments, and which are then incorporated into the speech. Tasks done by the Unit employees are also generally conducted in parallel. Additionally, due to the asynchronous nature of the shared workspace, events concerning the same task generally occur spread out over time. The events, as defined in (1), might include a new document version being reintroduced into the workspace, and then the writer notifying the relevant group members. However, documents concerning different tasks are continually being placed into the workspace, such as new speech versions, an answer to a citizen’s query, or new ministry information. Thus, a simple event history list would require much overhead by the users to sort through the events in order to piece together relationships and reconstruct a cohesive event history surrounding one particular task, such as collaborating on a speech. The model we propose involves compressing the representation of a task or of components of a task by relating the events. Such a compressed representation is easier for users to learn because it requires less load on the memory to associate the events e.g., [4].
3.3. Computerized OM as a part of an awareness support mechanism In order to tie the concept of organizational memory to the specific features of feedback structure for the POLITeam awareness information we suggest the following definition: Definition #2 The function of a computerized organizational memory (M) is to facilitate awareness of groupware activities by capturing the feedback relationships:
M: { POLITeam_Event(t), POLITeam_Event (t-1), ...... (2) POLITeam_Event (t-k)}------ >{U(t+1)}
that enable compressed representations for awareness events. From the user perspective, quick access at any time to compressed representations of awareness data facilitates the convention-making process and improves the groupware users’ ability to achieve: -reduction of transaction time, -reduction of task processing time, -increase of the task concurrency, and -learning (increase of complementary knowledge) The memory process (2) facilitates the convention-making process by capturing the structure for: POLITeam_Event(t)={U (t), X(t), P(t), I(t)}
(3)
and providing the cross-references between U(t), X(t), and P(t), for each t (or short interval) which would be the function for communication support of short-term memory, or across the history log: {POLITeam_Event(t), POLITeam_Event POLITeam_Event (t-k)}
(t-1),
...... (4)
For learning, the simplest level of memory that we denote as M1 could be to manage the relationships {P(t), User View (POLITeam_Event(t))}
(5)
This definition fits the metaphor of computerized organizational memory design [4]. According to this metaphor, organizational memory should provide shortterm memory that supports and enhances both individual and workgroup processes, and provide the index for linking to long-term memory. According to the other approach to designing computerized models of organizational memory the efficient computer-supported knowledge management mechanism of organizational memory should employ a combination of semantic-based indexing, environmental scanning, and knowledge retrieval [3]. In our model, the proposed feedback control structure of POLITeam events, is shown by the relationship {P(t),U (t), X(t), I(t)}, which is a representation for semantic-based indexing. Environmental scanning is represented through the I(t) component in the collaborative process output P(t)={X(t), U(t), I (t)}. The knowledge retrieval model is a hierarchy of memory layers (Fig. 1), in which each next layer (from bottom-up) is an association based on the underlined feedback structure.
1060-3425/98 $10.00 (C) 1998 IEEE
User 1
User 2
M2: Artificial Group View(s)
M1: Individual View(s)
M2: Artificial Group View(s)
M2:Artificial Group View(s)
M1: Individual View(s)
Event History: Event 1 Event 2 Event 3
Fig. 1. Feedback relationship layers in memory model
3.4. Implementing case memory with user views of the group process Case memory facilitates the learning of feedback relationships and different user views by utilizing a casebased reasoning technique [26] for indexing, capturing, and retrieving the POLITeam collaborative objects. In this architecture, objects such as individual profiles of collaborators, POLITeam awareness events, and problem solving task profiles are different segments (layers) of case frame representation. Some of the segments are populated in real time such as desktop conferencing and POLITeam awareness events, for example. The other segments, like collaborator, or task profiles are mainly populated during the adjustment interactions with agentfacilitators. In this hierarchy (Fig. 3) Expert profile, Document profile, and a POLITeam awareness events profile are captured by an agent-facilitator and transferred to the case frame via the data base. The other profiles (segments) are populated during the collaborative session interactively. They are reflected in the POLITeam feedback model POLITeam_Event(t)={U (t), X(t), P(t), I(t)} as follows: X(t)={reach, range, responsiveness} U(t)={Expert profile, document profile, POLITeam events profile} P(t)={Task profile (different user views on the task), transaction profile, decision profile}
The case memory provides the following support for making conventions via the feedback process. Distributed experts provide the initial knowledge base for likely cases by populating (in natural language) an appropriate set of frames. The resulting case-base provides a baseline for comparison between the current design situation and a set of known candidate solutions to rank it for a possible match. Previous solutions are stored as a case memory. When a search fails to locate a similar case, the search itself becomes the basis for creating a new case. The POLITeam user could access case memory via the agent-facilitators, which enable collaborators to communicate at different levels of bridges, routers and gateways, depending on which segments of case memory are involved. In the bridge state, the functionality of the agent’s communication is limited to broadcasting (or multicasting) to local agents of the team members. Normally this would apply to the members of the same organizational unit, or the team assigned to several
Task Management segment (populated interactively)
X(t) views P(t) views
Communication management segment (populated by agentfacilitator)
U(t): user profile
Expert Segment Comm. Preferences
Figure 2. Example of M1 level case memory: associating the views consecutive phases of the acquisition process. The format, access rights, and other features of the shared document (model) are not customized by the bridge according to the preferences of individual group members. Everybody gets the same message, or the same document. In the router state, the communication capabilities of the agent are more advanced. The router is capable of generating individual user packets that are customized according to individual preferences and rights. It may then send the packets directly to the team member using his or her direct Internet and/or ISDN address. The router state makes use of multiple control tables to issue the packet and incorporates the bridge functions. The router state would be useful in managing collaborative sessions with representatives of different organizational units that have temporary or unique duties associated with the task-athand.
1060-3425/98 $10.00 (C) 1998 IEEE
In the gateway state, the routing functionality is extended by the capability to communicate with agents who manage different dimensions. For example, the electronic meeting gateway would access the interface bridge to share a portion of the commenting process with other organizations. The functionality of the gateway is the most complex among the three states and requires multiple associative structures.
POLITeam_Event(t)={ U (t), X(t), P(t), I(t)}. Figure 3 illustrates the routing agent-facilitator that provides groupware users access to the case memory and populates the case memory by user profile and awareness events from the system log. In the menu bar at the bottom, “Case profile“ opens up the link to the case memory. The “Preferences“ menu provides the capturing of user
Figure 3. Example of user-memory interaction via the Agent Facilitator Based on the described considerations, we developed the prototype of lower level case memory and an agentfacilitator that provides routing functionality for the POLITeam members’ communication. This prototype could be used by the POLITeam groupware users for receiving awareness information about the different users and their views of the same task. According to the proposed feedback structure for the simplest level of POLITeam memory (5) this prototype represents the M1 level memory. The concept of layered memory model, that is based on the different levels of feedback relationships is illustrated in Figure 1. The function of M1 level case memory is illustrated in Figure 2. We designed the memory prototype in the development environment of ART*Enterprise system (ART Script Programming Guide, 1996) for coding distributed case-based reasoning architectures. In this example, case-memory is a collection of interrelated objects coded in ART*Enterprise Script. The objects are monitored on the basis of an index hierarchy represented by feedback relationships:
communication preferences and individual profiles. The upper segment of case memory keeps group communication state attributes X(t) of the awareness model. The next segment describes the user’s view of the task P(t). The lower portion of the case structure describes the user and document profiles.
3.5. A user scenario In this section we present a user scenario to illustrate the implementation of the model. As described earlier, a typical task for POLITeam users is to collaboratively write a speech for the Minister. In this scenario, several users are involved in writing the speech, and they regularly show drafts to their Unit leader for his comments. We may see a series of events as follows: The task is to collaboratively write a speech on a transportation issue for a particular environmental group P, and it must be finished within a tight time deadline (I(t)).
1060-3425/98 $10.00 (C) 1998 IEEE
The Unit Leader (UL) needs to confer with the Workspace Members (WM) to issue the new task. The UL consults with the workgroup memory via the agentfacilitator. The UL checks recent cases of “environmental group P“ as well as “transportation“. Through the agentfacilitator, the UL identifies that WM1 and WM2 have been previously involved with writing speech topics that concern this environmental group P and transportation issues, respectively. He also finds that WM1 prefers desktop video conferencing, and WM2 prefers asynchronous communication. Then, on behalf of UL, the agent-facilitator issues the video call to WM1 based on his or her conferencing preferences captured in the casememory (X(t)). A decision is reached: WM1 will write an introduction geared to the environmental group P, and WM2 will write the body of the speech which discusses the transportation problem. Reviewing the output (P(t)) segments for both, introduction and text body cases, the agent-facilitator recognizes financial information relevance and prompts the UL to contact W3 to write about finances. Subsequent events appear as follows: • • • • • •
• •
•
Workspace members include: WM1, WM2, WM3, and UL. After several hours, WM1 places a new document version into the shared workspace. Workspace members are notified (U(t)). WM2 removes the document (P(t)). A notification is sent to WM1, WM3, and UL that WM2 has removed the document (U(t)). WM4 places a document for a different task (new ministry finance information) into the shared workspace, and members WM5 and WM6 are notified (P(t)). Finance information is relevant to WM3, and WM3 is notified of the new document in the workspace.(U(t)). WM3 needs the new finance information at once in order to incorporate information into the speech. A request is sent to WM4 for the new finance information (U(t)). WM3 receives the information. WM3 requests a video conference with WM4 and UL to discuss which information should be included in the speech (U(t)).
Thus, we see in this simple scenario that the agentfacilitator can help expedite a task of speech writing by informing users of information relevant to their particular task. The Unit leader receives information to see what previous speech topics the employees have had experience with, and uses this memory to divide up the labor and assign new tasks for the current speech. It is sometimes, if not often, the case in real work that one user will have information relevant to someone else’s task, but is not aware that it is needed. The agent facilitator, in the case of informing the employee that new financial information has been introduced into the workspace and may be relevant for his or her task, provides this awareness information.
While we have presented a simplistic scenario to make the role of case memory clear, we should mention that real work in a ministry is generally much more complex, and user actions and tasks are less well-defined. Considering this complexity, we feel that the awareness information that case memory would provide would prove beneficial for managing multiple tasks in a shared workspace environment.
4. Conclusions In this paper, we presented examples of how actual users working in a shared workspace face a variety of problems by having restricted activity and feedback information from their cooperating partners. The problems involve a lack of understanding of the system behavior, forming and maintaining conventions for system usage, notification of document changes, and establishing new work processes. One of the difficulties for the users is utilizing awareness information, i.e., information about events that occur in the collaborative environment. The problem is compounded due to the potential multitude of information that the users would receive during the system use. Collaborative tasks are performed by multiple users who in turn generally work on other tasks in parallel. Thus, a solution is needed to aid users in understanding and relating the information that they receive. The amount of overhead needed to relate the numerous events without such aid is quite high. Although POLITeam currently has more users than described in this study, we need to issue a caveat about our experiences with a limited number of users. Not only is the count of users small, but their work domain is very specific, namely, a government organization. Workers in a government organization have different organizational policies, tasks, and degrees of work flexibility, compared to what we might expect in other environments, such as industry or academia. Thus, while the user requirements that we elicited as a result of the specific system use might be relevant for future users in this ministry, it is not clear to what extent our results can generalize. We present our results as a case study, and we hope that they can spark further work in this area. However, we would expect that the general problems that users encounter processing awareness information in a collaborative environment could generalize to other domains to some extent. The main aspect we would expect to find in other contexts is the difficulty in processing a large number of events, concerning multiple tasks, and which occur over a period of time. We have presented as a solution a computerized organizational memory feature for capturing the feedback relationship of events in a shared workspace. The awareness mechanism structures the events to provide feedback in the broad classes of transactions: communication transactions, data processing transactions,
1060-3425/98 $10.00 (C) 1998 IEEE
and decision-making transactions. Since it is difficult to define the multiplicity and complexity of relationships a priori to system use, we added the features for indexing, capturing, and retrieving collaborative objects. Our next step is to implement the model and observe the effect that feedback has on the groupware users. We expect to find benefits. When conventions are not followed, a feedback mechanism can inform users to reinforce the correct usage of the system. For specific convention knowledge, such as storing old and current documents, case memory provides support. A groupware environment such as a shared workspace is dynamic: new work operations emerge, membership can change, and activities can be fluid. For this reason, feedback and activity information are particularly well-suited for informing users about changing conditions.
5. References 1. Ackerman, M. S. (1993). Definitional and Contextual Issues in Organizational and Group Memories, UC Irvine ICS Technical Report, pp. 93-42. 2. Bordetsky, A. (1996) Study of the Design Requirements for Integration of Organizational Memory Into the POLITeam Awareness Mechanism. GMD-FIT, German National Center for Research in Information Technology, Sankt-Augustin. 3. Chen, H. McHenry, W. K., Lynch, K.J and Goodman, S.E. (1997). A Textual Database/Knowledge-Base Coupling Approach to Creating Computer-Supported Organizational Memory, University of Arizona. 4. Conklin, J. E. (1996). Designing Organizational Memory: Preserving Intellectual Assets in a Knowledge Economy, Corporate Memory Systems, Inc., Austin, TX. 5. Dourish, P. and Bly, S. (1992). Portholes: Supporting awareness in a distributed work group. Proceedings of CHI’92 (May 3-7, Monterey, CA), ACM/SIGCHI, NY, pp. 541-547. 6. Dourish and Bellotti, V. (1992). Awareness and coordination in shared workspaces. Proceedings of CSCW ‘92, Oct. 31-Nov. 4, Toronto, pp. 107-114. 7. Fuchs, L., Pankoke-Babatz, U., and Prinz, W. (1995). Supporting Cooperative Awareness with Local Event Mechanisms: The GroupDesk System. Proceedings of ECSCW’95, Sept. 11-15, Stockholm, pp. 247-262. 8. Greenberg, S., Gutwin, C., and Cockburn A. (1996). Using Distortion-Oriented Displays to Support Workspace Awareness, Dept. of Computer Science, University of Calgary, Calgary, Canada. 9. Gutwin, C., Roseman, M., and Greenberg, S. (1996). A Usability Study of Awareness Widgets in a Shared Workspace Groupware System. Proceedings of CSCW’96, Cambridge, MA, ACM Press, pp. 258-267. 10. Heath, C. and Luff, P. (1992): Collaboration and Control: Crisis management and multimedia technology in London Underground Line Control Rooms, Computer Supported Cooperative Work (CSCW), An International Journal, vol.1, pp. 69-94. 11. Klöckner, K., Mambrey, P., Sohlenkamp, M., Prinz, W., Fuchs, L., Kolvenbach, S., Pankoke-Babatz, U., Syri, A. (1995). POLITeam: Bridging the Gap between Bonn and Berlin for and with the Users. Proc. ECSCW’95, Stockholm, Kluwer Academic, pp. 17-31.
12. Leland, M. D. P., Fish, R. S, Kraut, R. E. (1988). Collaborative document production using Quilt. Proceedings of CSCW’88, Portland, OR, ACM Press, pp. 206-215. 13. Mambrey, P. Mark, G. and Pankoke-Babatz (1996). Integrating User Advocacy into Participatory Design: the Designers’ Perspective. Proc. of the Participatory Design Conference ‘96, pp. 251-259. 14. Mark, G. and Prinz, W. (1997). What Happened to My Document in the Shared Workspace? The Need for Groupware Conventions. In Human-Computer Interaction INTERACT’97, London: Chapman & Hall Press, pp.413420. 15. Moeller, G. (1954). The CS-UCS interval in GSR conditioning. Journal of Experimental Psychology, 48: pp.162-66. 16. Morrison, J. (1993), Team Memory: Information Support for Business Teams, Proceedings of the Twenty-Sixth Hawaii International Conference on System Sciences, 4: pp. 122131. 17. Neuwirth, C. M., Kaufer, D. S., Chandhok, R., and Morris, J. H. (1990). Issues in the Design of Computer Support for Co-authoring and Commenting, Proceedings of CSCW’90, Los Angeles, CA., Oct. 1990, pp. 183-195. 18. Olson, J. S., Olson, G. M., Storrosten, M., and Carter, M. (1992), How a Group-Editor Changes the Character of a Design Meeting as well as its Outcome. Proceedings of CSCW’92, Toronto, pp. 91-98. 19. Pankoke-Babatz, U., Mark, G., and Klöckner, K., (1997). Design in the POLITeam project: evaluating user needs in real work practice. Proceedings of DIS’97 (Designing Interactive Systems), August 18-20, 1997, Amsterdam, ACM Press, pp.277-288. 20. Rogers, Yvonne (1993). Coordinating Computer-Mediated Work, Computer Supported Cooperative Work (CSCW), An International Journal, vol. 1, pp. 295-315. 21. Sandoe, K. and Olfman, L. (1992), Anticipating the Mnemonic Shift: Organizational Remembering and Forgetting in 2001, Proceedings of Thirteenth International Conference on Information Systems, Dallas, pp. 127-137. 22. Sohlenkamp, M. and Chwelos, G. (1994). Integrating Communication, Cooperation and Awareness: The DIVA Virtual Office Environment, Proceedings of CSCW ‘94, Oct. 22-26, Chapel Hill, NC, ACM Press, NY, pp. 331-343. 23. Sohlenkamp, M., Fuchs, L., Genau, A. (1997). Awareness and Cooperative Work: The POLITeam Approach. In Proceedings of HICSS 30, Jan. 9-11, Wailea, Hawaii, pp. 549-558 24. Stein, E. (1996), Organizational Memory: review of Concepts and Recommendations for Management, Int. Journal of Information Management, 5, 2 25. Stein, E.W. and Zwass, V. (1995). Actualizing Organizational Memory with Information Systems, Information Systems Research, 6:2. 26. Sykara, K. (1993). Machine Learning for Intelligent Support of Conflict Resolution, Decision Support Systems, No. 10.. 27. Tatar, D. G., Foster, G., and Bobrow, D. G. (1991). Design for conversation: lessons from Cognoter. Int. J. ManMachine Studies, 34, pp. 185-209. 28. Walsh, J. P. and Ungson, G.R. (1991). Organizational Memory, Academy of Management Journal, 16, 1, pp. 5791.
1060-3425/98 $10.00 (C) 1998 IEEE
