Towards effective collaborative design and engineering Stephan Lukosch Gwendolyn Kolfschoten Delft University of Technology Delft University of Technology Faculty of Technology, Policy, and Management Faculty of Technology, Policy, and Management Jaffalaan 5, 2628 BX Delft, The Netherlands Jaffalaan 5, 2628 BX Delft, The Netherlands s.g.lukosch@tudelft.nl g.l.kolfschoten@tudelft.nl ABSTRACT Groups might not be able to overcome the challenges of collabo- Effective collaborative design and engineering has to deal with var- ration by themselves [16]. Even if groups are able to accomplish ious challenges. It is essential to create a shared understanding and their goals, they can often collaborate more efficiently and effec- facilitate interaction in such a way that effective collaboration be- tively using collaboration support [6]. Collaboration support can comes possible. Free riding, group think or hidden agendas need be comprised by tools, processes and services that support groups to be addressed by rarely available process facilitators. Available in their joint effort. In knowledge oriented organizations, there is tools are not regularly used, are not intuitive and often are difficult often a need or demand for collaboration support. However, tools to adapt to the changing group needs. In order to tackle the above and technology for group support exist in a variety of shapes from issues, we want to enable effective collaborative design and engi- complex computer systems, as e.g. Group Support Systems (GSS), neering by offering intelligent collaboration support that supports to simple boxes with cards and pencils. Each of these tools can facilitators of collaboration processes when monitoring collabora- be used by the group to be more successful in sharing ideas and tion processes and planning process interventions or tool adapta- indicating relations and preferences, but current challenges emerge tions. from the fact that available tools are not regularly used, are not in- tuitive and often are difficult to adapt to the changing group needs [7]. This makes it difficult for organizations to provide their teams Categories and Subject Descriptors with a suitable and adaptable collaboration support that help them H.4.1 [Office Automation]: Groupware; H.5.3 [Group and Or- accomplish their goals efficiently and effectively. ganization Interfaces]: Computer-supported cooperative work; K.4.3 [Organizational Impacts]: Computer-supported collabora- As discussed in [7], current collaboration support systems focus tive work adaptations with a limited scope. They are either restricted to spe- cific domains or to specific aspects of collaborative work, often General Terms focusing on awareness or knowledge management. Compared to Design, Human Factors this, we aim to create intelligent collaboration support that creates a shared understanding, facilitates collaborative actions across vari- ous geographic, temporal, disciplinary, and cultural boundaries and Keywords provides intuitive and adaptive tool support. This will allow us to Collaboration support systems, intelligent collaboration support, offer collaboration support for a variety of collaborative tasks in facilitation, group support systems a way that groups can use it for themselves without the need for extensive training or a professional facilitator. In this paper, we 1. INTRODUCTION will as a first step propose a conceptual framework towards intel- Collaboration has become a critical skill as products and services ligent collaboration support. We modeled collaboration processes are becoming increasingly complex, no individual has the skills to and identified factors suggesting process changes as well as adap- design, develop and deliver these alone. Collaboration is however, tations. These factors are the basis for this framework of intelligent not without challenges. On a group level, it is essential to create a collaboration support, which will offer us a first step in monitoring shared understanding, define rules for decision-making and facili- groups and predicting the need for facilitation interventions. tate interaction in such a way that effective collaboration becomes possible [13]. On a process level, free riding, dominance, group In the next section we will explain in detail how facilitators guide think, hidden agendas, are but a few phenomena in group work that collaboration processes. This will lead to a conceptual framework make it a non straight-forward effort [16]. of collaboration support interventions, presented in section 3. Next we will present how this framework can be used to identify specific collaboration situations to create intelligent collaboration support. We will then reflect on this design and end with conclusions and a research agenda. 2. FACILITATING COLLABORATION PROCESSES One of way of supporting groups in achieving their goals more ef- ficiently and effectively is to support the group by structuring and guiding their activities. This skill and profession is called facilita- 1. Collaboration process design: Interventions to guide col- tion. The facilitation task is described extensively in GSS literature laborators in choosing appropriate tools and techniques to [1, 8, 14]. The task of a facilitator requires both experience and support the collaboration process. extensive knowledge of group dynamics and facilitation methods. This tasks involves for instance management of the activities the 2. Collaboration process execution: guidance to move from group is performing, quality of their deliverables, relations between one activity to a next activity, changing the collaboration sup- the participants and the use of resources and time [9]. This type of port environment to transfer between activities, while taking process guidance is often offered by someone external to the group, documents and decisions along to a next phase. to ensure impartiality and objectivity. 3. Collaboration process guidance: Activities need to be ini- tiated and guarded to execute the collaborative activity. In an effort to reduce the need for professional facilitators, re- searchers have been coding facilitation practices to enable the sepa- 4. Collaborative behavior guidance: guidance in determining ration of the design task of a facilitator and the execution task [11]. and adjusting improves collaborative effectiveness. In this way a master facilitator called collaboration engineer, can design and transfer a collaborative work practice to practitioners to In a face to face context, facilitators can make adjustment interven- execute it for them selves based on a short training. This approach tions based on behavior of group members, including communica- is called Collaboration Engineering [3]. To ensure the predictabil- tion with group members, quality of the output of the group, and ity and transferability of the collaborative work practice, they are progress versus planned time for the group task. Based on our ex- designed with design patterns called thinkLets [4]. perience and discussion with expert facilitators, the following list is a first attempt to identify factors used to determine the need to To realize an intention by means of intervention, two types of in- make an intervention: terventions are required [2]. First, there are static interventions in which one or more commands are given to initiate the key activi- ties of a process. We will refer to this kind of communication as an • Group: behavior, emotions, communication, body language, instruction intervention. Second, there are dynamic interventions address facilitator, gestures intended to adjust the actions performed by the group to resolve a discrepancy between the facilitator’s intentions and the groups’ ac- • Task: amount of input, rate of input, quality of input, quality tions. These interventions depend on emergent conditions. We will of output, shared understanding, fit in relations in output call these messages adjustment interventions. • Time: progress, time left The conceptual design of a thinkLet exists of a set of instruction and adjustment interventions described as rules [4]. These rules Some of these aspects are non-digital and based partially on inter- are similar to rules mimicking human behavior in avatars [2]. Each pretations. This requires a translation to gain the same insights rule describes for a role an action that needs to be performed using from the online interaction. For instance facilitators might monitor a capability under some set of constraints to restrict those actions. de-focus of participants as an indicator that the group is finished Further, some thinkLets include conditional rules for frequently- with the task. However, this might also be learned from a signifi- required adjustment interventions because specific discrepancies cant decrease in input rate. However, without technology support manifest predictably during the execution of an activity based on to monitor input rate, perhaps per participant, this would be diffi- the thinkLet. cult to detect for a facilitator. Also the interpretation of input rate requires some experience and understanding of the cognitive impli- An example of a set of rules are captured in the L EAFHOPPER thin- cations of tools and knowledge sharing. Therefore we need more kLet [4]: than a thermometer to measure input rate, we need an intelligent collaboration support system that can monitor these factors, and use them to reason about the current collaboration process in order 1. Allow participants to add in parallel any number of contribu- to support facilitators in making intervention decisions. tions to any category. 2. Allow participants to add only contributions that are relevant 4. LEAFHOPPER FACILITATION INTER- to the categories in which they are placed. VENTIONS In the textbox below we describe what a facilitator does after initi- 3. Allow participants to add only contributions that match to the ating the L EAFHOPPER thinkLet to brainstorm ideas in categories. contribution specification. Underlined are those indicators the facilitator uses to make deci- sions on interventions. Some of these indicators can directly be 4. Let participants shift focus from category to category as in- observed, others are an interpretation of the facilitator. terest and inspiration dictate. After initiating the Leafhopper the facilitator needs to maintain sev- 5. Ensure that participants read the contributions of others for eral rules. The contributions of the group need to meet the quality inspiration. intended, they need to meet the contribution specification, the cat- egory in which they are placed. The contributions need to be made 3. CONCEPTUAL FRAMEWORK in a certain timeframe, and they need to cover a certain scope of In order to provide intelligent collaboration support, we first need information (completeness). Additionally the facilitator will need to identify the key goals that guide facilitation interventions. When to maintain a safe and respectful atmosphere to ensure that people facilitators intervene to initiate activity they can offer these at dif- feel free and encouraged to participate. To ensure that the partic- ferent levels [15]: ipants can share all relevant contributions, the facilitator can add Figure 1: Domain model for collaboration in a shared workspace a category ’other’. This category is monitored by the facilitator. setting (e.g., team structure, roles, tasks). Dey et al. [5]define con- When a pattern of contributions can be found in this category, the text as any information used to characterize a situation of an entity facilitator will add a new category to cover this topic. where an entity may be any object, person or place providing in- formation about the interaction between a user and an application. The facilitator will monitor the input, mainly to detect if there are With this definition, any information may help characterizing the small or insufficient quality contributions. Later in the process situation of the interaction’s participants because it is part of the the facilitator will monitor if the categories each contain a suffi- context itself. For our purposes, we can narrow this definition so cient number of contributions. Also, the facilitator will monitor that context includes all information which is necessary or helpful the ’other’ category to see if there is a persistent topic addressed, to adapt a shared workspace to better fit the needs of a collaborat- and therefore, a need to add a category. The facilitator might inter- ing team. This implies that the context contains information about vene if some categories are not filled. Such intervention would be the team as well as about the current collaboration situation. This made before the time for the task is passed, to give participants context information is necessary to recognize situations which de- time to add ideas in these categories, but not too early, when par- mand a facilitator’s intervention (and thus help minimizing the ef- ticipants might not yet had a chance to contribute to all categories. fort needed for adaptation). The facilitator will also observe the group to see if participants get distracted, or focus on other activities, which indicate that they We use a collaboration domain model for describing collaboration are (no longer) motivated for the task. The facilitator will also mon- environments and collaboration situations [7]. Figure 1 summa- itor behavior, communication and body language to see if any of the rizes this domain model and shows the basic classes and their rela- input causes an emotional reaction, which could indicate conflict tions that can be used to describe collaboration context in a global or flaming, which would require intervention. Finally the facilitator collaboration space. The domain model intends to capture the basic will monitor the input rate and the focus of participants to detect concepts of collaborative workspaces. It focuses on the technolog- when there is no more inspiration and the task can be ended. If the ical support for collaborative interaction and does not distinguish group is still very active and focused when time is running out, different artifact types or task domains. If applied to a certain col- the facilitator might encourage the group to speed up or to focus laboration environment, it must be extended with concepts match- on more important contributions in order to ensure that sufficient ing the specific properties. progress is made when the task should be finished. In some cases this can also be a reason to give the group more time for the task. The model in Figure 1 distinguishes different concepts that describe collaboration in a collaboration environment and relations between these concepts. We start exploring and explaining the model in Fig- 5. DESIGNING INTELLIGENT COLLAB- ure 1 with the concept of an Actor (see lower part of Figure 1). The ORATION SUPPORT domain model assumes that Actors are member of a Team and have In order to create a collaboration support system that can suggest a Role defined by the User Workspace, as Applications are started facilitators to make interventions, we use an explicit context model from within the User Workspace and thus the workspace can en- to describe the current collaboration situation. A collaboration situ- sure pre-defined Roles. Each Role allows an Actor to perform spe- ation can be characterized by the configuration of the collaboration cific Actions. The available Actions are defined by the supported environment as well as the state of interaction of the users with the Application Functionality of an Application. As an example con- system (e.g., based on interaction history) and the organizational sider a chat application which should offer at least two action types: categories and in case again alerts the facilitator can specified as OpenChat and SendMsg. These two actions would allow users to follows: communicate with each other by opening a chat tool and send mes- rule "empty categories" sages to each other. Other forms of collaboration such as within a when collaborative diagram editor would require to add additional action $category: Category(size == 0) types in order to specify the application functionality. then forall $c in $category As Actors interact with the Application by performing Actions al- openForFacilitator(Alert, "Category "+ $c.name()+" is empty. lowed by their Roles, Roles define interaction possibilities within Focus the attention of an application, e.g. in a shared writing application an author might the participants on the perform all edit actions whereas a reviewer can only comment ex- empty category.") isting text. The Actions are received by the corresponding Con- end troller components of the Application. An Application implements the model-view-controller (MVC) paradigm [12] and consists of As final example, the following rule checks the focus of the partici- Views and Controllers components. Views and Controllers use Ser- pants in order to alert the facilitator when half of the participants do vices to access the Artifacts. Artifacts use Services to notify Views not focus on the activity of creating contributions. For that purpose, and Controllers about changes. Each Application is part of a User the rule retrieves for focus of each participant by identifying the ac- Workspace and is created by an Application Factory which spec- tive View in the User Workspace. Based on the basic collaboration ifies what Applications are available within a workspace and how model (cf. Figure 1), this information can be inferred via the User these can be initialized. Finally, the class Application Functionality Workspace and the opened Applications within the workspace. The specifies the functionality an Application offers, e.g. in relation to following example rule assumes that the participants should focus communication, shared editing, or awareness. on a view with the name ’contribution input’ and if they do not do so alerts the facilitator: All above classes are useful to model and store the configuration of a collaboration environment and to capture the current context at rule "participants distracted" runtime. Based on such context information, a collaboration envi- when ronment is enabled to recognize situations, which demand a facili- $participants: Participant(focus != "contribution input") tator’s attention and intervention. $threshold: $participants[0].team(). size()/2 The domain model is abstract and not related to a specific applica- eval($participants.size() >= $threshold) tion domain. When considering our example on the L EAFHOPPER then thinkLet, we need to extend the model as shown in Figure 2. In openForFacilitator(Alert, "More than 50% order to incorporate the L EAFHOPPER thinkLet, the Artifact class, of the participants do not focus on creating the Action class and the Role class were extended. Based on this contributions.") extension, we can now distinguish between participants and the fa- end cilitator as well as identify contributions within a category. 6. DISCUSSION AND CONCLUSION Based on the extended domain model, we can suggest process in- Collaboration has become a critical success factor for many orga- terventions or tool adaptations in order to improve collaborative nizations, as products and services are becoming increasingly com- interaction. One process intervention within our L EAFHOPPER ex- plex and cannot be designed individually. However, collaboration ample is triggered when the category ’other’ exceeds a specified has several challenges. It is essential to create a shared understand- threshold. The following rule consists of a condition and an action ing and facilitate interaction in such a way that effective collabora- block. The condition block retrieves all contributions within the tion becomes possible. Free riding, group think or hidden agendas context model that belong to the category ’other’ and then evalu- need to be addressed by rarely available process facilitators. Avail- ates whether the number of contribution has exceeded a specified able tools are not regularly used, are not intuitive and often are threshold. If this is the case, the action block opens an alert view difficult to adapt to the changing group needs. In order to tackle for the facilitator. The following pseudo code shows how such a the above issues, we want to enable effective collaborative design rule can be specified: and engineering by offering intelligent collaboration support that rule "create new category" supports facilitators of collaboration processes when monitoring when collaboration processes and planning process interventions or tool $contributions: Contribution(category == adaptations. ’other’) eval($contributions.size() >= 20) then In this article, we identified several factors that are observed by openForFacilitator(Alert, "Number of professional facilitators before changing and adapting an ongoing contributions in collaboration process. We further introduced an abstract context category ’other’ has model which can be used to model collaboration within a shared exceeded specified workspace. We extended this model to include concepts and classes limit. Check whether of the L EAFHOPPER thinkLet. Based on the experiences of a pro- new category is necessary.") fessional facilitator, we used this extended context model to define end rules which can assist a facilitator. Based on the proposed rules, a context-adaptive and intelligent col- Another example for a rule that monitors whether there are empty laboration support environment, such as [17], can alert a facilita- Figure 2: Extended domain model for the L EAFHOPPER thinkLet tor when an intervention might become necessary and reduce the Information Systems (IJCIS), 19(1-2):71–120, 2010. facilitator’s overhead. In future work, we will go a step further [8] S. Hayne. The facilitator’s perspective on meetings and and model entire collaboration processes based on thinkLets [10]. implications for group support systems design. Database, We then will study factors that determine and influence collabora- 30(3-4):72–91, 1999. tion performance, e.g. cognitive load or shared understanding, and [9] G. Kolfschoten and G. de Vreede. A design approach for that inform facilitation interventions. Once identified, we will inte- collaboration processes: A multi-method design science grate these factors in our context model and think about possibili- study in collaboration engineering. Journal of Management ties to measure soft factors via additional application functionality Information Systems, 26:225–256, 2009. and without obstructing or distracting the group work, e.g. by of- [10] G. Kolfschoten, S. Lukosch, and M. Seck. Modeling fering means for self reporting. We will further identify and specify collaboration processes to understand and predict group rules that recognize situations that require process interventions by performance. In A. Dix, T. Hussein, S. Lukosch, and recording facilitation interventions and the performance indicators J. Ziegler, editors, Proceedings of the IUI workshop on at the point of intervention to gain more fine-grained rules for pro- Semantic Models for Adaptive Interactive Systems (SEMAIS) cess intervention. 2010, 2010. [11] G. Kolfschoten, F. Niederman, G. de Vreede, and R. Briggs. The path to intelligent collaboration support sketched above is long, Roles in collaboration support and the effect on sustained but small steps might already improve collaborative design and en- collaboration support. In Hawaii International Conference gineering today. As facilitators need to monitor many factors and on System Science (HICSS-41), 2008. indicators of progress, basic suggestions for process intervention as [12] G. E. Krasner and S. T. Pope. A cookbook for using the outlined above might already reduce some of the cognitive load of model-view-controller user interface paradigm in the facilitation task. Smalltalk-80. Journal of Object-Oriented Programming, 1(3):26–49, Aug. 1988. 7. REFERENCES [13] S.-Y. Lu, W. Elmaraghy, G. Schuh, and R. Wilhelm. A [1] F. Ackermann. Participants perceptions on the role of scientific foundation of collaborative engineering. CIRP facilitators using group decision support systems. Group Annals - Manufacturing Technology, 56(2):605 – 634, 2007. Decision and Negotiation, 5:93–519, 1996. [14] F. Niederman, C. Beise, and P. Beranek. Issues and concerns [2] N. Badler, R. Bindiganavale, J. Bourne, M. Palmer, J. Shi, about computer-supported meetings: The facilitator’s and W. Schuler. A parameterized action representation for perspective. Management Information Systems Quarterly, virtual human agents. In Workshop on Embodied 20(1):1–22, 1996. Conversational Characters, 1998. [15] F. Niederman, G. de Vreede, R. Briggs, and G. Kolfschoten. [3] R. Briggs, G. de Vreede, and J. Nunamaker. Collaboration Extending the contextual and organizational elements of engineering with thinklets to pursue sustained success with adaptive structuration theory in GSS research. Journal of the group support systems. Journal of Management Information Association for Information Systems, 9(10), 2008. Systems, 19:31–63, 2003. [16] J. J. Nunamaker, R. Briggs, D. Mittleman, D. Vogel, and [4] R. Briggs and G.-J. de Vreede. ThinkLets: Building Blocks P. Balthazard. Lessons from a dozen years of group support for Concerted Collaboration. Delft University of systems research: A discussion of lab and field findings. Technology, Delft, The Netherlands, 2001. Journal of Management Information Systems, 13:163–207, [5] A. K. Dey, G. D. Abowd, and D. Salber. A conceptual 1997. framework and a toolkit for supporting the rapid prototyping [17] D. Veiel, J. M. Haake, and S. Lukosch. Facilitating of context-aware applications. Human-Computer Interaction, team-based adaptation of shared workspaces. In 16(2, 3, & 4):97–166, 2001. International Symposium on Collaborative Technologies and [6] J. Fjermestad and S. Hiltz. A descriptive evaluation of group Systems (CTS 2010), pages 275–284. IEEE, 2010. support systems case and field studies. ournal of Management Information Systems, 17:115–159, 2001. [7] J. M. Haake, T. Hussein, B. Joop, S. Lukosch, D. Veiel, and J. Ziegler. Modeling and exploiting context for adaptive collaboration. International Journal for Cooperative