Resolving Function-based Conflicts in Groupware Systems - CiteSeerX

Reference:

Wulf, V., Pipek, V., Pfeifer, A. Resolving function-based conflicts in groupware systems. in: AI & Society, Vol. 15, Springer, Berlin, 2001, pp. 233-262.

Resolving Function-based Conflicts in Groupware Systems Volker Wulf, Volkmar Pipek & Andreas Pfeifer Volker Wulf, Volkmar Pipek ProSEC, Institute for Computer Sciences III University of Bonn Roemerstr. 164 53117 Bonn {volker, pipek}@cs.uni-bonn.de Andreas Pfeifer Lotus Development GmbH Godesberger Allee 115 53175Bonn [email protected]

Abstract In groupware tools, the activation of a function may affect other users who might have conflicting interests. We developed technical mechanisms to support users in resolving them. Contrary to current implementations of groupware tools, these mechanisms strengthen the position of the users who are affected by the activation of said functions. Supporting the visibility of a function's activation, providing a channel for communication or means to intervene against the function's activation are approaches which constitute a framework to implement these mechanisms. We conclude with showing implementation examples of the framework and their evaluation in the POLITeam project. Keywords: Conflict Regulation, Evaluation, Field Study, Groupware, Implementation Architecture

1 Introduction In the CSCW literature it is widely assumed that co-operative work implies the existence of conflicting interests among individuals (cf. Schmidt 1991; Easterbrook et al. 1993). Conflicts may come up at various occasions and may include a wide spectrum of different topics. In this paper we examine how the resolution of conflicts that are related to the execution of a function in a groupware application can be supported within groupware tools themselves. Functions in groupware

Wulf, V., Pipek, V., Pfeifer, A.

Resolving Function-based Conflicts in Groupware

We define a function as a feature implemented in an application whose execution leads to a state transition which is relevant for users and which is perceived as atomic. Functions according to this definition have one or more function anchors that represent the user’s options to trigger the function’s execution. Function anchors are represented at the user interface either explicitly (e.g. as a button in a GUI) or implicitly (e.g. as a command understood by a command line interpreter). We call the user-driven triggering of a function’s execution its activation. A function’s activation may have different outcomes, which usually are at least “commit function” or “abort function” (e.g. a “delete file” function), but which may also vary more (e.g. a “modify access right” function has several different outcomes depending on the access right model used). We call each possible outcome of a function’s activation a functional alternative. Conflicts through function activation In groupware applications conflicts may occur when one user activates a function whose execution produces a state transition of the groupware system. As groupware provides channels to transmit or to share data, a state transition resulting from the execution of a function might affect other users. In that context we regard a function’s activation as the activator’s specification of interest in a certain state transition of the system. That state transition might change the context of function executions of other users in a way that those functions are not as applicable as in the former system state. The actual conflict occurs either when the other users are notified of the state transition and can anticipate that the new system behavior does not meet their interest, or when they try to activate a function whose context has changed in a way that it doesn’t act as desired. For instance, a shared window system provides a function to the users that allows choosing among different floor control policies (cf. Greenberg 1991, pp. 21). The activation of this function to change the actual policy by one user will affect the other users of the section. Thus in this paper, a groupware-specific conflict is defined as a special relationship in which one user either feels disturbed or affected by the fact that another user has executed a certain function or would feel disturbed if he knew about the activation. The function then mediates a conflict between two or more users. Since – especially in the context of the ongoing discussions on “tailoring” of groupware (cf. Trigg et al. 1987; Malone et al. 1988; Greenberg 1991; Henderson and Kyng 1991; Stiemerling et al. 1997) – groupware applications tend to offer more and more flexibility (cf. Schmidt 1991, Wulf 1995a) to users the issue of how to deal with conflicts raised by diverging interests of groupware users becomes more important. Roles in groupware conflicts To examine these conflicts, we have to look closer at the roles of the users involved in a conflict. First we can distinguish between the activator who is responsible for the activation of a function and the user affected by the execution of the function. More precisely, all users who are affected by an execution of one of the functional alternatives are in our terms affected by a function. The users affected may be grouped according to the way they are affected (e.g. in the shared window system mentioned above once the policy has changed the current floor holder might have to pass floor control to someone else and thus loses the right to enter data into the shared window, while another participant gains that right and other session participants have to notice that the input source of the shared window has changed) or according to their interests (e.g. in the shared window system the interests of users really participating and users simply observing the work differ). Between each of those groups of affected users and the activator a special relation exists which represents the specific context of a conflict. We call that the conflict constellation. Though an activation of a function may produce several conflict constellations, which may even influence one another - e.g. depending on which conflict is solved first - we will concentrate on conflicts with a single conflict constellation per function. Legal Considerations for Conflict Management

-2-



In the beginning of the 90’s the German discussion on the introduction of ISDN telephone systems with potentially conflict-causing functionality (e.g. visibility of the person who calls) gave hint to the fact that legal aspects have to be considered also when developing concepts for conflict resolution. In that discussion the "right of informational self-determination" and the "right of communicative selfdetermination", which both derive from article two of the German constitution, got operationalised in a way that the design of communication systems could be based on them. The “right of communicative self-determination” requires that anybody should be able to decide with whom, when, about which content, and via which media they would like to communicate (cf. Roßnagel 1991). Applying these norms, the functionality of different communication systems like ISDN-telephone systems, computer integrated telephony application or X.400 Message Handling Systems has been evaluated (cf. Herrmann 1988; Roßnagel 1991; Höller 1993; Hammer et al. 1993; Wulf and Pordesch 1993). In this discussion a function is regarded as containing a potential for conflict if its execution would threaten the selfdetermination rights of one of the users affected. E.g. the activation of the forwarding function in telephone systems threatens the right of communicative self-determination of the caller whose call gets unexpectedly forwarded to somebody he had not intended to speak to as well as of the new recipient who might be disturbed by the additional phone calls. To handle potential conflicts the authors proposed to (re) design these functions in a way that the constitutional rights of the users affected are protected. Lessons from Conflict Theory In conflict theory as a part of social sciences, a pattern of conflict resolution is presented, which assumes that conflicts can be solved by making them overt and providing mediation if the conflicting parties do not find a compromise (cf. Dahrendorf 1961; Glasl 1992). CSCW researchers (cf. Murnighan and Conlon 1991, Egger and Wagner 1992) challenge these assumptions of the mainstream conflict theory. So, support for conflict resolution does not necessarily have to incorporate negotiation support in each case. Designing CSCW-Systems for Conflict Detection and Management Along with Dourish (1993) we don’t think that it is helpful to try to replace social conflict resolution mechanisms. But since conflicts in groupware are likely to occur we argue that a groupware product should provide means to notify affected users and means for conflict management. Our goal is to develop a systematic framework for the technical support of conflict resolution strategies in groupware and evaluate some first experiences. Conflicts resulting from the activation of a function have not yet been investigated systematically within the CSCW literature. Therefore, instead of presenting the State of the Art, we will simply look at some conflict scenarios from different fields of groupware applications, concluding the section with general observations from computer science and conflict theory. Then we develop a classification scheme for technical mechanisms to support users in regulating conflicts in groupware. We will present a general implementation architecture that allows choosing flexibly among the different mechanisms. At the end we will show how this approach has been used to satisfy user requirements within a participative software development project including an evaluation.

2 Conflicts in the wild In this section we present some typical conflict scenarios from CSCW literature as well as from experiences in the POLITeam project. In later sections we will refer to these examples.

2.1

Examples from the literature

In the CSCW literature we find some case studies which report empirically on the existence of conflicts in multi-user applications supporting communication and cooperation. Gaver et al. (1992) and Dourish (1993) have pointed out that the activation of the "glance" function in the RAVE video communication system has led to conflicts among users. The "glance" function allows the activator to turn on the video -3-



camera in the office of another user for a certain period of time. The glance function was designed to promote (informal) communication among the users. Nevertheless users affected felt disturbed during their work by the one way video channel and feared surveillance by its activation. Cool et al. (1992) report on conflicts among users concerning the establishment of video channels when applying the Cruiser system. On the one hand users in the role of the activator wanted to get connected immediately to the intended communication partner while being in the role of the user affected they wanted to be equipped with a cut-off-function to restrict video access to their personal workspace. They felt a strong need for such an option because established video channels were perceived more invasive than a face-toface talk in the office. Another conflict came up concerning the extent to which the activation of the cutoff function should become visible to the users affected. While the caller asked for detailed information why he cannot establish the video channel and for how long the cut-off will be active, the activator did not want the system to make this information available. As a result of an explorative study in two different fields of application of ISDN-telephone systems, Kahler (1994) reports on similar conflicts between users when establishing a telephone channel. Users in the role of the caller expressed their discontent when the recipients had activated a cut-off function or a call forwarding function, while the recipients stated that this would be the only way to avoid disturbances caused by incoming calls during periods of intense working. As a result of the same study, Wulf and Hartmann (1994) have pointed to conflicts that may occur when somebody activates functions that make the actions of other users automatically visible. While the users in the role of the activator did not feel disturbed by these functions and asked for more of them to ease cooperative task performance, some of the interviewees in the role of the user affected, felt disturbed by them and feared electronic surveillance as a result of their increased implementation. Conflicts among users concerning the consistency of shared data are discussed in concurrent engineering and cooperative software development. Based on experiences gained in the car industry, Condon (1993) discusses conflicts resulting from synchronous manipulation of data in a shared window application. A different potential for conflicts results from data dependencies in Concurrent Engineering. In case someone else manipulates data on which members of a design team have based their decisions, conflicts are likely to occur. These conflicts have been tackled for instance by Bahler, Dupont and Bowen (1994) and Mark and Dukes-Schlossberg (1994). Narayanaswamy and Goldman (1992) have discussed conflicts resulting from inconsistent modifications of program code in cooperative software development projects.

2.2

Examples from POLITeam

In the POLITeam-Project (cf. Pipek and Wulf 1999), the development and introduction of a groupware product into several fields of public administration was accompanied regarding technological as well as organizational aspects. We developed a groupware application in an evolutionary and participative way. Its functionality mainly consisted of an electronic circulation folder, shared workspaces, and an event notification service. Based on the experiences gained by introducing a commercial base system in three different fields of application, we developed advanced versions of the system. The functionality of the system was redesigned continuously according to user demands resulting from their actual experiences in working with the system. Therefore, the development of the project is guided by the actual working practice of the users (cf. Klöckner et al. 1995, Sohlenkamp et al. 1997). An important means for user involvement are different types of workshops in which users, support staff, and designers participate. In the design-centered workshops users and support staff report on their experiences and articulate requirements, to which the designers responded by presenting their concepts for the next version of the system. Conflicts among users caused by the activation of a function have been discussed within several of these workshops (cf. Wulf 1997b). Conflicts concerning the activation of the delete-function in a shared workspace occurred within a section of a federal ministry. This work group had decided to build up a folder to share mailing lists for different groups of recipients. Usually, one of the members of the unit started to build up such a list and made it

-4-



available for his colleagues by storing it in the shared folder. The colleagues used and updated the list for their purposes. Over time the folder became more and more crowded. Thus, the users felt a need to delete mailing lists that seemed not to be used any more. Nevertheless, it was not at all clear which lists were still in use. Thus, whoever deleted a list could violate the interests of those users who were still using it. Within another workshop we presented a new function to the members of the same group. The new function allows to the creator of an object to stop object-sharing with other users. This function had been designed to handle documents that had to be shared just for a short period of time within a group. During the workshop the users started to think of other types of documents on which they would not like the creator to determine the level of object-sharing. For instance, the head of the unit argued that most of the relevant documents were created by one of his colleagues while he would just modify or read them before sending them out. His interests were affected by this function because he could not re-access these documents after its activation by the creator. Presenting a newly designed search tool in a workshop, we also found conflicts between the activator and the users affected. The participants of this workshop belonged to a different field of application - an organizational unit of a state ministry. The search tool presented allows the activator to specify certain criteria to search for documents in the whole groupware system. The result of the search is displayed in a window. The activator can manually select relevant documents out of this window. These documents will be displayed on his desktop even if they were not accessible for the activator before. Thus, this function allows the activator to access other people’s documents. Obviously such a design affects the interests of the users affected. For instance, one user imagined that her boss would sit at night on her computer searching for documents containing certain keywords. Accessing documents while their owner was sick or on holidays was another case of groupware-specific conflicts in both fields of application mentioned before. It turned out necessary to access absentees' documents even when they were not stored in shared workspaces. Nevertheless absentees felt uneasy to allow general access to their private z workspaces.

2.3

General observations

Conflicts resulting from the activation of a function have not yet been investigated systematically within the CSCW literature. Nevertheless, looking at the design of certain applications, one can occasionally find functions equipped with a technical mechanism to regulate such conflicts among the users (cf. Sections 2.1 and 2.2). But these mechanisms appear to be rather the result of accidental than of well-grounded design decisions being aware of different alternatives. Furthermore, the implementation of these mechanisms in general does not offer much technical flexibility. The implemented mechanisms are rigidly connected to the functions they refer to. An evaluation of the effects of these mechanisms does not take place.

activation of alternative f 1


x v := f 1

x v := f 2

xv

xv

xv

xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

xv no conflict regulation x n := x v

transition generated by the system

.

by the activator´s input

xn

xn

xn

x n = f1

x n = f2

execution of alternative f 1

e xecution of alternative f 2

z1

..

activation of alternative f n x v := f n

z2

xn

..

x n = fn execution of alternative f n

zn

Figure 1: State transitions without conflict regulation

-5-



The CSCW literature only offers two modes for handling conflicts caused by the activation of a function. They are either solved in favor of the activator or they are masked out from the ordinary users. In the first case conflicting activations of a function are executed in the way the activator intended by the system. In the second case conflicting activations of a function are often solved either by a rigidly implemented automatism (e.g. concurrency control in traditional information systems) or they are solved automatically according to a specification provided by a privileged user (e.g. access control in traditional database systems). In both cases affected users do not get technical support to perceive the conflict or to influence the activation of a function. Usual ways to specify access rights offer an only slightly more elaborated approach, since for one of the conflicting parties (the user affected) it is possible to specify her interests concerning the affected data files. But neither can the activator specify his interest in a similar way nor does the actual conflict become explicit. This has already been criticized as too inflexible for groupware (cf. Greif and Sarin 1986). Conflict resolution and its technical support are viewed as application-initiated processes that also may incorporate alternatives and iteration. So, to present different types of conflict handling, we will use nested petri nets with individual tokens (cf. Genrich and Lauterbach 1981; Jensen 1981 and 1987). Figure 1 presents the case without any technical support for conflict regulation. Whatever functional alternative the activator selects (xv), it will be automatically executed (xn := xv). Thus, the system directly performs the state transition intended by the activator. Figure 2 presents the case of automatic conflict solution. After the activator has selected an alternative of the function (xv), a build-in-automatism checks whether it should be executed (xn: = xv) or its execution should be rejected (xn: = f-). In this case the user affected does not get involved in the conflict regulation, either.

3 Technical Support for Conflict Resolutions: A framework Thus, regarding the current examples from CSCW and the recommendations from conflict theory, it is clear that we should allow for a more flexible, more user-orientated and more communication-oriented solution to the problem. A communication-orientated approach is especially necessary because we can’t anticipate all possible conflict constellations and because sometimes a user’s input does not represent his real intentions (e.g. because of a misinterpretation of a function’s behavior), and thus there is no real conflict. We want our solution to be understood as embedded into social practice.

z

.



x v := f 1

x v := f 2

..

xv

xv


xv xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

xv

transition generated

automatic conflict solution x n :={x v , f -}

by the system by the activator´s input

xn xn

z1

xn

x n = f1

x n = f2

execution of alternative f 1

e xecution of alternative f 2

z2

xn

xn

..

x n = fn

x n = f-

execution of alternative f n

execution of alternative f -

zn

Figure 2: State transition with automatic conflict resolution -6-


In this section we develop a framework for technical support of appropriate mechanisms for conflict resolution.


z activation of alternative f 1 x v := f 1

..

activation of alternative f 2 x v := f 2


xv xv Intermediate state for x ∈ {f , f , ..., f } xv x ∈ {f , f , ..., f , f } conflict resolution intermediate transition generated The basic idea is to break up state by the system the direct dependency between by the activator´s xv a function’s activation and its input conflict by conflict re gulaexecution. To achieve that we tion steps, regulation introduce an intermediate state to be defined x n :={f 1 ..,f n ,f -} to allow for conflict resolution xn steps. Spoken in terms of figure 1 and 2, possible outcome of this step might be xn xn the execution of any of the xn x n alternatives fi, maybe even the x n = fn x n = fx n = f1 x n = f2 activated one xv, or the execution of execution of e xecution of execution of rejection of the activation (f-). alternative f n alternative f 1 alternative f 2 alternative f Figure 3 presents the necessary adaptations to allow for a participation of the user z2 zn affected in the regulation of z1 conflicts. Compared to Figure 3: Intermediate state for conflict resolution automatic conflict solution (figure 2), mechanisms for conflict regulation among users involve the user affected and offer opportunities to modify the alternative chosen by the activator. All of the following conflict resolution mechanisms formally are specialisations of the “conflict regulation” state transition in Figure 3. v

1

2

n

n

1

2

n

-

..

As the regulation of conflicts among users might take some time, the system may have to stay in an intermediate state during this process. In figure 3 this fact Yes No is expressed by the double right to headed arrow and the intervene additional single headed No Yes No Yes arrows which indicate that the intermediate state is kept awareness awareness up to the moment the conflict regulation is finished. Assuming that users of groupware do not always work at the same time or at the same place technical mechanisms should be offered to support them in solving conflicts caused by the activation of a function. They could make conflicts visible to users affected and

Yes

No

channel for communication

controllability

visibility of acti.

discussability

Yes

No

channel for communication

negotiability

struct. 1-loop negot.

countercontrollability

Figure 4: Classification for conflict resolution mechanisms -7-



offer a channel for communication among them. To offer a base for communication the user affected should have the right to intervene against the activation of a function. In case of disagreement among users these mechanisms could contain a strategy for conflict mediation.

4 Conflict resolution mechanisms The technical mechanisms for conflict management can be classified whether they allow the user affected to intervene against an activation, whether they make a conflict visible or whether they offer a channel for communication. Figure 4 gives a classification scheme for these mechanisms (cf. Wulf 1995a). In the following we will describe the mechanisms resulting from figure 4 by refining the conflict resolution step of figure 3. Controllability Controllability means that there is not any technical mechanism to support users in regulating a conflict (cf. figure 5). It is either intended to allow the activator to decide on usage of the function autonomously or conflict regulation fully depends on social practice. Visibility of action In case of visibility of activation (cf. figure 6) the user affected automatically gets a notification about the activation of a function which causes conflicts. This information can be either sent to him or be kept available for his access. During the design or configuration of this mechanism the exact content of the data set has to be determined. In case it is not sent to the user affected, the duration of its accessibility has to be decided, upon too. Thus, this mechanism makes endemic conflict overt which is a precondition for its solution.

xv no conflict regulation x n := X v

xn

Visibility of activation is realized for instance in the RAVE video Figure 5: Controllability communication systems. Whenever a channel is built up to another person's office, a special sound is automatically produced to inform the user affected (cf. Gaver 1991, p. 305). Moreover, visibility of activation can be reached by a pop-up message on the workstation screen (cf. Dourish 1993, p. 129). If the user affected is in his office at the moment the channel is built up, he can adapt his behavior accordingly. Though he cannot intervene against the opening of the channel by technical means, he may be able to move out of the focus of the camera or redirect the focus of the camera. Thus, the right to intervene might be achieved through social xv practice. Nevertheless, in certain situations it might be annoying for the users affected to adapt their own behavior to someone's activation of a function. Another example for visibility of activation as means for conflict regulation is given by Condon (1993, pp. 180). Conflicts that are coming up when two users attempt to change the same object at the same time on a shared whiteboard are handled by displaying each person's action on the other's screen.

notification available for affected user x n := X v

xn Figure 6: Visibility of action

Interludium: On the structure of communication Beyond making a conflict overt, technical support for its communicative solution could be provided. If the activation of a function has become visible by technical means, a technical channel of mutual communication could be built up in that moment. In the following we refer to this kind of communication channels, which are created on the occurrence of a specific conflict constellation between the conflicting

-8-



parties.1 Such a channel can be realized in different ways. The messages transmitted via this channel of communication among the users involved could be structured, semi-structured or unstructured (cf. Malone et al. 1988). Structured communication would just allow expressing the intended alternative for usage or tailoring of a function. Thus, in this case just highly structured acts of communication would be offered to the users. Additional to these highly structured acts a semi-structured channel would allow the users involved to express further explanations on the desired alternatives. In this sense the coordinator (cf. Winograd 1988) offers a semi-structured channel of communication. Contrary to these types of communication channels, an unstructured version would allow the users involved to provide their point of view without following strict formal patterns. According to the application and its environment such an unstructured channel could be based on textual, Audio or video communication. It could be synchronous or asynchronous. For instance, in case of a conflict a telephone or a video communication line could be built up among the users involved. Thus, a channel of communication makes a conflict always visible to users affected by technical means. xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

xv

Discussability As long as technical mechanisms are restricted to give visibility to the users affected and to build up a channel for mutual communication, we will talk of discussability. Figure 7 gives an example on how discussability could be implemented. The functional alternative is executed immediately, but the users affected are technically supported to establish a communication channel with the activator. By this means they may convince the activator to modify the state-transition performed. As the way a conflict is solved strongly depends on how well the users affected can express their argument, a semi-structured or unstructured version of the communication channel should be applied. So far discussability has not yet been implemented for conflict regulation.

transition generated by the system

notification available for affected user x n := x v

by the user affected’s input by the activator’s or the user affected’s input

support to build up channel

establish channel

do not establish channel

Negotiability If the users affected additionally have the chance to intervene with the activator's decision by technical means we will talk of negotiability (cf. channel abandon Wulf 1995b). In this case the activation of a not xn channel function will only take place if activator and users e x istin g affected have found an agreement. In case of unstructured negotiability there is not any data Figure 7: Discussability available for the technical mechanism to detect the outcome of a conversation between activators and the users affected. To realize the affected user's right of intervention in this case, the negotiation mechanism should be designed in a way that he is the one who provides the result of the conversation to the system (cf. figure 8). In case activator and user affected cannot find a unanimous solution within a certain period of time, strategies for the establishment of a mediation process have to be implemented. Assuming that during the 1

In some cases a communication channel may already exist. We don’t relate to that since it is not a targeted measure for conflict regulation then. -9-



xv

Figure 8: Unstructured Negotiability

negotiation window available for user affected

xv xv

xv

xv time-delay x n := f DT

disagreement x n := f DD

xn xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

fDD, fDT ∈ {f1, ..., fn, f-}

xn

modification x n := {f1, ..,f n }

support to build up channel

agreement x n := x v

xn

xn

xn notification available for activator

establish channel

do not establish channel

f DD/f DT: Disagreement/ Tim e Delay Default transition generated by the system by the user affected’s input by the activator’s or the user affected’s input

abandon channel

xn

channel not e x istin g

application of groupware a third party for mediation will not always be available, the negotiation mechanism has to be configured in advance in a way that it will activate a default option according to the state of the conversation (cf. Wulf 1997a). Figure 8 gives an example how unstructured negotiability could be implemented. After the activation the user affected receives a negotiation window that indicates the activator's choice and allows him to agree, to disagree, or to modify the alternative proposed by the activator. Moreover, he receives technical support to build up an unstructured channel of communication. In case of structured and semi-structured negotiability the speech acts are clearly defined by the structured part of each message. Therefore, it is technically simple to detect the outcome of a negotiation and to realize the right to intervene of the user affected. Herrmann (1995) and Wulf (1995a) have described how structured and semi-structured negotiability can be realized. Figure 9 gives an example how structured negotiability could be implemented. After receiving a negotiation window that displays the alternative chosen by the activator the users affected can either agree, disagree, break off the negotiation, or choose a different alternative. The activator gets a notification about the user affected's decision. In case the user affected has agreed, disagreed or broken off the negotiation the system performs a corresponding state transition. If the user affected has chosen a different act of negotiation (e.g. counterproposal), the activator will be informed about it by a newly created negotiation window. In the following he has about the same options to respond as the user affected had before. Thus, the structured communication process might go through different negotiation loops. In the case of semi-structured negotiability the negotiation scheme presented in figure 9 is still valid. Additionally, the activator and the user affected have the option to add unstructured verbal or textual explanations to each of the different acts for negotiation (cf. Wulf 1997a).

- 10 -



xv negotiation w indow available for user affected

Figure 9: Structured Negotiability xv xv

xv

different act of negotiation x n ∈ {f1 , ..,fn ,f-}

negotiation w indow available for user affected

disagreement x n := f DD

x1

time-delay x n := fDT

xn

x1

xv

negotiation w indow available for activator

agreement x n := x v

break off x n := f DA

xn

xn

xn

x1

x1 x1 different act of negotiation x n ∈ {f1, ..,fn ,f-}

xv

xv

xv

x1

x1

time-delay x n := f DT

disagreement x n := fDD

xn

xn

x1 xn break off x n := fDA

agreement x n := x1

xn

xn

xv xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

x1 ∈ {f1, ..., fn} (help variable) fDD, fDT, fDA ∈ {f1, ..., fn, f } f DD/f DT/f DA : Disagreement/ Tim e Delay/ „Abort“ Default State transition generated by the system

notification available for activator

xn

notification available for user affected

xn

by the user affected’s input by the activator’s input

xn

Negotiability as a conflict resolution mechanism has not yet been widely implemented. Hammer et al. (1993, p. 143) propose to handle conflicts concerning the activation of the forwarding function in inhouse telephone systems by unstructured negotiability. Whenever the activator wants to establish a call forwarding, a telephone line will be built up automatically to the user affected. Via this line they can negotiate, finally the user affected has to confirm the activation. In this case the negotiation process is entirely supported by technical means. The users involved are forced to communicate with each other to find a solution of a potential conflict. In case of disagreement the default option is selected by the user affected – the forwarding function will become active.

- 11 -


Structured Single Loop Negotiability A special case of negotiability is the structured single loop version. In this case communication among users is not technically supported. The user affected just gets a notification on the activator's decision. He can intervene against this decision by technical means expressing a disagreement. Again strategies for mediation have to be put into place to handle cases where a unanimous solution cannot be found within in a certain period of time. Figure 10 gives an example on how structured single-loop negotiability could be implemented.


xv negotiation window a v a ilable for user affected

xv xv

xv xv time delay x n := fDT

disagreement x n := fDD

xn xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

xn

agreement x n := xv

xn

xn fDD, fDT ∈ {f1, ..., fn, f-} Structured single loop negotiability as a notification available means for conflict management has been fDD/fDT: Disagreement/ for activator Time Delay Default proposed for instance in video transition generated xn communication systems. Dourish (1993, by the system pp. 128) presents it as a solution to privacy by the user affected’s input problems. A channel is only built up when the user affected has agreed on it by pushing a button. Similar solutions were Figure 10: Structured Single Loop Negotiability described by Cool et al. (1992) and Belotti and Sellen (1993). This mechanism is already well-known in ordinary telephone systems. A telephone line is just established when the recipient (user affected) has agreed on it by picking up the receiver.

Counter-Controllability The final type of technical mechanisms for conflict regulation is called countercontrollability. In this case the activation of a function is neither made visible to the users affected by technical means nor are they supported to negotiate with the activator via a technical channel of communication. Nevertheless, users affected get technical support to intervene against the activation of a certain function. They are equipped with another function (FC) whose state will be checked whenever the activator will try to activate function F. If the state of the counter-controlling function allows for the intended activation, it will be executed immediately, otherwise the function which was supposed to be activated will take a default state in case of disagreement among the users (cf. figure 11). Thus, contrary to all the other mechanisms proposed so far the users affected decide about their position held in a conflict before the conflict-causing

xv

y

xv activation of countercontrolling function FC

y1 no conflict regulation x n := xv

system default takes x nstatus := f D

xn

xn notification a v a ilable for activator

xn

xv ∈ {f1, f2, ..., fn} xn ∈ {f1, f2, ..., fn, f-}

fD ∈ {f1, ..., fn, f-} f D: Default State transition generated by the system by the user affected’s input

xn

Figure 11: Counter-Controllability - 12 -



function is activated. Counter-controllability as a means to handle conflicts can be found in several CSCW applications, as well. Dourish (1993) has implemented a program within the RAVE video communication that allows users to cut off incoming video calls automatically. The cut off mechanisms can be specified for certain groups of users and periods of time. Malone et al. (1988) have proposed a similar mechanism for e-mail systems to filter incoming mails. In these cases counter-controllability rather contributes to an automatic solution of a conflict than encouraging negotiation. As it prevents the establishment of a channel of communication, a negotiation has to be performed by the help of another communication channel. This strict option of conflict solution was intended by its designer to protect the user affected’s right for privacy and communicative self-determination.

5 Architecture and Implementation of a Conflict Resolution Framework As a result of a scenario-based evaluation study, we found that in general users appreciated the mechanisms presented in the preceding section. They had a positive influence on the regulation of rolebased conflicts (cf. Rohde and Wulf 1996, Rohde 1995, Wulf and Rohde 1996). To evaluate this result more in depth we constructed and realized an architecture that in general can be applied for the implementation of these mechanisms. Additionally, we differentiated some of the assumptions made for the sake of simplicity in the preceding section. Design for Group Decisions In the preceding sections, we assumed that only the interests of an individual user are affected by a function activation. In groupware applications we also find functions which affect more than one user. Sometimes, conflicts resulting from a single activation of a function have to be resolved by a group decision. In case the implemented mechanisms offer visibility of activation to the user affected, notifications have to be made available for a whole group. Voting rules transforming the individual users reaction into a group's decision have to be implemented if technical mechanisms offer a right to intervene to the users affected (cf. Wulf 1995b and 1997a). Most difficult is a group-orientated extension of those technical mechanisms that provide a channel for communication. Technically supported multi-point communication seems to be a reasonable means for conflict regulation in case the group of users affected is small in number. There are also functions that require a differentiation of the role of the user affected because their activation affects different users in different ways (cf. Pfeifer and Wulf 1996). In these cases different technical mechanisms for conflict regulation should be applicable. Thus, more than one conflict constellation has to be regarded. Flexible Management of Conflict Resolution Strategies It is most likely that in groupware systems many functions have a conflict potential. Consequently, the management of the resulting possible conflict constellations of a function (and the resolution strategies assigned) should be as flexible and as easy as possible. Additionally, the choice of a resolution mechanism may depend on the type of object or channel of communication to which the activation of the function refers. This configuration data should be stored centrally to be easily tailorable. It may consist of a matrix containing different dimensions. Its exact layout depends on the possible conflict constellations it refers to and on the specification requirements in the field of application. Design for Unknown User Interests

- 13 -



In the prior sections we assumed that the users whose interests are affected would be explicitly known within the system when the groupware-function will be activated. Given the example of an email forwarding function, on the time of its activation we know who will be affected by getting possibly undesired messages directed to the activator. But we do not know who will be affected by having his message to the activator redirected to another person. Clearly, not every user in the groupware system can be considered as “affected” just because he or she may send an email to the activator. On the other hand we can clearly determine the “send email” function (given the activator of the forwarding function is specified as the recipient of the email) as a point which dynamically defines the sender as “affected”. In general, the activation of one function of an application can be used to implicitly define affected users of another function. An application which allows defining the group of users affected implicitly has to be equipped with an "affected-function" storage. In this storage functions and further specifications are stored whose activation lets the activator become the user Extended affected of another function. Exectution of “Affected Function” Function configuration Store function Taking these considerations into check whether function is account, a generic architecture to activated implement technical mechanisms for conflict Read regulation should contain the Affected elements shown in figure 12. Function Store The design of each function whose activation might cause conflicts should be extended in a Call Conflict way that after activation and Manager before the execution of the conflict-causing state transition Read the technical mechanisms to Configuration regulate potential conflicts can Store Conflict be applied. We call a function Manager that is designed in this way Call "extended function". Within the Conflict Configuration "conflict manager" all the Manager Store different technical mechanisms W rite into of an application will be Affected implemented. The Function "configuration store" contains all Store Write into Store the configuration matrices of a Read from Store function's different conflict Adjust outcome of different Call Conflict Manager constellations. The "affected constellations and provide Arguments function store" contains all the Receive Arguments from data about functions whose Conflict Manager Execute funcactivation leads to conflicts. tion acc. to con.

flict regulation

Thus, whenever a user activates a function the corresponding process will read the "affected Figure 12: Architecture to implement technical mechanisms for conflict regulation function store" to check whether the activator is affected by another function. In case he is affected, the conflict manager will be called providing the necessary parameters which had been stored in the "affected function store". The manager applies the mechanism specified in the transmitted parameters. Holding the role of the user affected of another function, the activator will get involved in regulating the conflict. As a result of the conflict regulation, he should have the chance to cancel the intended activation. For instance, the activator calling someone who has - 14 -



Figure 13: Configuration Window of the LinkWorks workbench forwarded his telephone could get an acoustic notification. As a result of this notification the activator might like to give up his attempt to call. In case he does not cancel the activation of the function, the relevant configuration data for each of the function's conflict constellations have to be read from the configuration store. The conflict manager has to be called for those constellations where the users affected are explicitly known. The functional alternative resulting from the mechanism's application has to be sent back to the original process. In case the users affected are not explicitly known, data has to be written into the "affected function store". If a function contains more than one conflict constellation, the solutions worked out within the different constellations have to be adjusted according to predefined rules. Finally, the resulting functional alternative determined within this process of technically supported conflict regulation will be executed. Application and Programming Environment To evaluate our framework we applied it on a Shared Workspace system in the POLITeam-Project. We now want to discuss the implementation details to demonstrate how the implementation architecture presented in this section has been realized within the POLITeam system. Because the groupware system chosen in POLITeam (LinkWorks by DEC, cf. DEC 1995) supports an object orientated programming language, we decided to also use an object orientated approach to implement the mechanisms for conflictregulation within POLITeam. This approach has the advantage that we have (cf. Graham 1991 p.31 ff., Jacobson 1992: • good correspondence between the objects and the concepts • flexibility for system development • excellent possibilities for software reusability. Figure 13 illustrates a short part of the POLITeam class hierarchy within the configuration window of the LinkWorks workbench. The system provides some default classes, like the Folder or the Envelope classes and allows the designer of POLITeam to create new functionality by adding new classes. Additionally we have the possibility to redefine existent functionality by overriding methods of the default classes. This approach enabled us to modify the system architecture by introducing extended functions that handle the conflicting state transitions within the existent system version (cf. beginning of this section and figure 12). Application scenario - 15 -



The application has been developed for a scenario of shared workspaces ("cabinets" which can be divided into "drawers" and "folders") in the setting described in section 2.2. In that scenario workspaces are established for users currently cooperating, for organizational groups of users and for archiving documents. Shared documents include cooperatively written texts like speeches, forms, information documents like address lists, birthday lists or checklists and reports. Besides the shared workspaces all users have their own private "Virtual Desk". User actions in that setting are creating and deleting documents, beginning and ending the sharing of a document, searching for a document and reading and modifying it. Access restrictions are useful e.g. for address lists which should only be deleted if no one uses them anymore, for reports containing information which is to be revealed only to the head and certain members of the section, for unfinished documents or for checklists, which should be modified only under the eyes of the section’s heads secretary. Designing for Negotiation Support According to the architecture model, the extended function has to check at first whether another function affects the activator. Looking at the functions described in the scenario it turns out that the users affected were already explicitly known at the moment of activation. Therefore, we did not implement an affected function store. The extended functions check directly whether the intended activation of the function may lead to a conflict by comparing the current working situation with a description of the conflict constellation defined in the configuration store. As already mentioned the dimensions of the matrix describing the different conflict constellations of a function have to be specified empirically by looking at the user requirements in the different fields of application. Therefore, we carried out ten interviews with users in three fields of applications to specify the dimensions of the configuration matrix of the "delete", "search" and "share" functions (cf. scenario and section 2.2). The following dimensions turned out to be relevant to describe those conflict constellations (cf. Stiemerling 1996): • Users (by name, unique identifier) • Groups (organizationally and arbitrary) • Roles (can technically be treated as groups, i.e. aggregations over the set of users) • Objects (by name, unique identifier) • Space-metaphors (e.g. Oliver's desk, our shared cabinet etc.) • Object classes (text documents, spreadsheets etc.) • Object attributes (e.g. signed by) • Relationships between objects and users (owner, current user on a workflow, future user on a workflow etc.) • recurrent time (e.g. from Monday to Friday, from 10:00 to 12:00, from January to July) • absolute time (e.g. from 7-10-94 to 8-5-95) Because of the great number of dimensions for the description of the conflict constellations in our application fields, the configuration matrix turned out to be too complex to be directly handled by the users. Therefore, we developed a rule-based approach to support the users to define which mechanism they prefer to regulate a certain conflict constellation by creating rules like: If the user Oliver activates the delete-function on the weekly report, than he has to negotiate with all members of the group. Figure 14 shows the screen used to create and edit rules by selecting the relevant dimensions in the tabbed folder. The plain text on the bottom of the screen is updated whenever the user changes the formal definition of the rule above. Thus, the user is provided with instant feedback in natural language about his actions. A first empirical evaluation by means of the thinking aloud method indicated that rules are a viable way to support users in handling the complexity of the configuration (cf. Stiemerling 1996). The "Configuration" - button in figure 14 allows the users to determine the specific conflict regulation mechanism. According to the users’ requirements the following mechanisms for conflict resolution have been implemented so far within the POLITeam system (cf. figure 4): • Counter-Controllability - 16 -



• Visibility of activation and • different variations of negotiability Counter-Controllability was implemented directly by means of the rule based approach. Instead of implementing the counter-controllability function separately the users affected can predefine their agreement or disagreement concerning the activation of a function by applying the same rule editor (cf. figure 14). To support visibility of activation as well as different variants of negotiation the configuration store within the POLITeamsystem provides special conflict regulation objects. An object of the class Visibility_of_activation (cf. ‘Transparenz’-object in figure 13) consists mainly of a notification string with the Figure 14: Rule Editor for defining configuration store textual description of the conflicting situation (e.g. user x has activated function y on object z). Additionally we need the list of affected users and an application specific start-method, which supplies the affected user with the notification. Different Visibility_of_activation classes can provide different notification methods (e.g. per Email or as text window) by overriding (c.f. Graham 1991, Jacobson 1992, Firesmith and Eykholt 1995 p. 316) the startmethod to the specific needs. The prototype used within the POLITeam-system creates a special notification object, which is sent to the affected users. In contrast to the class Visibility_of_activation the negotiability class is much more complex: Each negotiation object in POLITeam has the following attributes: • the name of the activated function • the activator of the function • the users affected from the activation • a voting rate (as percentage value), when more than one user is affected • the yes votes • the number of given votes and • a result value, which represents the result of the negotiation Furthermore, a start-method will be provided by the negotiation class that determines the conflict regulation strategy of the specific class. The start method is responsible for the whole negotiation handling. It provides the communication channels and coordinates the evaluation of the negotiation process. To select the different variants of negotiability we have implemented the Figure 15: Configuration window for specifying a following configuration window. It negotiability variant - 17 -



shows up within the configuration dialogue presented in figure 14 when the users choose negotiability as a mechanism for conflict regulation. Within the POLITeam-system we have implemented a structured and a semi-structured variant of negotiability, which also support negotiations with more than one user (cf. Figure 15). Furthermore, we distinguish synchronous and asynchronous negotiations. The last differentiation became necessary because in our application field many users work at different places, not always at the same time. Within the prototype, we have decided to choose synchronous structured single loop negotiability (cf. figure 10) as predefined negotiation-strategy in order to regulate conflicts as quickly as possible. The start-method of this Negotiation class pops up a negotiation window at the workstation of the affected user. The window contains a short description of the conflicting situation by stating which user has activated a Figure 16: Window received by the user affected in case of semi-structured negotiation specific function on a working-object (e.g. a text) and asks the user if he agrees to the activation or not. The structured variant of negotiability can be extended to a semi-structured variant, where the activator can explain his activation by means of an additional text-field. Semi-structured negotiation is a subclass of the negotiation class with an additional attribute. Taking the example of the "delete"-function, the start-method of this class opens the negotiation-window shown in figure 16 at the desktop of the affected user. Synchronous and asynchronous variants of negotiability take a different intermediate state after the function's activation (cf. figure 3). In case of synchronous negotiability, the object to which the activation refers is locked during the whole negotiation process. To avoid situations where long-lasting objectlocking hinders ongoing work with the system, the conflict management tool cancels the negotiation after a predefined period of time (without response) and asks the activator of the function whether he wants to start an asynchronous negotiation. If he agrees, the asynchronous negotiation will be initiated and the activated method will not be executed. This represents the default-alternative for time delay regarded to be sensible in our field of application. Moreover, asynchronous negotiation is executed either if the users have defined it in the configuration store, or as predefined variant of negotiability if more than one of the users is affected by the activation a conflicting function. This decision has been made to avoid long-term object locks, which are likely to the result from a multi-party voting process. In case of asynchronous negotiability the system proceeds within the intermediate state as follows. The conflict manager returns a value to the extended function (cf. figure 12) which indicates that the negotiation is asynchronous. In these cases the extended function executes a predefined state transition which finishes object locking but sets a flag at the object to which the activation refers. This flag indicates that the function’s execution for Figure17: Mail inbox for conflict management this object is under negotiation. Moreover, a - 18 -



persistent negotiation object is created, storing among other things the activated alternative, the affected object, the name of the activator and the voting mode. The conflict manager stores the negotiation object and sends a ballot object indicating a specific conflicting situation to all affected users. Contrary to the case of synchronous negotiability the ballot is not displayed directly at the screen of the users affected. To receive these ballots and the notifications in case of "visibility of activation", we have designed a specific mail inbox for conflict regulation on every users’desktop (cf. figure 17). Every user affected who receives a negotiation ballot can launch it by double clicking on the ballot's icon. Doing this, the negotiation window will be displayed (cf. figure 16) and the user can decide whether to agree or disagree to the intended activation of the conflicting function. His response will be sent to the conflict-manager, which increases the number of given votes for the related negotiation object and in the case of agreement also the number of yes votes. If the voting rate has been reached, leading either to an agreement or to a disagreement, the flag of the negotiation object changes accordingly. Moreover a specially designed decision object (cf. figure 17) will be sent to the activator of the conflicting function notifying him about the decision and in case of agreement asking him whether he wants to execute the negotiated functional alternative. The visibility object in figure 17 contains the message that an activation of a function has been proceeded, where visibility of activation has been set as conflict regulation mechanism. The mail inbox can also be displayed as an object list on the window. This enables the user to display more information about the objects than just their name, and to organize them in different orders. Furthermore, this display mode enables the user to get a quick overview on the ongoing conflict regulation activities and allows him to react to specific inquiries of other users.

6 Discussion This section presents results of an evaluation of the prototype described before. We gathered feedback by presenting the prototype in a workshop to users from a federal ministry. To present the prototype, we developed a scenario that was based on workplace studies carried out before in that ministry (cf. Mambrey and Robinson 1997) as well as on earlier findings concerning groupware specific conflicts (cf. section 2.2). Tailoring access rights with rules The scenario presented a new way to carry out tasks well known to the users. It dealt mainly with the preparation of a speech for the minister. A member of the section has to write a first version of the speech. Therefore, she uses the search-tool to look for existing speeches in the system. Moreover, she looks for a mailing list that turns out to be outdated. Therefore, she activates the delete function that creates a semi-structured negotiation with the other members of the section. Having finished the speech and got an approval, she leaves for holidays. Applying the rule editor, she allows her deputy to access certain folders on her desk under the condition of visibility of activation. During her holidays it turns out to be necessary that her deputy enter the document to carry out some modifications. On her return she finds a corresponding message in her meta mailbox. This scenario led to vivid discussions among the users participating in the workshop. Here we will focus on the aspects most relevant to the design of mechanisms to regulate conflicts in groupware. We will first focus on the design of the rule editor and the conflict manager before discussing the design of the extended functions. Having seen the rule editor, the head of the section stated that such a far-reaching individualization of a system would lead to problems in the unit's cooperation. He stated that there is a clear need for standardization. Moreover, the rule editor seemed to him too complex to use. For both of these reasons, he assumed that the rule editor is rather a tool for system administrators than for ordinary users. The head of the ministry's IT-department got interested in the strategy to deal with inconsistent rules in the rule base. While the general approach gives priority to the most specific rules he argued that certain general rules set by the system administrators should be given top priority. This is important to him because such general rules may implement organization wide standards or agreements between

- 19 -



worker's representatives and the management on how to deal with personal data. The prototype was designed in a way that it could cope with this demand (cf. Stiemerling and Cremers 1998). Concerning the meta mailbox, the head of the section noted that he does not want a second mail box. He found it to confusing using two mailboxes. Therefore, he wanted to receive the notifications together with his other mails. Searching Documents The search tool presented in the workshop was not equipped with technical mechanisms to regulate conflicts in groupware. Nevertheless, the results of an inquiry were presented in three different windows according to the location where the documents were found - own desktop, colleague's desktop, or registrar (cf. Kahler 1996). We used this design to discuss groupware-specific conflicts related to the different locations and possible design approaches. Starting from the case presented in the scenario the head of the IT department expressed his worries that employees whose speeches would be copied could feel uneasy about it and claim to the worker's representatives. Though he acknowledged clear benefits from being able to access speeches written by colleagues, he argued for a solution that respects other users' privacy and copyright. One of the employees working already in Berlin expressed strong interest in being able to search for press announcements covering certain topics. These documents are hardly available in Berlin yet. Contrary to this one of the members of the section clearly stated that she does not want anybody being able to search on her private desktop. She felt uncomfortable whether somebody could find electronic documents which are private or still in work progress. The head of her section supported her point of view. However, one of the typists who is responsible to search for documents in case the owner of a document is absent opposed this attitude strongly. As users forget to locate important documents in the folder shared with her, she often can not find these documents. Thus, she pleaded for unlimited access to other users' desktop, at least in case of an urgent demand. The discussion reveals that searching outside of a user's own desktop can lead to severe conflicts. Most of the users asked for counter-controllability to be able to create private domains where other users' access via the search-tool would be impossible. These mechanisms were already integrated in the system deployed in this field of application. Nevertheless, this approach led to problems. To overcome the rigidity immanent to this approach, one of the typists has the right to access all shared folders of a section. Thus, if one of the members of the section needs to access a certain document, he will go to the typist and ask her to find it for him. This practice makes access to other users' documents visible at least to this typist. We assume that in some of the cases the mechanism visibility of activation could be applied as an alternative to the rigid mode of access control used so far. Having made this suggestion on the workshop, the head of the section pointed out the problem of information overload. Thus, such an approach seems to be only viable in case the relevant documents are accessed infrequently. Deletion of Shared Information The actual problem was the deletion of address lists, which were often established for special, timelimited purposes, and were shared among several users. Users often forgot to delete address lists, and some months later nobody would know exactly, what a list has been created for and whether someone (Who?) is still using it. Our suggestion to involve the whole section by means of single loop negotiability (cf. Section 3) when deleting address lists from a shared folder led to vivid discussions. In the beginning of the discussion the head of the section was of the opinion that there is no need for such a tool. The registrar should be responsible for document deletions. A democratic procedure seemed to him difficult to implement since one never knows whether the people would respond. By contrary, the head of the typists who is involved in the registrar work turned the

- 20 -



responsibility back to the section. In her eyes the registrar needs clear orders by the individual members of the section how to handle documents: “Nevertheless address lists cannot be handled in this way because they are used by groups. If we have the feeling that they are no more useful, we ask. I have already a huge amount of such documents and nobody really decides to delete them. Thus, I think we really have to involve the whole section.” The head of the section contradicted by arguing that for each document there should be somebody responsible to decide on its handling. Due to a suggestion of one of the designers from POLITeam project, alternatives were discussed. An employee of the registrar marks all the outdated address lists visibly. If the other users see this mark they can add their mark. An address list would be deleted if all the section members had marked it. This solution was abandoned because users typically do not check all the lists. Another suggestion to remove all documents which have not been modified for a certain period of time was also given up because the date of last editing was not perceived as a sufficient indication for a documents’ necessity. Therefore, the users finally agreed on an approach that would apply semistructured negotiability to inform all members of the group about the activation of the delete function. Only in case the recipients either agree or do not react within a week the delete function will be executed. In an earlier workshop the users had opted for a similar approach having seen the prototype (cf. Wulf, 1997b, pp.488). Concerning the design of the negotiation window they asked for an option to be able to directly access the document under negotiation. Meta Conflicts In general, the question occurred, how we can deal with meta conflicts; e.g. when the request to establish a communication channel itself has to be considered as a possible cause for conflict. It may endanger the privacy of the one activating the conflict resolution or it may annoy persons with repeated requests for establishing communication channels. We believe that all the conflict resolution strategies described could be applied to meta conflicts, too. But we think it is more feasible to decide upon possible meta conflicts at configuration time by choosing the appropriate conflict resolution strategy. Limitations and Directions of further Work The final presentation of the prototype in a workshop with users from the POLITeam project led to ambivalent reactions. The discussion concerning the deletion of address lists revealed a clear potential for one of the mechanism developed in this paper. Accessing an absentee's document indicated another possibility to apply one of the mechanisms. Looking at the feedback from the users the following factors seem to be indispensable for the application the mechanisms: • Appropriate understanding of the functions leading to conflict: In the case presented the meaning of the functions discussed did not pose a considerable problem. As the participants of the workshop used the corresponding functions frequently in their daily work they had a rather good understanding of their meaning. Nevertheless, dealing with less qualified users or less frequently used functions may lead to different findings. • Context-dependent mode of conflict resolution: Those of the mechanisms which involve the users actively in the conflict regulation seem to be only useful in case there is not an anticipated mode to resolve the groupware-specific conflicts. For instance, it would not make sense to apply one of the negotiation mechanisms to handle access to all of the documents of a private desktop because it is clear that access will be generally denied. • Limited frequency of message sending: Mechanisms involving user activity should consider that perceiving visibility or taking part in negotiating disturbs users in carrying out their actual task. Therefore, the application of these mechanisms should be restricted to important cases of groupwarespecific conflicts. In our field of application, the deletion of address lists seems to be such a case.

- 21 -



Accessing documents while the owner is away, seems to be another. In case of the search function, visibility seems to be an important feature. Nevertheless, there should be an appropriate presentation at the interface of the users affected to ease its perception (e.g. only one message indicating all the objects found). • Discursive conflict resolution culture: The organizational culture in the fields of application should allow the users involved to influence the resolution of a conflict. If hierarchy or power differences will not allow users affected to influence the conflict resolution there is not much space for the mechanisms presented. In the section of federal ministry taking part in the workshop, there was a climate of discursive conflict resolution. Though the head of the section was hierarchically superior to the other members of his section, he would not dominate discussion and insist on his position when deciding on the design of the groupware.

7 Conclusion We have proposed a classification scheme for technical mechanisms that support users in regulating conflicts concerning the activation of certain groupware functions. Moreover, we have presented an architecture to implement these mechanisms. Discussions with users in workshops showed that the technical mechanisms presented in this paper are a useful means in regulating conflicts between users. Therefore, we have implemented our concepts in a first prototype, which modifies an existing groupware product accordingly. Recognizing that users work asynchronously and avoiding unnecessary interruptions we specified the concept of negotiability further. Moreover, we developed a rule-based approach to support users in specifying the complex configuration matrices. As a next step, the prototype has to be tested by the users. We have to find out how the users judge the way the mechanisms are implemented, which mode of negotiability will be preferred by them and how they are able to handle the rule-based mode of configuration. The prototypical implementation of additional mechanisms will affect the performance of applications. Therefore, further research towards an efficient implementation is needed. Looking at the implementation architecture for technical mechanisms of conflict regulation, it resembles the one of access control. Indeed, approaches to implement access rights in groupware include more than just reading and writing permissions. They allow to specify access rights concerning a wide variety of functions (cf. Shen and Dewan 1992, Sikkel 1997). To realize access control, one has to extend the code of each function in a similar manner as we have proposed (cf. Pfeifer and Stiemerling 1997). Access control lists used in these approaches can be seen as configuration data for conflict regulation. Nevertheless, compared to the approach proposed in this paper, access control in groupware has so far just included counter-controllability as a technical mechanism for conflict regulation. Thus, our paper offers concepts to extend existing approaches to access rights in groupware, which give users more than just a single technical mechanism for conflict regulation.

8 Acknowledgements We would like to thank Markus Rohde for valuable discussions on the topics addressed in this paper. Oliver Stiemerling and Dirk Fischer have implemented the prototype presented in section 5. This research has been supported by the German Ministry of Education and Research within its "Polikom" research program under the grant No. 01 QA 405/0.

9 References (Translations of German titles made by the authors) Bahler, D.; Dupont, C.; Bowen, J. Mediating Conflict in Concurrent Engineering with a protocol based on Utility. In: Concurrent Engineering - Research and Application, Vol. 2, No 3, 1994, S. 197 - 207

- 22 -



Belotti, V.; Sellen, A. Design for Privacy in Ubiquitous Computing Environment, in: de Michelis, G.; Simone, C.; Schmidt, K. (eds.): Proceedings of the Fourth Conference on Computer Supported Cooperative Work - ECSCW '93, Kluwer, Dordrecht, 1995, pp. 77 - 92 Condon, C.: The Computer Won't let me: Cooperation, Conflict and the Ownership of Information, in: Easterbrook, S. (ed.) CSCW: Cooperation or Conflict, Springer, London u. a. 1993, pp. 171 - 185 Cool, C.; Fish, R.S.; Kraut, R.E.; Lowery, C.M.: Interactive Design of Video Communication Systems, in: CSCW '92. Sharing Perspectives. Proceedings of the Conference on Computer-Supported Cooperative Work, (ACM Press, New York) 1992, pp. 25 -32 Dahrendorf, R.: Elemente einer Theorie sozialen Konflikts ("Elements of a theory on social conflicts"), in: Dahrendorf, R. (ed.): Gesellschaft und Freiheit ("Society and Liberty"), München 1961, pp. 197 - 236 DEC : LinkWorks Version 3.0, Class Programming Guide, Digital Equipment B.V., Apeldoorn, Netherlands, 1995 Dourish, P.: Culture and Control in a Media Space, in: de Michelis, G.; Simone. C.; Schmidt, K. (eds.): Proceedings of the Third Conference on Computer Supported Cooperative Work - ECSCW '93, Dordrecht, NL, Kluwer 1993, pp. 125 - 138 Easterbrook, S. M.; Beck E. E.; Goodet, J. S.; Plowman, L.; Shaples, M.; Wood, C. C.: A Survey of Empirical Studies of Conflict, in: Easterbrook, S. (ed.) CSCW: Cooperation or Conflict, Springer, London et al. 1993, pp. 1 - 68 Egger, E.; Wagner, I.: Time Management: A Case for CSCW, in: CSCW '92. Sharing Perspectives. Proceedings of the Conference on Computer-Supported Cooperative Work, ACM-Press, New York 1992, pp. 249 - 256 Firesmith, D.G.; Eykholt, E.M.: Dictionary of Object technology. The Definitive Desk Reference, SIGS Books, New York, 1995. Gaver, W.: Sound Support for Collaboration; in: L. Bannon, M. Robinson; K. Schmidt, (eds.): Proceedings of the Second European Conference on Computer Supported Cooperative Work, Amsterdam, 1991, pp. 273 - 307. Genrich, H. J.; Lauterbach, K.: System Modelling with High-Level Petri Nets, in: Theoretical Computer Science, Vol. 13, 1981, pp. 109 - 136 Glasl, F.: Konfliktmanagement ("Conflict Management"), 3rd ed., Bern 1992 Greenberg, S.: Personizable Groupware: Accommodating individual roles and group differences, in: L. Bannon; M. Robinson; K. Schmidt (eds.): Proceedings of the Second European Conference on Computer Supported Cooperative Work, Amsterdam, 1991, pp. 17 -31 Greif, I. and Sarin, S: Data sharing in group work, in: Proceedings of the First Conference on ComputerSupported Cooperative Work, ACM Press, New York 1986, pp. 175-183 Graham, I.: Object Oriented Methods. Addison Wesley 1991. Hammer, V.; Pordesch, U.; Roßnagel, A.: Rechtliche Gestaltungsanforderungen an betriebliche ISDNTelefonsysteme ("Legal Design Requirements for Business ISDN Telephone Systems"), Berlin Heidelberg, Springer, 1993 Henderson, A.; Kyng, M.: There's No Place Like Home: Continuing Design in Use; in: J. Greenbaum; M. Kyng (eds.): Design at Work - Cooperative Design of Computer Artefacts, Hillsdale, 1991, pp. 219 - 240. Herrmann, T.: Grenzen der Softwareergonomie bei betrieblichen ISDN-Anlagen ("Restrictions for Software Ergonomics for Business ISDN Systems"). In: Valk, R. (ed.): Proceedings der GI-18. Jahrestagung, Springer, Berlin u.a. 1988, S. 521 - 532

- 23 -



Herrmann, T.: Workflow Management Systems: Ensuring Organizational Flexibility by Possibilities of Adaptation and Negotiation, in: Proceedings of COOCS, August 13 - 16, 1995, Milpitas, CA, ACMPress, New York 1995, pp. 83 - 96. Höller, H.: Kommunikationssysteme - Normung und soziale Akzeptanz ("Communication Systems Standardization and Social Acceptance"), Braunschweig u.a. 1993 Jacobson, I.: Object-Oriented Software Engineering. A Use Case Driven Approach. Addison Wesley 1992. Jensen, K.: Coloured Petri Nets and the Invariant-Method. In: Theoretical Computer Science, Vol. 14, 1981, pp. 317 - 336 Jensen, K.: Coloured Petri Nets. In: Brauer, W.; Reisig, W.; Rozenberg, G.: Petri Nets: Central Models and Their Properties, Lecture Notes in Computer Science, No. 254, Springer, Heidelberg u.a. 1987, pp. 248 - 299 Kahler, H.: Von der Empirie zur Gestaltungsanforderung - Beispiele für den Einfluß explorativer Empirie auf die Entwicklung von Gestaltungsanforderungen für Groupware ("From Empirical Studies to Design Requirements - Examples for the Influence of Explorative Empirical Studies on the Development of Design Requirements for Groupware"), in: Hartmann, A.; Herrmann, Th.; Rohde, M.; Wulf, V. (eds.): Menschengerechte Groupware - Software-ergonomische Gestaltung und partizipative Umsetzung ("Human-oriented Groupware - Software-Ergonomical Design and Participative Realisation"), Stuttgart, Teubner 1994, pp. 109-124 Klöckner, K.; Mambrey, P.; Sohlenkamp, M.; Prinz, W.; Fuchs, L. Kolvenbach, S.; Pankoke-Babatz, U.; Syri, A.: POLITeam – Bridging the Gap between Bonn and Berlin for and with the Users, in: H. Marmolin; Y. Sundblad; K. Schmidt (eds.): Proceedings of the Second European Conference on Computer Supported Cooperative Work, Kluwer, Dordrecht, 1995, pp. 17 - 32 Mambrey, P.; Robinson, M.: Understanding the Role of Documents in a Hierarchical Flow of Work. In: Hayne, S. C.; Prinz, W. (eds.): The Integration Challenge – Group `97. Proceedings of the International ACM SIGGROUP Conference on Supporting Group Work. Nov. 16-19, Phoenix, Arizona, ACM New York, NY 1997, pp. 119-127 Malone, T. W.; Grant K. R.; Lai, K.-Y.; Rao, R.; Rosenblitt, D.: Semistructured Messages are Surprisingly Useful for Computer-Supported Coordination, in: I. Greif (ed.): CSCW: A Book of Readings, Morgan-Kaufmann Publisher, San Mateo, California, 1988, 311-334. Mark, W.; Dukes-Schlossberger, J.: Cosmos: A System for supporting Engineering Negotiations. In: Concurrent Engineering - Research and Application, Vol. 2, Nr. 3, 1994, S. 173 - 182 Murnighan, K. J.; Conlon, D. E.: The Dynamics of Intense Work Groups: A Study of British String Quartets, in: Administrative Science Quarterly, Vol. 36, 1991, pp. 165 - 186 Narayanaswamy, K.; Goldman, Neil: "Lazy" Consistency: A Basis for Cooperative Software Development. In: CSCW '92. Sharing Perspectives. Proceedings of the Conference on ComputerSupported Cooperative Work, New York 1992, S. 257 - 264 Pfeifer, A.; Wulf, V.: Aushandelbarkeit als Konfliktlösungsstrategie in gemeinsam genutzten Datenbanken ("Negotiability as Conflict Resolution Strategy in Shared Databases"). In: Broedner, Peter; Paul, Hansjuergen; Hamburg, Ileana (eds.): Kooperative Konstruktion und Entwicklung - die Zukunft von CAD-Systemen ("Cooperative Construction and Development - The Future of CAD Systems"). Muenchen: Rainer Hampp Verlag, 1996, pp. 215 - 239 Pfeifer, A.; Stiemerling O.: Konfiguration des Informationsdienstes in Groupware ("Configuration of an Information Service in Groupware"). Proceedings of the 3. Internationale Tagung Wirtschaftsinformatik, 26.-28. Feb., Berlin, Germany 1997.

- 24 -



Pipek, V.; Wulf, V.: A Groupware's Life, in: Kyng, M.; Bødker, S.; Schmidt, K.: Proceedings of European Conference on Computer Supported Cooperative Work (ECSCW'99), Kluwer, Dordrecht, Netherlands, 1999, pp. 199-218 Rohde, M.: The Scenarionnaire - Empirical Evaluation of Software-ergonomical Requirements for Groupware, in: Anzai, Y.; Ogawa, K.; Mori, H. (eds.): Symbiosis of Human and Artefact - Future Computing and Design for Human-Computer Interaction, Elsevier, Amsterdam 1995, pp. 333 - 339 Rohde, M.; Wulf, V.: An Early Evaluation of Technical Mechanisms Supporting Negotiations in Groupware; in: Proceedings of the Second International Conference on the Design of Cooperative Systems (COOP´96), 12. - 14.6.1996 in Juan les Pins, INRIA, Sophia Antipolis 1996, pp. 281 - 297 Roßnagel, A.: Vom informationellen zum kommunikativen Selbstbestimmungsrecht ("From the Informational to the Communicational Right of Self-Determination"). In: Kubicek, H. (ed.): Telekommunikation und Gesellschaft ("Telecommunication and Society"), Karlsruhe 1991, S. 86 - 111. Schmidt, K. : Riding a Tiger or Computer Supported Cooperative Work, in: L. Ban-non, M. Robinson; K. Schmidt, (eds.): Proceedings of the Second European Conference on Computer Supported Cooperative Work, Amsterdam, 1991, pp. 1 - 16 Shen, HH. and Dewan, P.: Access Control for Collaborative Environments, in: Computer-Supported Cooperative Work ´92. Sharing Perspectives. Proceedings of the Conference on Computer-Supported Cooperative Work, ACM Press, New York, pp. 51 - 58. Sikkel, K.: A Group-based Authorisation Model for Cooperative Systems, in: Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, Lancaster, 1997 (to appear) Sohlenkamp, M.; Fuchs, L.; Klöckner, K.; Kolvenbach, S.; Mambrey, P.; Pankoke-Babatz, U.; .; Prinz, W.; Syri, A.: Supporting the Distributed German Government with POLITeam, in: International Journal on Multimedia Tools and Applications - Special Issue on Multimedia Projects in Governments, 1997 (to appear) Stiemerling, O.: Anpaßbarkeit in Groupware - ein regelbasierter Ansatz ("Tailorability in Groupware - a rule-based approach"), in: Master Thesis, University Bonn, 1996 Stiemerling, O.; Cremers, A. B.: Tailorable Component Architectures for CSCW-Systems, in: Proceedings of the 6th Euromicro Workshop on Parallel and Distributed Programming, Jan 21-24, 1998, Madrid, Spain, IEEE Press, pp. 302-308 Stiemerling, O.; Kahler, H.; Wulf, V.: How to Make Software Softer - Designing Tailorable Applications, in: Proceedings of the DIS (Designing Interactive Systems) '97 , 17.-20.8.1997, Amsterdam, ACM Press 1997 , pp. 365-376. Trigg, R. H.; Moran, T. P. and Halasz, F. G.: Adaptability and tailorability in Note Cards, in: Bullinger, H.J., Shackel, B. (eds.): Human-Computer Interaction - INTERACT '87, Elsevier, Amsterdam, 1987, pp. 723 - 728. Winograd, T.: A Language/Action Perspective on the Design of Cooperative Work, in: I. Greif (ed.): CSCW: A Book of Readings, Morgan-Kaufmann Publisher, San Mateo, California, 1988, pp. 311 - 334. Wulf, V.: Negotiability: A Metafunction to Tailor Access to Data in Groupware; in: Behavior & Information Technology, Vol. 14, No. 3, 1995b, pp. 143 - 151 Wulf, V.: Mechanisms for Conflict Management in Groupware. In: Anzai, Y.; Ogawa, K.; Mori, H. (eds.): Symbiosis of Human and Artefact - Future Computing and Design for Human-Computer Interaction, Elsevier, Amsterdam 1995a, pp. 379 - 385 Wulf, V.: On Conflicts and Negotiation in Multi-User Applications; in: Kent, A.; Williams, J. G. (eds.): Encyclopaedia of Microcomputers, Dekker, New York et al., 1997

- 25 -



Wulf, V.: Konfliktmanagement bei Groupware ("Conflict Management in Groupware"), Vieweg, Braunschweig, 1997a Wulf, V.: Handling Conflicts in Groupware: Concepts and Experiences made in the POLITeam-Project, in: Howard, S.; Hammond, J.; Lindgaard, G. (eds.): Human Computer Interaction: INTERACT 97, Chapman & Hall, 1997b Wulf, V.; Hartmann, A.: The Ambivalence of Network's Visibility in an Organizational Context. In: Clement, A.; Kolm, P.; Wagner, I. (eds.): NetWORKing: Connecting Workers in and between Organisations, North Holland, Amsterdam 1994, S. 143 - 152 Wulf, V.; Pordesch, U.: Datenschutzprobleme bei computer-integrierter Telefonie ("Problems of Privacy in Computer-Integrated Telephony"). In: Datenschutz und Datensicherheit 8/1993, S. 438 - 446 Wulf, V; Rohde, M: Reducing Conflicts in Groupware - Metafunctions and their Empirical Evaluation; in: Behavior & Information Technology, Vol. 15, No. 6, 1996, pp. 339 - 351

- 26 -

Resolving Function-based Conflicts in Groupware Systems - CiteSeerX

Resolving Function-based Conflicts in Groupware Systems - CiteSeerX

Suggest Documents

Reducing Conflicts in Groupware - CiteSeerX

RESOLVING DISTRIBUTIONAL CONFLICTS BETWEEN ... - CiteSeerX

RESOLVING DISTRIBUTIONAL CONFLICTS ...

Resolving Requirements Conflicts with Computer ... - CiteSeerX

Detecting and Resolving Packet Filter Conflicts - CiteSeerX

Reducing Conflicts in Groupware - Semantic Scholar

Resolving File Conflicts in the Ficus File System - CiteSeerX

RESOLVING CONFLICTS IN TASK DEMANDS DURING ... - TSpace

Resolving industrial plantation conflicts in Indonesia_ ...

RESOLVING CONFLICTS IN TASK DEMANDS DURING BALANCE ...

Resolving Conflicts in Ed_print version

Resolving apparent conflicts between oceanographic and ... - Qc.edu

Detecting and Resolving Packet Filter Conflicts

Resolving conflicts over transboundary watercourses: an Indian ...

41. Towards Resolving Raptor-Human Conflicts - JNCC

A Metadata Approach to Resolving Semantic Conflicts

Reinventing Democratic Diplomacy for Resolving Intractable Conflicts ...

Anticipating and Resolving Conflicts During ... - Semantic Scholar

Resolving Conflicts Between Recreation and ...

Synchronizations in Team Automata for Groupware Systems

resolving conflicts of jurisdiction in criminal proceedings: interpreting ...

Page 1 Resolving Wildlife Conflicts Wildlife conflict resolution in ...

Resolving Structural Conflicts in the Integration of ... - NUS Computing

Resolving Resource Conflicts in a Ship Repair Project - International ...