Focus+Roles: Socio-Organizational Conflict Resolution in Collaborative User Interfaces Davy Vanacken, Chris Raymaekers, Kris Luyten, and Karin Coninx Hasselt University, Expertise Centre for Digital Media and transnationale Universiteit Limburg, Wetenschapspark 2, 3590 Diepenbeek, Belgium {davy.vanacken, chris.raymaekers, kris.luyten, karin.coninx}@uhasselt.be

Abstract. Collaborative workspaces are in dire need of elegant floor control policies, resolving and preventing conflicts without interrupting the dynamic workflow. Our approach employs the user’s roles and focus to extend existing solutions. Roles define a user’s responsibilities and privileges during a particular activity; tracking the users’ focus provides a means of improving mutual awareness within a multi-user setting. Furthermore, in combination with document properties such as content type and sensitivity, roles make up an effective access control system. We apply the approach to a co-located group of users, interacting simultaneously on a collaborative shared display, which results in graceful (e.g. correct in a socio-organizational context) conflict handling and access to shared data. Keywords: computer-supported cooperative work, multi-user interfaces, collaboration, floor control, access control.

1 Introduction and Related Work Along with the numerous advantages of supporting and enhancing group productivity, CSCW applications introduce various challenges. In particular, allowing multiple people, either co-located or remote, to interact with a shared workspace simultaneously, gives rise to uncertainty and unpredictability, bringing about several types of conflicts. Consequentially, to fully exploit the countless advantages, CSCW applications call for some interaction management. Providing concurrent, multi-user interaction allows users to focus on the task at hand, while taking full advantage of group dynamics and different interaction styles [8]. However, a very common type of conflict is caused by several people trying to manipulate a shared resource at the same time. If no synchronization mechanism is in place, the system may end up in an inconsistent state. Therefore, various strategies can be employed: execute the activities sequentially, try to merge both actions, or only allow one of the users to manipulate the object at the same time, among others. In such circumstances, a floor control policy determines how conflicts are prevented or resolved [3]. An intuitive approach is to assume that “social protocols” (such as polite behaviour and social standards) are adequately observed and suffice to coordinate the actions of J. Jacko (Ed.): Human-Computer Interaction, Part IV, HCII 2007, LNCS 4553, pp. 788–796, 2007. © Springer-Verlag Berlin Heidelberg 2007

Focus+Roles: Socio-Organizational Conflict Resolution

789

a collaborating group of users. Even though social protocols perform well in some cases, they cannot prevent or resolve numerous types of conflicts which may lead to an inconsistent system state. Users often fail to realize the side-effects of their actions, or become utterly confused when other partakers in a collaborative session operate on a shared resource simultaneously [5]. In the Dynamo system [6], which relies largely on social protocols, users reported inconveniences with overlapping interaction, such as one user closing a document belonging to someone else. Moreover, the high degree of freedom concerned users, seeing as it may easily lead to malpractices, such as stealing other people’s work without consent. The Kansas system [9] augments social protocols by considering roles, in an attempt to improve usability. A user’s role determines the amount of visual output offered to the user and limits the user’s input capabilities. Although this method is capable of preventing quite a few types of conflicts, users still have to resort to informal verbal communication to regulate collaborative activities such as note taking. In addition, while conducting tests, problems arose from unintentional user actions, some of which had consequences that were hard to undo. Coordination policies reaching beyond social protocol and employing direct manipulation mechanisms to avoid and resolve conflicts can vastly improve multi-user interfaces [7]. Solutions include the use of rank to factor in differences in privilege among users, or privatising strategies to restrict a user’s access to a subset of documents. While one such policy may suffice in a constrained environment, sophisticated surroundings have need of a more extensive strategy. A different class of policies is described in terms of access control rights on objects, assigned to groups of users. Role-based access control (RBAC) [10] simplifies authorization management, based on the various job functions in an organization. Organizational roles are fairly static; transitory roles, which can alter dynamically throughout a collaborative happening, are not supported. Intermezzo was successfully extended with both static and dynamic roles [4]. Unfortunately, the rather complex specification language makes it difficult to add new policies or roles. To effectively provide both conflict handling and access control in a wide-ranging environment, our approach introduces roles and focus, which are expressed in an extensible xml-format. Throughout a collaborative meeting, participants can adopt various roles and may switch from one role to another at any time. The floor control policy dynamically adjusts to those users and their ongoing activities, thereby preventing the majority of conflicts. The organizational hierarchy determines the outcome of any conflict, and is employed to avoid various malpractices. Moreover, through an enhanced sense of mutual awareness, confusion and unintentional sideeffects are greatly reduced. To clarify the intended approach, we present a very common and practical scenario in the next section. Hereafter, we discuss the significance of the user’s roles and focus during a collaborative experience, and shed some light on properties related to day-today access control. Building upon this rationalization, we point out how such features can enhance floor control policies. To validate the approach, we provide a few interesting particulars regarding our implementation. In conclusion, we review our approach and elaborate on a number of promising extensions.

790

D. Vanacken et al.

2 Exemplifying Scenario The following scenario is used throughout the text, in order to demonstrate how we implemented a more predictable, yet dynamic group coordination and an effective access control mechanism by employing a user’s roles and focus. Three employees of a software development team attend a kick-off meeting: Kate, project leader, Bob, lead programmer and Tom, developer. Bob starts the meeting by introducing the design architecture of a new software project. In his current function as speaker, he is the only person capable of navigating through the set of slides. When Tom tries to alter one of the slides, he is notified by the system of the ongoing presentation and his action is prohibited. Bob finishes his talk and all users, including Bob himself, are now considered equal participants in an open discussion. As a result, the system finally allows Tom to modify the slideshow. Meanwhile, Kate opens a financial report and starts going over the first page with Bob. Others are not permitted to disturb their activity by closing or moving the document, since a significant number of users (two out of three) focus on it. Kate’s file contains confidential information; Tom, as a developer, is not qualified to access the contents.

3 Focus+Roles In the next sections, we examine the user’s roles and focus: we define the terms in the context of our work and discuss their significance during collaborative meetings. In addition, we consider some useful properties related to access control, which we ascribe to the collaborative items in our environment. 3.1 Roles A user’s role in an organizational context is determined by a job description, defined as a collection of responsibilities, privileges and associated organizational tasks. We call such an organizational role static, since it rarely changes. Static roles include project leaders, lead programmers, software engineers, analysts, developers, financial advisers, PR managers, technical and administrative support, etc. Likewise, a user’s proficiencies can be considered reasonably unchanging. Therefore, static roles also include C++ or network experts, hardware specialists, etc. Users may adopt several static roles at once. In the context of a collaborative get-together, a role is determined by a user’s current activity, defined as a second collection of responsibilities and privileges. Since a user switches from one activity to another on a regular basis [1], we call it a dynamic role. Dynamic roles include speakers and attendees, chairpersons, brainstorm participants, demonstrators, note takers, etc. Users may adopt only one dynamic role at once, yet they can switch roles whenever the need arises. In a collaborative environment, invasive activities such as leafing through a slideshow or altering the contents of a slide are predominantly carried out by a rather narrow subgroup of users. This group consists of users taking on a dynamic role which is inherently related to the activity. For instance, one can expect a speaker to browse through a slideshow or alter a slide, whereas an attendee will not. Users outside the

Focus+Roles: Socio-Organizational Conflict Resolution

791

subgroup generally perform non-intrusive actions such as observing the ongoing activities or note taking. These particular characteristics of collaboration can be exploited to prevent a range of conflicts. To illustrate this approach, we reconsider our scenario. The lead programmer Bob, in his role of speaker, may navigate through the slideshow unhindered; his dynamic role is related to that activity. Conversely, to prevent conflicts with other users during Bob’s presentation, attendees are limited to non-intrusive actions such as observing the slideshow on a shared screen. As a result, Tom’s attempt to modify one of the slides is prohibited during the talk, thereby averting an inconvenient disruption. When several users adopt one and the same dynamic role, collaborative activities may result in a power struggle. In such circumstances, the organizational hierarchy is of overriding importance. In other words, the users’ static roles determine the final outcome. In our scenario, all users take on an identical dynamic role for the duration of the open discussion. If Kate and Tom should try to move a document simultaneously, Kate’s action will be given priority, since she is the project leader. 3.2 Focus In real life circumstances, a person's physical presence provides numerous indications relating to that person's centre of attention. We notice if someone is looking at one item in particular (primarily based on head movements and eye gaze), we often point our finger to draw other people's attention, distinct facial expressions may reveal a person’s intentions, etc. As a result of such a mutual awareness, various conflicts are avoided in a natural way (e.g. we customarily refrain from closing a document while we are aware that others are reading it). In a collaborative environment which allows users to participate both co-located and remote, the natural sense of mutual awareness is inadequate. Collaborative work involves periods of tightly coupled group activities, alternated with more loosely coupled individual work [1]. For instance, a group of users frequently commences to collaborate on one topic, and eventually evolves into several smaller communities, working separately in multiple threads. Such threads close, split off and merge repeatedly, making it difficult for users to stay informed about all ongoing parallel activities. This inevitable lack of mutual awareness brings about many conflicts. Therefore, we provide an enhanced sense of mutual awareness by taking advantage of a user’s focus. We consider two different kinds of focus: passive and active focus. A user's passive focus is determined by activities such as reading a document or listening to an audio stream. The user’s active focus, on the other hand, includes actions such as manipulating a document, moving an item, leafing through a text, etc. Active focus clearly involves some form of user input, while passive focus does not. Our scenario illustrates the useful employment of focus. After his presentation, Bob starts discussing the financial report with Kate. Meanwhile, Tom alters one of the slides, and thereby loses track of all nearby activities. When the necessary modifications have been carried out, Tom, not aware of the ongoing discussion, may try to move the report, in order to examine it himself. However, Tom is not permitted to disturb Bob and Kate by moving the document, since a significant number of users (two out of three) are centring their attention on it.

792

D. Vanacken et al.

3.3 Access Control On a collaborative shared display, access control constitutes a fairly sensitive issue, particularly in an organizational context. Although all documents are available on a single surface, some belong to individuals who may wish to prohibit certain types of access by their fellow users. Access restrictions can limit a user’s ability to open, copy or print a file, the ability to edit or remove an object, etc. From an organizational perspective, access rights and restrictions are related to the user’s static roles. A financial report, for example, mainly concerns users with an administrative role, while developers are generally not qualified to comprehend or handle such information. Moreover, the financial document may contain sensitive information, which should not be accessible to everyone. In addition to the traditional operating system’s approach, we allow a user’s access rights to be inferred from the associated roles, in combination with the document’s content type (e.g. financial report, presentation, etc.) and sensitivity (e.g. confidential or publicly available). To exemplify this process, we refer to our scenario once more. Bob informs all participants of the new design architecture, by means of a few slides which contain the most significant objectives. Since the document will be publicly available after the meeting, all users are allowed to make a personal copy. However, Kate, the project leader, also mentions some financial figures, written down in a sensitive spreadsheet. Given that the information is highly confidential, nobody is authorized to copy the file for personal use. Access control is not only applicable to documents in a shared workspace; the collaborative dynamics in an application can also benefit from restricted access to other types of objects, including menu items or toolbar buttons. Functionalities such as closing the entire workspace or automatically tiling all items should be used with care in a multi-user environment. The dynamic roles of a user can pose a solution, since the set of current activities often determines which users should be in control of the system. The speaker should, for example, be able to tile the workspace, as opposed to the attendees.

4 Implementation To validate our approach, we added an initial Focus+Roles policy to an existing collaborative environment, iConnect [2]. In the next sections, we briefly introduce the environment and provide a few interesting particulars regarding our implementation. 4.1 The iConnect Project The iConnect project aims at the creation of a collaborative meeting room, in which participants can be either co-located or remote (Fig. 1). Users are able to share and manipulate arbitrary data through heterogeneous input devices and displays; personal workspaces are single-user oriented, whereas shared workspaces permit numerous users to operate concurrently.

Focus+Roles: Socio-Organizational Conflict Resolution

793

Fig. 1. The iConnect environment. On a shared workspace, participants are represented by an avatar and a personal cursor. Users interact with the environment using the touch-sensitive shared display, or a personal device (e.g. PDA).

Each user is represented by an avatar and commands an individual cursor in a shared view. A cursor can be operated either at the shared display itself, or from a distance, using a personal device such as a PDA. The cursor allows a user to manipulate (e.g. open, close, move, resize) objects, write down annotations, transfer data to and from a personal space, etc. Simultaneous interactions in a highly collaborative environment such as iConnect cause numerous conflicts on a regular basis, which disturb the dynamic workflow and group coordination. Since iConnect is primarily targeted at common daily meetings, which rely heavily on the participants’ roles to prevent and resolve conflicts, it provides an appropriate test case. 4.2 Roles Roles are defined by a set of permissions, written down in an extensible xml-format (Fig. 2). A user’s static roles are primarily employed to provide the necessary access control. Therefore, we associate each static role with a set of content permissions, indicating to what extent a user is suited to handle a particular content type. A user’s dynamic role, on the other hand, is effectively put to use to prevent conflicting activities. Such a role is expressed in terms of activity permissions. The permission level specifies whether a user may perform a particular activity or not, and to what extent a user’s action will be given priority over other (ongoing or simultaneously initiated) activities. While a user's static roles are fixed from the beginning of a collaborative meeting, the environment must allow the user to easily switch between dynamic roles during the course of the collaboration. Since iConnect requires each user to log on to the system, the static roles can be simply recovered from a database. The dynamic role,

794

D. Vanacken et al.

Fig. 2. A partial description of a developer and brainstorm role. This particular example shows, for instance, developers with no access to financial documents and brainstorm participants with limited capabilities regarding actions on the entire workspace (e.g. tiling documents). The xml-format provides an easy way to quickly adjust existing roles or add new ones.

however, must be selected by the user when connecting to the environment, and may be altered at any time. 4.3 Focus Based on both passive and active focus, each object in the environment is attributed an amount of attention. Passive focus is detected by analysing a user's cursor movements: when hovering over an eligible object, the user’s centre of attention gradually shifts to it, thereby increasing the amount. Active focus is determined by explicit actions (e.g. mouse clicks) on an object; the associated increase in the amount progressively diminishes over time. Whenever a user tries to perform an action that influences a shared object, the content type, sensitivity, ongoing activities and amount of focus are compared to the corresponding permissions of the user. The outcome determines whether the system carries out the action or (discreetly) notifies the users of a conflict (Fig. 3).

Fig. 3. Multiple users simultaneously interacting with a slideshow. One user tries to close the document, while two others center their attention on it. The system discreetly notifies the users of a conflict (by means of a miniature stop sign) and does not allow the closing to take place.

Focus+Roles: Socio-Organizational Conflict Resolution

795

4.4 Access Control A practical workspace in a collaborative meeting environment requires document formats such as text files, presentations, spreadsheets, pictures, video files, etc. However, the document format not always provides a sufficient indication of the actual contents. Therefore, we employ a secondary classification, based on content type and sensitivity: a text file may contain an internal application design or a simple note, spreadsheets can hold confidential financial information or a publicly available planning, etc. When uploading a file to the iConnect environment, the user should state the type of contents and the document's sensitivity. In some cases, it is possible for the system to determine one or both properties automatically. For instance, a C++ file always contains programming code, and a bank statement is at all times considered sensitive information.

5 Conclusions and Future Work Social protocols represent a popular floor control choice in present-day collaborative environments. Unfortunately, such solutions are everything but foolproof. Our approach effectively provides both conflict handling and access control in a wideranging environment, by introducing roles and focus, which are expressed in an extensible xml-format. Throughout a collaborative meeting, participants can adopt a variety of static roles, representing their organizational function and proficiencies. In addition, a dynamic role specifies the user’s current activities; a user may switch from one such role to another at any time. Our floor control policy dynamically adjusts to the participants’ roles, and focus tracking provides an enhanced sense of mutual awareness, thereby reducing confusion and unintentional effects. Furthermore, we ascribe properties such as content type and sensitivity to the collaborative items in our environment, allowing for effective access control when combined with the users’ roles. Incorporating role management and intelligent focus tracking into floor control policies is only part of the job. An important step is to visualize the roles and focus of a user, in order to further enhance the sense of mutual awareness. Providing a means for one user to grant temporary privileges to another user, or expanding the concept of roles to entire teams might offer us even more flexibility. Tracking a user's eye gaze, head orientation or posture will unquestionably improve the focus recognition. To further refine our floor control mechanism, we can track a user's interaction history. By considering all past and present actions on an object, we can define a degree of ownership for each user, which is useful when deciding on a particular action (e.g. delete a document). If others were far more active on a document, they should be in control of the most sensitive activities, and not a user who barely paid any attention to it. In addition, an honesty policy can benefit less assertive people, whose actions will continuously be suppressed by more prevailing users. An honesty algorithm can determine the activity rate of each individual, and thereafter prioritize less active user's actions. Furthermore, it should prove interesting to include device properties in the floor control policy, since studies suggest that users behave differently when seated around

796

D. Vanacken et al.

a table, or standing in front of a vertical display. It might even be possible to automatically deduce a user’s current dynamic role from such device properties, ensuring smoother policy transitions. Acknowledgements. Part of the research at EDM is funded by the European Fund for Regional Development and the Flemish Government, the iConnect project is funded by the Interdisciplinary institute for BroadBand Technology (IBBT). We would like to thank Maarten Cardinaels and Geert Vanderhulst for their invaluable assistance.

References 1. Bergqvist, J., Dahlberg, P., Ljungberg, F., Kristoffersen, S.: Moving out of the meeting room: exploring support for mobile meetings. In: Proceedings of the Sixth European Conference on Computer Supported Cooperative Work, pp. 81–98. Kluwer Academic Publishers, Dordrecht (1999) 2. Cardinaels, M., Vanderhulst, G., Wijnants, M., Raymaekers, C., Luyten, K., Coninx, K.: Seamless Interaction between Multiple Devices and Meeting Rooms. In: Proceedings of the CHI’06 Workshop on Information Visualization and Interaction Techniques for Collaboration across Multiple Displays, Montreal, Canada, (April 2006) 3. Dommel, H.P., Dahlberg, Garcia-Luna-Aceves, J.J.: Floor control for multimedia conferencing and collaboration. In: Multimedia Systems, pp. 23–38. Springer-Verlag, Heidelberg (1997) 4. Edwards, K.W.: Policies and roles in collaborative applications. In: Proceedings of the 1996 ACM conference on Computer supported cooperative work, pp. 11–20. ACM Press, New York (1996) 5. Greenberg, S., Marwood, D.: Real time groupware as a distributed system: concurrency control and its effect on the interface. In: Proceedings of the 1994 ACM conference on Computer supported cooperative work, pp. 207–217. ACM Press, New York (1994) 6. Izadi, S., Brignull, H., Rodden, T., Rogers, Y., Underwood, M.: Dynamo: a public interactive surface supporting the cooperative sharing and exchange of media. In: Proceedings of the 16th annual ACM symposium on User interface software and technology, pp. 159– 168. ACM Press, New York (2003) 7. Morris, M.R., Ryall, K., Shen, C., Forlines, C., Vernier, F.: Beyond “social protocols”: multi-user coordination policies for co-located groupware. In: Proceedings of the 2004 ACM conference on Computer supported cooperative work, pp. 262–265. ACM Press, New York (2004) 8. Scott, S.D., Grant, K., Mandryk, R.: System Guidelines for Co-located Collaborative Work on a Tabletop Display. In: Proceedings of the 2003 eighth European conference on Computer-supported cooperative work, pp. 159–178. Springer-Verlag, Heidelberg (2003) 9. Smith, R.B., Hixon, R., Horan, B.: Supporting flexible roles in a shared workspace. In: Proceedings of the 1998 ACM conference on Computer supported cooperative work, pp. 197–206. ACM Press, New York (1998) 10. Wang, W.: Team-and-role-based organizational context and access control for cooperative hypermedia environments.In: Proceedings of the tenth ACM Conference on Hypertext and hypermedia: returning to our diverse roots, pp. 37–46. ACM Press, New York (1999)