Marco Manca
email: marco.manca@isti.cnr.it

Fabio Paternò
email: fabio.paterno@isti.cnr.it

Carmen Santoro
email: carmen.santoro@isti.cnr.it

Collaborative Task Modelling on the Web

Keywords: Task models, Collaborative Modelling, Responsive Web 1

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Task modelling is a useful method for various activities in the user interface design and development process. It helps to better understand the application domain, record the results of interdisciplinary discussions, support user interface design, usability evaluation, and documentation. The nature of task modelling as a multi-disciplinary process is widely accepted: in order to properly carry out task modelling it is important to involve various experts, stakeholders, designers and users. In addition, with the increasing need for collaboration among stakeholders, and also the need to reduce costs, which often forces teams to collaborate also from different locations, it is becoming increasingly important to create a shared understanding and joint representations of the interactive systems being designed. As a consequence, enabling interactive collaborative modelling in this area can prove to be valuable as it could make collaborations more effective and productive. For instance, in some situations it might be interesting for UI designers to carry out the modelling work together with users at the same time but from different locations, or it would be interesting for the members of the same design team to be able to carry out the modelling activity in a collabora-tive manner. Unfortunately, most of the tools that support task modelling only allow for single users, and they do not enable various users to share the task models and collaboratively edit them. Thus, we judged it interesting to investigate the opportunities offered by a multi-user, collaborative, Web-based task modelling tool.

In particular, the main goals of this work are to design a tool able to:

 Support a shared view of task models across various devices and associated users;  Support concurrent editing of task models by multiple users;  Provide mechanisms to synchronize editing of some parts of the task models;  Provide mechanisms to create mutual awareness of the concurrent activities in the modelling process.

To these ends, we have opted for a responsive Web-based implementation because this would facilitate its adoption given its wide interoperability across various devices, and we have adopted the ConcurTaskTrees (CTT) notation [START_REF] Paternò | Model-based Design and Evaluation of Interactive Applications[END_REF] since it is widely known in the task modelling community.

In the paper after reviewing the state of the art, we introduce some scenarios that have motivated our work; next we discuss how we have designed the features that support the collaboration in editing the task model, describe how it has been implemented, and report on two user tests. Lastly, we draw some conclusions and provide indications about future work.

STATE OF THE ART

Collaborative modelling has received some attention in some domains. For example, Collaborative Protégé and WebProtégé [START_REF] Horridge | WebProtégé: a collaborative Web-based platform for editing biomedical ontologies[END_REF] are extensions of the existing Protégé (http://protege. stanford.edu), also enabling collaborative ontology editing. Support in this direction is also provided by some commercial tools. For example, VPository (from Visual Paradigm, http://www.vpository.com/) offers a central repository for storing user's software design projects with version control capabilities and, in this regard, it is far from providing the support offered by a truly collaborative environment. In [START_REF] Noy | The CKC Challenge: Exploring Tools for Collaborative Knowledge Construction[END_REF] a review of tools that support collaborative processes for creation of various forms of structured knowledge was presented. However, we note that little attention has been paid to collaborative modelling support in HCI so far.

Before analysing this aspect more closely, it can be useful to highlight the difference between tools for collaborative task modelling, and tools supporting task modelling of collaborative applications. The first case is the one which we address in this paper, i.e. we analyse tools enabling users to jointly create a model in remote or colocated places (e.g. collocated groups of designers in a room, team members in distant places), in a synchronous or asynchronous manner. In the second case, the focus is on tools allowing designers to model systems where multiple users act in a collaborative manner. So, in the first case the multi-user dimension concerns the users of the modelling tool, in the second case it regards the users of the application to design.

On the one hand, the latter case (tools supporting task modelling of collaborative applications) has been the subject of several contributions. Indeed, proposed notations for modelling multi-user applications include: the COMM (COlaborative and Multi-Modal) notation and its on-line editor for specifying multi-user multimodal interactive systems [START_REF] Jourde | COMM Notation for Specifying Collaborative and MultiModal Interactive Systems[END_REF]; CTML [START_REF] Wurdel | Toward a Formal Task-Based Specification Framework for Collaborative Environments[END_REF][START_REF] Forbrig | Making Task Modeling Suitable for Stakeholder-Driven Workflow Specifications[END_REF], a task-based specification framework for collaborative environments, consisting of a language and a tool for editing/animating CTML models; CUA (Collaboration Usability Analysis) [START_REF] Pinelle | Task Analysis for Groupware Usability Evaluation: Modeling Shared-Workspace Tasks with the Mechanics of Collaboration[END_REF], a modelling technique allowing designers to model the main features of a group work situation that will affect groupware usability. Other proposals along the same lines have been put forward by Penichet et al. [START_REF] Penichet | Task Modelling for Collaborative Systems[END_REF], van der Veer et al. [START_REF] Van Der Veer | Task modeling for collaborative authoring[END_REF], Guerrero-Garcia et al., [START_REF] Guerrero-Garcia | Comparative analysis of task model notations[END_REF], Giraldo et al. [START_REF] Giraldo | Integrating Groupware Notations with UML[END_REF], Molina et al. [START_REF] Molina | A methodological approach for user interface development of collaborative applications: A case study[END_REF][START_REF] Molina | A conceptual and methodological framework for modeling interactive groupware applications[END_REF]. On the other hand, little has been proposed for collaborative task modelling tools. Even recent proposals [START_REF] Anzalone | Responsive Task Modelling, Proceedings EICS[END_REF] have addressed the issue of adapting to various device types but not collaborative aspects. Some basic support for collaboration during task modelling has been provided in tools such as HAMSTERS [START_REF] Martinie | Multi-models-based engineering of collaborative systems: application to collision avoidance operations for spacecraft[END_REF] and CTTE [START_REF] Mori | Design and Development of Multi-Device User Interfaces through Multiple Logical Descriptions[END_REF], which enable users to re-use fragments of task models (even created by other users) within their own task model specifications. However, our goal is to provide a truly collaborative tool in which users actually share the same model, which they can collaboratively modify even at the same time.

A literature review of approaches in the area of collaborative modelling, although not specifically focused on task modelling is in [START_REF] Renger | Challenges in Collaborative Modeling: A Literature Review[END_REF], other proposals still in the same area are [START_REF] Gutwin | Group awareness in distributed software development[END_REF][START_REF] Rittgen | Group Consensus in Business Process Modeling: A Measure and Its Application[END_REF]. Some degree of collaborative support is provided by FlexiLab [START_REF] Hili | Innovative key features for mastering model complexity: flexilab, a multimodel editor illustrated on task modeling[END_REF], a UI multi-model editor for HCI implemented as a Web-based application. It mainly supports the possibility of interactively sending fragments of the model from one user to another. This allows several designers to work on separate fragments of the same model, which is especially useful when dealing with large models. While FlexiLab provides some level of collaboration and communication support (for example, it supports sharing models by sending model fragments from one device to another), our proposal addresses the concurrent editing of the same model by multiple users with multiple devices, which implies additional features also for mutual awareness and coordination (e.g. sharing focus, locking a task for editing).

In this area, one relevant experience to mention is SPACE-DESIGN [START_REF] Duque | Defining Tasks, Domains and Conversational Acts in CSCW Systems: the SPACE-DESIGN Case Study[END_REF][START_REF] Gallardo | A System for Collaborative Building of Use Case Models: Communication Analysis and Experiences -Experiences of Use and Lessons Learned from the Use of the SPACE-DESIGN Tool in the Domain of Use Case Diagrams[END_REF], which is a synchronous, generic (i.e. domain independent) collaborative modelling tool, which is extensible and also reconfigurable for a specific domain. SPACE-DESIGN has been used for task modelling through the CTT notation [START_REF] Gallardo | Collaborative Modelling of Tasks with CTT: Tools and a Study[END_REF]: starting with a CTT specification, the tool adapts its UI to provide some collaborative support for modelling with this notation by including widgets for awareness, communication and coordination. Such paper also reports on a user test that indicates that a generic collaborative modelling tool has advantages in comparison to the use of a single-user tool (such as CTTE) combined with a shared window system such as NetMeeting, especially in regards to the awareness mechanisms offered. The test indicated that when using SPACE-DESIGN, fewer situations of conflict occurred with respect to the alternative setting (CTTE+NetMeeting). While we agree on the fact that the collaborative modelling approach is a more suitable solution, we note that SPACE-DESIGN was able to support only a limited number of basic modelling functionalities (e.g. create, read, update and delete models).

Another relevant experience has been Quill [START_REF] Motti | Simplifying the development of cross-platform web user interfaces by collaborative model-based design[END_REF][START_REF] Motti | Quill: a collaborative design assistant for cross platform web application user interfaces[END_REF], a Web-based development environment that aimed to enable various stakeholders of a Web application to collaboratively adopt a model-based UI design. Quill attempted to support several users to concurrently participate in a common work project in a distributed fashion with live updates. In Quill each user has a specific role (junior or senior), which provides access to specific features of the application. Quill also has a revision control mechanism by which the changes suggested by juniors are passed for review to the senior who has the responsibility for committing them. Similarly to Quill, the results of Collaborative CTT can be included in a comprehensive MBUI-development framework (such as MARIAE [START_REF] Paternò | Engineering the authoring of usable service front ends[END_REF]). However, in our case the mechanism for deciding the changes is more flexible since rights can be assigned dynamically and not statically to the users. Overall, we can conclude that our proposal addresses an area still underexplored concerning the possibility of supporting collaboration in task modelling.

TARGET SCENARIOS

The design of the tool has been driven by some scenarios that we briefly describe in this section and are based on our experience in teaching task modelling and in research projects in which task modelling has been used.

Educational use in the classroom. In our experience teaching how to create and modify a task model may not be trivial. Once the conceptual aspects have been introduced and studied there is a strong need to do some concrete exercise to better understand how to apply in practise the concepts. An effective exercise is to develop the task model together (teacher and students) in a laboratory in which all students have their own computer (it can be a PC or a tablet or a smartphone). The teacher can start the modelling to show how to approach the associated issues and the students can see the results directly in their devices, while at the same time they can browse the model in order to analyse its features without immediately make any change. At some point the teacher may want to highlight some parts of the model and so impose his/her view on all the devices, centred on the selected part. Once students start to be familiar with the modelling activity it can be useful to gradually allow them to directly carry it out. A good exercise is to make some extension or some modification to the model in the class exercise given that creating a task model from scratch may still be premature. Thus, the teacher may want to ask specific student(s) to detail how a high level task should be carried out or perform some modification on a part of the model developed. This implies the need to assign the possibility of editing the shared model to a specific student and make it possible that her modifications are updated in the teacher and other students views.

A workgroup aiming at designing an application. An example of sector in which CTT has been often applied is the air traffic control domain 1 in which the design decisions need to be carefully analysed in order to prevent human errors that can even threaten human life. In designing such applications it is important to involve all the relevant stakeholders, such as the air traffic controllers, the application developers, the experts in the relevant regulations. When such groups are in the same room (same place/same time) their discussion could be more effective with a collaborative modelling tool. Thus, they could start the discussion with the task model developed by one of them, and the others can point issues associated with some design decisions using a shared focus, and more clearly indicate alternative ways to accomplish some tasks by directly editing the shared model.

Distributed synchronous workgroup (different places/same time). For various reasons the meetings amongst the various stakeholders in the same room are not always possible. Thus, it is useful to support the possibility of collaboratively editing the task model remotely. In this case there is a need for additional tools that support the communication among the participants (e.g. a chat), to have a precise indications of what editing has been made by each involved participant (e.g. a shared log) and to have dynamic feedback on what the other users are doing.

Distributed asynchronous workgroup (different place/different time). In some cases is not even possible to arrange a remote meeting because of work constraints. Thus, it is still useful to have the possibility of sharing a model, which can be eased by some cloud support, and facilitate its collaborative editing. In this way when one participant accesses the shared model s/he can work on the modifications carried out by the others. There can be some different opinions regarding how to design some parts, thus it is still important on the one hand to give all participants the possibility of proposing and discussing their solutions, and on the other hand to make a final decision, which can be taken by the moderator or through a vote.

THE DESIGN OF THE COLLABORATIVE FEATURES

In this section we describe how we addressed the requirements raised by the target scenarios in the proposed tool.

Roles and access rights in handling task models

In terms of roles we have adopted a solution in which there is a 'Moderator' who is the user who starts the collaborative session and invites the other participants ('Collaborative Users'). The latter can have various ways to participate, which are defined by their assigned access rights.

Such rights/authorizations are related to the ability to modify the model, invite further participants, and/or the possibility to assign the shared focus to other members.

Thus, all users can read the models (e.g. visualise, navigate, etc.), but only those who have received the corresponding rights can modify them (a locking mechanism is provided in order to avoid that the models get inconsistent states due to e.g. simultaneous changes).

The environment supports dynamic groups, thus users can be added or leave the collaborative session at any time.

Enhancing mutual awareness among users

Users can independently browse the task model. When they set the focus on one task then their personal view is adapted in such a way to centre the entire model around that task. Figure 1 shows an example in which two users have different focuses on the same model at the same time, and thus receive different views of it. One user has the focus on the EnableAccess task while the other on WithDrawCash. The red circles in Figure 1 indicate the number of task that are not visualized because they are out of the screen area. In addition, each user has an event logger panel (see Figure 3 bottom-left part), listing in temporal order all the actions carried out by each user while collaboratively working on a task model. For each action it indicates a timestamp, the user who carried it out, the type of action (e.g. lock, unlock, edit, set shared focus, update temporal operator), and the task(s) involved. The logger considers actions carried out even at different times by different groups of users on the model. It is worth noting that, in the second version of the tool, we decided not visualising anymore the lock/unlock events generated when an authorised user performs a model modification, in order to avoid too long lists of events. Indeed, the lock/unlock events are very frequent and in any case a graphical feedback is provided to users in the main area of the application to highlight the occurrence of such events.

Coordination between users collaboratively handling a task model

One further issue addressed in this work has been how to design flexible collaborative editing while supporting an efficient and coordinated way to work. This has been addressed by considering the typical hierarchical structure of task models. In order to support flexibility, users are for example allowed to change at the same time parts of the tree-like task model structure that are independent each other, which means that there is no intersection between the subtrees currently modified by the users. Indeed, modifying a task can involve different types of possible changes, e.g. the user can delete the task and some/all of its children, change name, type, category, associated platforms, specify whether the task is iterative or optional, modify its description, associated objects and pre/post-conditions, if any. In order to coordinate the editing work, when a user is modifying a task, that task and its subtasks (in practise the subtree having as its root the task currently edited) are 'locked' to avoid concurrent changes on that part of the task model by other users at the same time. When this locking mechanism occurs, all the other users participating in the collaborative session receive a notification of the lock and the locked task will be highlighted in red in their view of the task model so that they are aware that it will not be possible to edit it (see Figure 3) anymore until the other user unlocks it. When a user locks a task, a timeout is set so that if the lock is not released within the defined time interval then the system performs an automatic procedure to release all the locked tasks.

In particular, Figure 3 shows the user interface of Collaborative CTT (initial version) while modelling an ATM (Automated Teller Machine) system. As you can see, the logger panel, the voting system and the chat are located in the bottom part of the user interface and can be hidden when more screen area is necessary to edit the model. There are two users: John (on the left side), and Bill (on the right side). On the left side John selected the Access task and started editing it: in this way he locked the selected task and all its subtasks. This event is communicated to the server-side part of the environment, which updates the model and sends this information to all clients involved in the collaborative session. Each connected client receives the lock infor-mation and automatically updates the interface by adding a red background to the subtree locked (see Bill's view in Figure 3). When the tasks are locked other users cannot edit them.

When the editing is finished the locked tasks are released and all users are notified of the unlock operation. Moreover, users will also be notified of the changes in the task attributes in a temporary banner shown in the top area and in the event console log, if a new task has been added (the new task is highlighted with a blue background in the other users' view) or if a task (and its subtasks) is deleted. The user who plays the role of moderator also has the possibility to reject modifications carried out by other users when s/he deems them inappropriate. The rationale behind how we have designed the locking was rooted in the hierarchical nature of the task model specification. Since a high-level task is described hierarchically in terms of its sub-tasks, by locking the entire sub-tree we aim to prevent two users editing parts that are semantically tightly connected simultaneously.

In the initial version of the application the locking mechanism was activated as soon as the user opened the panel for editing the task (see an example in Figure 3, left side). However, sometimes users just open this panel to see additional information about the task and not necessarily to edit it, so these cases do not really require the use of a locking mechanism. Thus, in the second version we decided postponing the time when the locking mechanism is actually activated: it is carried out only when the user actually selects the operation to do (e.g. add/edit/delete task).

By considering in particular the target scenario of educational use in the classroom, and our experiences in the discussions carried out during task modelling activities, we noticed that often there is a need for sharing the same focus on the task model. During a collaborative session, it can happen that different users select different tasks and have different model layouts in front of them at the same time, depending on the task currently having the focus. This supports a flexible way to work but at some point there could be the need to discuss some specific parts of the model, and thus it is important that all users have the same model layout in front of them with the part under discussion shown in the central part of the working area. In Collaborative CTT this is achieved through the possibility to set a shared focus. This operation allows all users participating in the collaborative session to coordinate their focus on a particular task (only if they have the corresponding authorization). The selected task will be placed in the centre of their working areas, it will be highlighted in green and the icons associated to this task and its immediate siblings will be enlarged, while the presentation of the neighbouring tasks gradually decrease in size when progressively moving further away from the task that currently has the focus.

Supporting communication between users

In the collaborative application we provided support for communication between the participating users by means of a chat, which is especially useful when the involved users are not in the same place. Figure 3 shows the chat (in the first version of the tool). In the second version we provided users with the possibility to interactively select tasks within the chat. By means of typing the [task] keyword within the chat, the tool shows a list of the tasks included in the currently task model, from where they can interactively select the task to refer within a conversation. In addition, if the user types some letters of the task name the list of the task names is automatically filtered accordingly. After the message is sent by a user, it is added to the chat area of all users. If a chat message contains a task identifier this is shown as a link, which can be selected in order to place the corresponding task in the centre of the working area.

Within the application we also provided users with a voting system, which can be useful to make a decision when there are different views on how to address a specific aspect of a task model. It allows a user to propose a topic for the vote, which is shown to all users who can express their agreement or not, and finally shows the result. If the topic concerns a task, selecting the task name in the topic description makes it possible to centre the model in the personal view around such task. It is worth noting that in the evaluations reported in this article the voting system was not used because just two users were considered for each test session.

Cloud Support for sharing task models

Users who collaboratively edit a task model may be located in various places and using different devices, thus we decided making the models shared in a collaborative session available in the cloud. In particular, all the users have a private repository and also have access to a shared repository in which the models collaboratively shared by users are saved. It is worth noting that, since the task models created through Collaborative CTT and those created through Desktop CTTE share the same XSD schema describing the underlying language, users can indifferently use Collaborative CTT and desktop CTTE for accessing the models contained in their spaces.

Implementation

From the implementation point of view Collaborative CTT has been obtained by applying the Model View Controller (MVC) pattern. The model is the task model description stored in the server-side. Each user request that implies some modification in the task model is sent to the controller (server-side), which manipulates the model and sends back the response to all involved clients that update their view accordingly. All the communication involving the collaborative functions exploits Web socket mechanisms that allow pushing information from server to clients avoiding polling. When a user accesses Collaborative CTT, a Web socket connection to the server is opened and the client subscribes to receiving updates about collaborative functions (such as shared focus, current users focus, temporal operator update, add/edit/delete a task, chat messages, propose or vote a topic) specifying the corresponding callback function that will handle the received information.

USER FEEDBACK

Two formative tests were conducted to collect user feedback on the usability and usefulness of the features provided in the tool, and receive suggestions for improvements. In both cases the tests were carried out in pairs.

In the initial test the two users were in the same room, while in the second the two users were in different rooms. Thus, the first evaluation addressed the same time/same place setting, and represents the first (but also the second) scenario, whereas the second evaluation covered the same time/different place setting (distributed synchronous workgroup scenario). For the initial assessment we deemed it more useful to deal with users in the same room to better control the experiment and more easily monitor the users' behaviour.

The second test was carried out with a version of the tool which had undergone some small refinements as a result of the first formative test in order to improve its usability. In particular, in the second version we reduced the time when a task is actually locked in order to increase the possibility for users to work in parallel, we refined the chat (which was not used much during the first exercise), and we improved the mutual awareness between users by also showing where the local focus of each user was positioned. The purpose was not to provide a formal comparison between the two tests because various conditions changed, but to obtain progressive feedback that has been useful to orient the evolution of the tool.

5.1

Participants and Tasks

Initial test

Fourteen people (2 females) aged 25 to 47 (M =32.2, SD =6) participated. All had good experience/familiarity with CTT. They were selected by using the professional network of authors, choosing people having familiarity with CTT notation and potentially interested in the tool. In the end, a pool including experts in HCI (e.g. academic researchers) and Computer Science students (with familiarity with CTT) participated in the evaluation exercise. For the test, users were asked to edit a previously created task model, which describes an ATM system in its "current" design. By using the tool, they had to edit this task model in a collaborative manner so that the new model would describe a possible, envisaged, "new" ATM system. The description of the features that the new system should support (and which they had to include in the model), were provided to them through four tasks to carry out.

In particular, users were required to include the specification of the following tasks in the model: i) add the possibility to access the ATM system using additional modalities apart from the current one (which is typically done through inserting a card and then typing in the code), namely: using either fingerprints, a smartphone or a smartwatch; ii) once a user has logged in to the system, the presentation should adapt by means of e.g. enlarging the fonts, improving the contrast, removing elements in the UI; iii) once the user has selected withdrawal, the system should calculate the amount that the user typically gets and then suggests it to the user, who can accept it or not; iv) the possibility to visualise the current user balance and see the transactions made during a certain interval of time (the user would have to choose a timeframe from: today/1 week/15 days/1 month). After jointly accomplishing such tasks, users had to independently fill in an online questionnaire.

Second test

We were not able to involve four of the 14 people who participated to the first user test, so in the end only 10 users (2 females), aged 25 to 47 participated in the second test (M =33.4, SD =6.2), all having quite a good experience/familiarity with CTT.

For the test we asked the users to edit a task model containing a partial specification of the features typically supported by a smartphone (e.g. enter a pin to access, make a call, handle messages). In the test, users were requested to edit the task model so that it will also include additional possibilities according to the following tasks. Task1: refine a task named "Show General Information" by further showing the time, the battery level and the network connectivity level. Task2: edit the "HandleMessages" task by modelling the tasks supporting users while they create a message to send to a contact. In our case, only two types of messages were considered: SMS and Whatsapp messages. Users had to model the fact that, in both cases the user can use text to create the content of the message. However, in the case of SMS messages, the user can also send, attached to the textual message, memos, contacts, calendar events, and notes. In the case of Whatsapp messages, the user can send additional types of files: images, videos, and audio files (in addition to memos, contacts, calendar events, and notes). Task3: add the possibility that a telephone call can occur any time during the use of the phone and then interrupt any task the user was currently doing with the smartphone. At the end of the telephone call, the user should be able to continue the interaction suspended previously.

As in the previous test, after jointly accomplishing such tasks, users had to independently fill in an online questionnaire.

Procedure and Design

Before the tests, the users were provided with instructions about how to access the tool, a general textual introduction, and a video showing its main features. In both tests users performed the test in pairs. For the first test they were in the same room, each using a PC, and they were placed in such a way that they could easily talk to each other, but could not see the screen of the other participant. They were allowed to talk and chat freely during the test. For the second test, the two users were in different rooms, still using the same equipment as in the first test (PCs). In both cases, two researchers observed the interactions occurring during the experiment.

One of the users initially acted as the moderator, inviting the other user to join the collaborative session: in this condition the two users completed the first two tasks, and then they swapped their roles. This was done in order to have both users act in both roles and test the corresponding functionalities.

After the test, the users filled in a questionnaire, which included first a demographic section (about e.g. education, experience/familiarity with task modelling), and then a section with questions specifically related to the tool.

Results

In the questionnaire, a 5-point scale was used to provide ratings on the tool features: [1 to 5; 1 = not usable at all/not useful at all, 2 = not very usable/not very useful, 3 = neutral, 4 = usable/useful, 5 = very usable/very useful]. We report the median and Interquartile Range (IQR) values.

Setting shared focus. First test. Usability [Median=4

; IQR=5-3.25=1.75] Usefulness [Median=4.5; IQR=5-4=1]
Many users found this mechanism useful (one user even suggested extending it to temporal operators) for better turning/pointing the team's attention toward a specific task-related issue/discussion, and especially useful to quickly focus on a task when dealing with large model specifications. However, from the usability point of view, one user found the provided mechanism difficult to understand since it requires two actions (clicking on the task and then select the button for setting a shared focus). Another user suggested making the visualisation of the shared focus different from the user's own focus (although each user has only one focus at any given time), to better distinguish them. There was only one user who explicitly criticised having his current focus changed by others: instead, he would have preferred to see where the other users currently had the focus and then decide to change his own focus accordingly. The second version of the tool addressed this issue to some extent by providing the possibility to show also the local focus of the other users.

Second test. Usability [Median=4; IQR=4.75-4=0.75] Usefulness [Median=4.5;

IQR=5-4 =1]

A user said "sometimes I forgot that the other user had set the shared focus, thus I made modifications to a wrong subtree." Another user said that he would have liked to use the mouse right click to access the button to activate the shared focus instead of using the menu in the top-right part of the application. Regarding the usefulness of this functionality, one user suggested further testing this functionality with more than two users. Another user had qualms about the fact that when using this functionality the overall interaction would slow down a bit.

User authorisations. First test. Usability [Median=4; IQR= 5-4=1 ] Usefulness [Median=4.5; IQR=5-4 =1 ]

Two users would have preferred a different, more compact layout for their settings (e.g. one row per user, using checkboxes or toggle switches).

Second test. Usability [Median=4

; IQR=4-4=0] Usefulness [Median=4.5; IQR=5-4 =1]
Nothing was particularly noted apart the fact that, in line with what had already been highlighted in the previous test, a user suggested having a more compact layout for visualising users' access rights (he suggested using accordion menus).

Mutual awareness mechanisms. First test. Usability [Median=4; IQR= 5-4=1 ] Usefulness [Median=4; IQR=5-4 =1]

Users were asked whether it was easy for them to be aware of other people participating in the same session and their current activities (e.g. understand when another user joins a collaborative session, or be informed of the actions that other users are doing/have done on the shared model). Overall, users expressed high appreciation of the usefulness of the support provided by the tool allowing them to be aware of other users' activities. Nonetheless, three users recommended some further improvements to its usability, with different suggestions: one proposal was to associate a colour to each participant to more easily identify users in the same session (and also the user who currently acts as the moderator), and/or to identify the current users by changing different portions of the task model; another user suggested using a short sound to signal when a new user joins a session; another user suggested using a small square around the graphical task representation and then identify the users who are currently focusing on that task by displaying their names (or initials) beside the square. Some of these aspects were addressed in the second version. In the second test one user expressed concerns over the possibility that using the users' initials could cause conflicts, and so suggested using icons rather than initials. Another user raised the issue that it is difficult to know who the users currently connected in the session at any given time are. Another user said: "As 'Owner' of the task, I received an overwhelming amount of notifications of task modifications, which interrupted my work several times. I suggest collecting all the notifications into a side box, in order to not block the owner's work."

Chat. First test. Not evaluated in the first test because users were in the same room.

Second test. Usability [Median=4.5; IQR=5-4=1] Usefulness [Median=5; IQR=5-5 =0] One user raised an issue connected with the fact that it was difficult for the moderator to discuss a modification to the model suggested by another user before accepting/rejecting it. In addition, the same user said "When the chat window is minimized, every time I receive a new message/ information about a new event, I must maximize it in order to read the message/event notification. I suggest that you write (the first part of) the event notification / text message in the window header. In this way, while the chat window is minimized, I can get an idea of the event notification / message" Other two users also highlighted the importance of better drawing the user's attention to the most recent message (e.g. by blinking for a few seconds). A user suggested having the possibility to have a voice chat for more easily communicating with the other users.

Visualisation of logged events. First test. [Median=4; IQR=5-4 =1 ] Usefulness [Median=4; IQR=4-4 =0 ]. This feature received quite mixed comments. On the one hand, one user found it very useful and reported looking more often at the area dedicated to event logging than the one showing the model. Nevertheless, the user suggested better structuring the visualization of the logs, by indicating, for example, first the type of event and the author, in order to speed up the extraction of relevant information. On the other hand, a pair of users said that they did not look much at this panel, while one highlighted the usefulness of this feature especially for remote users. Indeed, users often talked to each other, not only to identify a shared strategy for editing the task model, but also to request confirmation of actions made through the tool (instead of just checking the event log). Another user suggested rendering just the editing events in the panel (e.g. not providing information on the locking events), since they are the really meaningful ones from the user's perspective. Another user suggested adding the possibility to go through past events and even 're-play' them.

Second test. Usability [Median=4; IQR=4-3 =1 ] Usefulness [Median=4; IQR=4.75-3 =1.75] Two users suggested hiding it by default and having the possibility to show it on request. Another user said that he noticed some changes sometimes but then he pre-ferred looking at the model to understand what happened. Another user suggested classifying the events, by distinguishing between events occurring on the task model and other types of events (e.g. chat modifications, notifications about user joining the session, etc.) Coordination (lock mechanism). First test. Usability [Median=4.5; IQR=5-3=2] Usefulness [Median=5; IQR=5-5=0]. Users really appreciated the availability of the locking mechanism to avoid including inconsistencies in the model due to concurrent and uncontrolled modifications. However, some users highlighted that the lock mechanism can slow down the collaborative process excessively, suggesting keeping it only for the time that it is strictly necessary (e.g. when the user actually starts modifying some property of the model, and releasing it just afterwards).

Second test. Usability [Median=4; IQR=5-4=1] Usefulness [Median=5; IQR=5-4 =1]

A user complained that, as the moderator of the session, he received many notifications about task changes, which made it difficult to work on the model properly: "As owner of the task, I received many notifications of task modifications, which interrupted my work several times. I suggest collecting all the notifications into a side box, in order to not block the owner's work." ." Another user said that the locking mechanism could be difficult to handle, he suggested better using the chat for coordinating the work.

Rejection/Acceptance. First test. Usefulness [Median=4; IQR=4.75-4 =0.75 ] On the one hand, users acknowledged the need and the importance of providing the moderator with the possibility to act as "super-user" to decide on the modifications to actually apply to the model (among the ones proposed by other users), and then maintaining the control of it. Nonetheless, two participants suggested providing the moderator with some means for justifying rejection of a proposal made by another user (e.g. by means of adding a text field where the moderator can explain the reasons for rejecting a change), so that all members can develop and keep a shared mutual knowledge/view of the correctness of the specification (documented in the model) and its rationale and evolution. On the other hand, confirming every step done by the other partners was judged a bit tiring from the moderator's point of view (a user admitted sometimes having lost his own focus to check requests of change from the other user).

Second test. Usefulness [Median=4; IQR=4.75-4=0.75]

Two users acknowledged its usefulness but at the same time they highlighted that the moderator frequently had to interrupt his work to deal with accept/reject requests. Another user pointed out the fact that when a request arrives, the user cannot discuss it with the partner but just accept/reject it.

Most usable functionality and Least usable functionality. First test. The functionalities that were most appreciated from a usability point of view were the shared focus (seen as a way to have a better "organised" collaborative session), and the possibility to concurrently modify a model. Among the least usable functionalities, users reported the locking mechanism ( which could slow down the collaborative editing), and the event log list (not particularly structured and currently including events not very meaningful from the user's perspective).

Second test. Four users particularly appreciated the chat (which was improved), one user most liked the fact that the task model portions been edited by other users are highlighted graphically. Regarding the least useful functionalities, one user mentioned the logger, and two mentioned the locking mechanism.

Most useful scenario(s) of use. First test. For assessing this aspect we envisioned four basic scenarios of use (corresponding to those introduced in Section 3) and we asked users to select the scenario(s) (one or more than one) they found most suitable for exploiting the features of Collaborative CTT. The usage scenarios which received the highest approval were: distributed workgroup (selected 10 times) and workgroups aiming at designing an application (10 times as well). The educational scenario was also rated highly (9 times). The scenario that was judged the least useful was the different places/different times scenario (2 times). In any case, the tool was judged by users as highly flexible in supporting rather different scenarios. From users' comments it seems to offer the best opportunities when synchronous (same time) scenarios are to be supported. An advantage highlighted by users is the fact that, by using the tool, users do not need to exchange task model specifications. The educational setting was also judged appropriate for using the tool because in such settings the tool is able to support a good interaction between the teacher and the students while facilitating the work of both. In other words, Collaborative CTT facilitates teachers explaining task models (by using e.g. shared focus functionality and being a Web-based tool) and at the same time it makes possible an active and collaborative participation of students in building task models, giving them the opportunity to put in practice and apply the theoretical knowledge gained in concrete examples.

Second test. One user said that the tool can be fruitfully used in all the four mentioned settings. However, for a future version of the tool he suggested improving that the mechanism used by the moderator to accept/reject the suggested modifications because it is time consuming (and thus he has less time available for working on the model). One user declared that the application should fit all the target scenarios, especially the "same time/different places" one. Another user declared that the Educational use fits particularly well. However, also other settings are suitable, but in these cases there should not be anyone needed to confirm/reject the changes of other members.

Further suggestions. First test. One user suggested adding a non-transparent background when the circular menu for task editing appears, in order to avoid visualisation problems between the circular menu and the task model visualised underneath. Additional suggestions included adding a voice chat in the system and using sounds for notifying important events. Second test. A user suggested removing the locking mechanism and increasing mutual awareness through user icons; another user suggested adding the possibility to edit tasks with drag-and-drop; another user suggested enabling right-click when possible.

Discussion

First test. Overall, the results of the test show that Collaborative CTT was appreciated although some aspects (e.g. the lock mechanism and the limited level of mutual awareness) should be subjected to further refinement. Participants especially liked the flexibility provided by the tool in supporting different types of scenarios of use, the most promising ones being when users exploit the tool in a synchronous manner. Another aspect that users particularly liked was the possibility to work (through a Web-based tool) on the same shared model in a concurrent yet organised/controlled manner. In this way the possibility of reworking and duplication as well as the need of exchanging models between members should be reduced, thereby leading to faster and more productive task modelling sessions. As evaluators, we noticed low parallelism between users (i.e. when one user started to edit one task the other rarely started editing another task). However, this can be explained by the users' low familiarity with the tool, and the fact that they tended to follow the sequence of test tasks strictly. Participants verbally discussed the strategy to follow to build the task model for satisfying the test requirements and, being in the same room, they did not use the chat much. Nonetheless, they fruitfully used other tool features (e.g. shared focus) to coordinate their activities during actual editing.

Second test. The researchers noticed increased parallelism among participants: in all the tests users started to work on different tasks from the beginning and then they used the tool features to coordinate/verify their work for finally satisfying the test requirements. This enabled us to test the appropriateness of the tool in situations where users actually edit different parts of the model in parallel. This improved parallelism was probably due to two factors. The first one could be greater users' familiarity with the tool: users felt more confident controlling the tool and its features, and therefore exploited it in a more flexible manner. Another possible explanation could be that the remote chat-based communication used in the second experiment was slower than the direct communication used in the first test, therefore users were further stimulated to more efficiently and concurrently edit the model to save time. Nonetheless, the comments received suggest further refining the mechanism supporting the modifications made to the shared task models, which currently may overload the work of the moderator, especially when many requests for modifications have to be analysed in a short time.

Figure 1 :

 1 Figure 1: Example of multiple views of the same task model

Figure 2 :

 2 Figure 2: Task models annotated with representations of the local focus of the other users

Figure 3 .

 3 Figure 3. Example of task modification in Collaborative CTT.

  Second test. Usability [Median=4.5; IQR=5-4=1] Usefulness [Median=5; IQR=5-5 =0]

https://www.eurocontrol.int/ehp/?q=node/1617

CONCLUSIONS

Currently, most of the automatic environments enabling task modelling only support single users, thus limiting the possible interactions and discussions amongst them. In this paper we present a new Web-based multi-user tool for specifying task models. Among its features, the tool includes relevant mechanisms supporting coordination, communication and mutual awareness between participants. In the paper we discuss the aspects we have addressed in designing the collaborative features in a task modelling tool, what type of mechanisms have been developed for their support, and also report on two formative user tests which provided promising feedback, also identifying aspects that could be subject to further refinement. A video showing the tool is available at https://www.youtube.com/watch?v=AapwdNIz5V8&feature=em-share_video_user.

Future work will be dedicated to further empirical testing in both educational and industrial projects.


Jil Klünder
email: jil.kluender@inf.uni-hannover.de

Kurt Schneider
email: kurt.schneider@inf.uni-hannover.de

Fabian Kortum
email: fabian.kortum@inf.uni-hannover.de

Julia Straube
email: julia.straube@tu-bs.de

Lisa Handke
email: l.handke@tu-bs.de

Simone Kauffeld
email: s.kauffeld@tu-bs.de

Communication in Teams -An Expression of Social Conflicts

The more members a team has, the more information needs to be shared with single team members or within the whole team. Sufficient information sharing is difficult to ensure, since a project leader will not be fully aware of all on-going information and communication within the team. In software engineering, information flow is essential for project success. In each part of the process, information like requirements or design decisions needs to be communicated with appropriate persons. Neither missing nor wrong implemented requirements are desirable, since extra working hours or incomplete working results need to be paid. Therefore, the right amount of information sharing is highly desirable. To ensure this, communication is a mandatory requisite. Furthermore, knowing about social conflicts is suitable, since these influence the information flow. In an experiment with 34 student software projects, we collected data referring to internal team communication and mood. In these projects, we could show a correlation between chosen communication channels, social conflicts and mood. Since social conflicts foster an insufficient information flow, knowing about these helps software developing teams to reach higher quality and a higher customer satisfaction.

Introduction

Ensuring the right amount of information sharing with all involved persons is often difficult. Some information only needs to be communicated with a few team members, while other information needs to be shared within the whole team.

In software engineering, the impact of "appropriate" communication on project success has been discussed frequently (e.g. [START_REF] Schneider | Media, mood, and meetings: Related to project success[END_REF] [START_REF] Pikkarainen | The impact of agile practices on communication in software development[END_REF]). Both, the communication with the customer and the inner team communication require special attention to provide high quality project results with well performing functionalities [START_REF] Kauffeld | Meetings matter effects of team meetings on team and organizational success[END_REF]. Communication is important for working in groups. Furthermore, motivated by the importance of information sharing within the project team, communication has been proven to be a determinant of project success [START_REF] Kraut | Coordination in software development[END_REF].

In software developing teams, wrong or insufficiently transmitted requirements often cause wrong or not implemented parts of the software [START_REF] Schneider | Requirements compliance as a measure of project success[END_REF]. Therefore, insufficient communication can threaten project success. Otherwise, adequate communication can foster project success. Hence, a good working communication is desirable for all project members: The developer team that does not want to spend time on implementing unnecessary program code, the project leader who wants to complete the tasks, and lastly the customer who wants a successful project. But not only requirements need to be shared within the team. Also design decisions, customized standards, reports about bugs and many other information need to be transported to the relevant persons.

As Stapel [START_REF] Stapel | Informationsflusstheorie der Softwareentwicklung[END_REF] pointed out, not only the intensity of communication, but also the chosen communication channel is important for transmitting the desired information. In the "Modes of Communication", Cockburn [START_REF] Cockburn | Agile software development: The cooperative game[END_REF] rated different kind of communication channels by their effectiveness and richness. Among other characteristics like synchronicity, the perceptions addressed by the media channels are one factor for the grading. For example, meetings with face to face communication -in physical support with a white board -are the most effective way to communicate [START_REF] Ambler | Agile modeling[END_REF] [START_REF] Cockburn | Agile software development: The cooperative game[END_REF]. As teams often do not have the opportunity to meet regularly and since meetings often do not suffice for conveying the entire information at hand, other ways of information sharing need to be used. In practice, common alternatives are services like email, video chat, telephone or group and single chat.

Schneider et al. [START_REF] Schneider | Exploring FLOW distance in project communication[END_REF] developed an approach to combine communication channels and the intensity. They used FLOW distance, which is defined to be a measure for the collaboration in teams.

In this contribution, we want to motivate the usage of FLOW distance by achieving a relationship between FLOW distance, and hence communication behavior, mood and social conflicts in software developing teams.

Along with the findings of Watson et al. [START_REF] Watson | Development and validation of brief measures of positive and negative affect: The PANAS scales[END_REF], mood can be described using positive and negative affect. While persons in a state of high negative affect feel anger, disgust and fear, persons in a state of high positive affect feel active, enthusiastic and alert [START_REF] Watson | Development and validation of brief measures of positive and negative affect: The PANAS scales[END_REF]. The affects of persons working in groups converge over time, meaning that the mood of all team members assimilate [6][32]. This assimilation influences team performance as well as important process variables: For example, Barsade [3] was able to prove that positive group mood is associated with better performance and less conflicts.

This paper concentrates on the positive affect dimension, as we assume that positive group mood facilitates action (cf. [START_REF] Kuhl | Volitional facilitation of difficult intentions: Joint activation of intention memory and positive affect removes stroop interference[END_REF]) and will thus be beneficial, especially at the beginning of the project.

We are able to show that summarizing the chosen communication channels and the communication intensity using FLOW distance has a relation to social conflicts and mood. The FLOW distance between two members measures the indirections and barriers hampering the information flow when they communicate. Given by the intuitive comprehension of distance, FLOW distance increases with a decreasing collaboration and with the usage of non-direct communication channels and vice versa.

In an experimental study on 34 student software projects, we show a correlation between FLOW distance, social conflicts and mood at certain stages of the project. Therefore, an increasing FLOW distance can be seen as indication for difficulties within the team. Therefore, observing FLOW distance may be helpful for the project leader. It helps assuming problems within the developing team and working against lack of information sharing. In the case of a well-working communication, the project leader finds out that there is no reason to modify or adjust the used media channels.

The structure of this article is as follows: In the following section 2, we give an overview of related work in similar topics. In section 3, we motivate and give the definition of FLOW distance with its properties and the way of calculation. Afterwards, we validate our approach in section 4, followed by section 5, in which we discuss the results. Section 6 summarizes our work.

Related Work

The relationship between communication intensity, communication channels and project success has been studied for a long time in software engineering. This chapter gives an overview about already existing approaches in certain topics which are related to this paper: The combination of social network analysis with the FLOW method to analyze information flows and the distance, i.e. collaboration, within the team referring to the communication intensity of a co-located working software developing team.

The idea of combining social network analysis and communication intensities is not entirely new. In the context of the collaboration within a team, Damian et al. [START_REF] Damian | Collaboration patterns and the impact of distance on awareness in requirements-centred social networks[END_REF] studied the awareness among team members in global software development teams using methods of social network analysis. They found a positive correlation between communication and awareness within so-called requirements-centered social network analysis.

Additional work often refers to team communication centralization that indicates the degree to which communication is focused on a subset of participants or even a single person. High centralization can be considered as an indication of unequal communication participation (for other network measures of participation, such as Maverick score, see [START_REF] Prikladnicki | Propinquity in global software engineering: examining perceived distance in globally distributed project teams[END_REF]). Centralization of communication compiles structural and quantitative elements (weights) into an indicative number. It is a widely-used metric in social network analysis.

Sauer et al. [START_REF] Sauer | Meetings as networks: Applying social network analysis to team interaction[END_REF] applied social network analysis to team interaction. They investigated the calculation of centralization for various kinds of small group interactions. After having conceptualized group discussions as networks, they were able to present a metric calculating a centralization for these networks using extensions of Freeman's metrics for centrality measures [START_REF] Freeman | Centrality in social networks: II. Experimental results[END_REF]. In the end, they examine the relationship between team performance and centralization of the interactions during the meeting.

In software engineering, Wolf et al. [START_REF] Wolf | Predicting build failures using social network analysis on developer communication[END_REF] also applied social network analysis to team communication structures. They wanted to indicate the importance of developer communication for software integrations. In order to reach this aim, they used well-elaborated measures like density and centrality in general as metrics.

The FLOW method serves for visualizing and analyzing information flows in project teams. It was introduced and presented by Stapel et al. [START_REF] Stapel | Using FLOW to improve communication of requirements in globally distributed software projects[END_REF]. The general structure of communication within the team is extended about the state of information flow: Solid information summarize all information that is repeatable, long term accessible and comprehensible for third parties, whereas fluid information is everything which is not solid.

Although most research concerning the distance in teams refer to distributed software developing teams, there are some approaches that are comparable to our approach, which focuses on co-located teams.

Bjarnason [START_REF] Bjarnason | Distances between requirements engineering and later software development activities: A systematic map[END_REF] identified different variants of distance in software engineering literature. She stated that distance plays an important role in both, distributed and co-located software development. In her systematic literature review, she found eight different distances between people, i.e. within the team, also including the geographical distance. In the context of this contribution, Bjarnason's results concerning the socio-cultural distance including among other things organizational and national culture, language and individual motivations, opinion distance and organizational distance are important. The most important results are those related to the psychological distance. Prikladnicki [START_REF] Prikladnicki | Propinquity in global software engineering: examining perceived distance in globally distributed project teams[END_REF] has denoted psychological distance as a "measure of the perceived psychological (subjective) effort of an actor to communicate with another actor" [START_REF] Bjarnason | Distances between requirements engineering and later software development activities: A systematic map[END_REF].

There have already been various researches relating to FLOW distance. Schneider et al. [START_REF] Schneider | Exploring FLOW distance in project communication[END_REF] presented a first approach of defining and using FLOW distance. The authors evolved the idea of a "perceived distance" generated by the communication intensity and a certain weighting of the used communication media. Schneider et al. considered FLOW distance as "the number of weighted indirections between source and target of an information flow" [START_REF] Schneider | Media, mood, and meetings: Related to project success[END_REF]. In the present contribution, we will refine the definition and motivate this approach by pointing out a relation between FLOW distance, social conflicts and mood.

FLOW distance is a metric combining communication intensity and used media. Exploring the information flow within a project, FLOW distance simplifies the detection of the wrong amount of communication and therefore indicates problems in information sharing. Considering the FLOW distance enables strategic changes in the way of communication (for example by adding an obligatory meeting each week) and hence a better flow of relevant information.

In this contribution, we want to elaborate the already existing definition of FLOW distance (cf. [28][26]) restricted to a static network of a single software developing team consisting of three to five co-located working members. We want the measure to consider the used media and the subjective communication intensity between two persons within these teams. FLOW distance can also be used to analyze the structure of a team using social network analysis.

The requests and restrictions can be summarized as follows:

-FLOW distance should consider the communication intensities and the used media.

-It shall increase with a decreasing collaboration and vice versa.

-It has to be practicable, i.e. it needs to be easy to calculate and the input data need to be collectable with low effort. -For later research, it needs to be extendable towards bigger software developing teams and to FLOW models 3 .

Fulfilling these requests yields to a few more definitions and analyses before giving the definition of FLOW distance.

1. Creating a mathematical model of FLOW distance which allows a precise and well-founded definition. 2. Weighting the used media with respect to their effectiveness and richness. This needs to be done at least for the common used communication channels "meetings (F2F)", "video chats", "chats", "emails" and "phone calls". 3. Defining and calculating the communication intensity only using easily collectable data. 4. Giving the definition of FLOW distance and using it for calculation. These steps will be executed in the course of this chapter.

Mathematical View

We consider FLOW distance as a mapping d : A×A → [0, 1], where A denotes the set of all team members and [0, 1] is the unit interval 4 . We understand FLOW distance as a metric from a mathematical point of view, i.e. it is (i) positive definite, (ii) symmetric and (iii) the triangle-inequality holds:

(i) positive definite: The measure is always greater than or equal to zero. It vanishes if and only if the two persons are the same, i.e. d(i, i) = 0 and d(i, j) = 0 ∀ i = j. This is useful, since there is no interpretation for negative distances between two members and having a FLOW distance of zero between to different members would mean that they spend the whole time together exchanging each thought. (ii) symmetric: Along the lines of Watzlawick's findings [START_REF] Watzlawick | Pragmatics of human communication: A study of interactional patterns, pathologies and paradoxes[END_REF], one cannot not communicate, meaning that also if only i sends many emails to j without receiving an answer, j communicates with i by receiving the emails. Therefore, the mapping d should be symmetric, even if the communication is one-directional. (iii) triangle-inequality: The FLOW distance between two team members i and k should be greater than or equal to the sum of the FLOW distances between i and j and j and k, i.e. d(i, k) ≥ d(i, j) + d(j, k). In the context of communication, this means that communicating via a third person let the distance between the two other persons increase.

Media Richness and Effectivity

We consider the common used communication media "email", "phone call", "video chat", "chat" and "meeting". Intuitively, the intensity and efficiency are the largest in meetings, followed by video chat, chat, phone and email. There are proper justifications to use this or a very similar grading of the media [START_REF] Figl | Team and media competencies in information systems[END_REF]. First of all, the more human senses the media addresses, the more information can be transported. One does not only communicate by speaking; the facial expression, the gestures and the voice are not less important than the used words [START_REF] Daft | Information richness. A new approach to managerial behavior and organization design[END_REF]. In meetings and video chats, most senses are addressed. In chats, emails and in phone calls, there is only written or heard text. This way, we get the following weighting: meetings = video chat > email = chat = phone call Furthermore, we should consider the synchronicity of the media [START_REF] Dennis | Media, tasks, and communication processes: A theory of media synchronicity[END_REF]. Meanwhile meetings, chats, video chats and phone calls are instantaneous, emails often need much time until the receiver answers them. Therefore, the weighting of emails should be smaller than the weighting of chat and phone calls, i.e. meetings = video chat > chat = phone call > email Due to the direct face-to-face communication without screens or bandwidth (potentially limiting the information flow) and the interactions of team members in one room, the importance of meetings should be bigger than the importance of video chats. Therefore, we get the following final order of the efficiency and effectivity of the media: meetings > video chat > chat = phone call > email Table 1 reflects the weighting of media gained by starting with 1 and increasing the weighting about one unit at each jump in the previous ordering. These weights will be used for calculating FLOW distance. Cockburn's [START_REF] Cockburn | Agile software development: The cooperative game[END_REF] and Ambler's [START_REF] Ambler | Agile modeling[END_REF] reflections support this ordering. In his "Modes of Communication", Cockburn proposes a grading of various communication channels referring to their "richness" and "effectiveness". Figure 1 represents these findings, which can be retrieved in the grading above.

Communication Intensity

Calculating the FLOW distance requires a certain kind of communication intensity. Therefore, each team member is asked to estimate the intensity of communication with respect to each other team member. This way, we gain a matrix of the following structure:

      0 a 12 a
     
where each a ij has a value between 0 and 45 . Ideally, this matrix is symmetric, i.e. a ij = a ji for all team members i, j ∈ A. But since the statements concerning the intensity are all subjective and there does not exist a (non-technical) objective reference, this matrix will probably never be symmetric. Therefore, we calculate the average of each a ij and a ji to gain the resulting communication intensity between i and j.

Calculation

To simplify the calculation of FLOW distance, let d ij = d(i, j) denote the FLOW distance between two team members i and j. To gain a comparability between FLOW distances of different teams, we want to restrict the image of d to the unit interval. Therefore, we need a certain kind of normalization.

As variables, we only need a list of used communication channels written by person i respectively j and the perceived communication intensity.

In a first step, we calculate the product c ij of the communication intensity and the sum of the weightings of all used media. For example, if two persons have communicated using chats (2), emails (1) and a face-to-face meeting (4) with an average perceived intensity of 4, we would calculate 4 • (2 + 1 + 4) = 28, where 2, 1 and 4 represents the weightings of the used media (see table 1). Then, FLOW distance d ij is given by

d ij = 1 - c ij c * ,
where c * denotes the theoretical maximum of c ij within the regarded team constellation. In a team with five members using meetings, video chats, chats, phone calls and emails, c * would be calculated as

c * = 4 • (4 + 3 + 2 + 2 + 1) = 48,
where 4 is the maximal possible communication intensity.

Looking at the example of above, the FLOW distance is

d ij = 1 - 28 48 ≈ 0, 4167.
The FLOW distance of the whole team, d, is given by the average of the FLOW distances of the team members, i.e. d = avg{d ij : i = j ∈ A}.

FLOW centralization

Using FLOW distance calculation, we can create the FLOW centralization which gives an overview for the structure of the team. As centralization and centrality are common measures in psychology and social network analysis to analyze team structures and the collaboration, FLOW centralization can be applied to further calculations in social network analysis. We start with an upper triangular matrix D, where the entry d ij is given by the FLOW distance between the members i and j. The FLOW centralization is then calculated as follows:

We get the FLOW centrality of a person j by summing up over all FLOW distances between this person and all other team member, i.e.

centrality(j) = i∈A d ij ,
where A again denotes the set of all team members and d ij is the FLOW distance (respectively the entries in D). The higher a person's centrality, the closer he or she is generally to the other team members.

Let now centrality max denote the score of the team member who has the maximum centrality, i .e. where centrality * denotes the theoretical maximum of centrality.

Calculating centrality * bases on considering the star shape as network [START_REF] Freeman | Centrality in social networks: II. Experimental results[END_REF]. The star network has the largest centralization, which is why it is used to normalize the FLOW centralization. In this network, we weight each edge with c * , which is defined to be the most possible communication interaction (gained by using all media with the most perceived intensity). Figure 2 shows the star shape network with five persons. Considering not an individual's centrality, but the group centralization allows conclusions about the team internal structure6 : The higher the centralization, the more individual members communicate via one dominant actor rather than directly to one another.

Empirical Validation

To motivate the use of FLOW distance and FLOW centralization, we want to show the relationship between communication channels, perceived communication intensity and social conflicts.

As several studies have shown, a low degree in centralization appears to be beneficial for team performance [START_REF] Schneider | Media, mood, and meetings: Related to project success[END_REF] [START_REF] Sauer | Meetings as networks: Applying social network analysis to team interaction[END_REF]. As software projects are considered to be highly dynamic entities, communication structures may also be expected to vary over time [START_REF] Balijepally | Collaborative software development in agile methodologies -Perspectives from small group research[END_REF]. The project's midpoint may be particularly relevant in this case, as teams have been shown to display increased effort at this time [START_REF] Gersick | Time and transition in work teams: Toward a new model of group development[END_REF] [START_REF] Waller | Watching the clock: Group pacing behavior under dynamic deadlines[END_REF]. Furthermore, at this stage of the project, team structures also seem to change, as individual expectations and perceptions transform into shared group goals and understandings [START_REF] Jarvenpaa | Toward contextualized theories of trust: The role of trust in global virtual teams[END_REF] [START_REF] Gersick | Time and transition in work teams: Toward a new model of group development[END_REF]. Considering that team development during this point in time also involves conflict resolutions [START_REF] Jehn | The dynamic nature of conflict: A longitudinal study of intragroup conflict and group performance[END_REF], we assume that it will be influential on how teams deal with relationship conflicts throughout the rest of the project. We thus hypothesize that a higher degree of FLOW centralization in the middle of the project will also be associated with increased social conflicts later on. H1: The degree of FLOW centralization at midpoint will be positively related to the degree of social conflict at the end of the project.

Positive affect has been known to increase social integration, i.e. the extent to which people are positively linked to one another, as it can be linked to approachoriented and cooperative behaviors [START_REF] Knight | Positive is usually good, negative is not always bad: The effects of group affect on social integration and task performance[END_REF]. Furthermore, group affect seems to influence how members regulate their behaviors when facing a deadline [START_REF] Knight | Mood at the midpoint: Affect and change in exploratory search over time in teams that face a deadline[END_REF], such as a quality gate7 at project's midpoint. Interactions in early project stages have been shown to consist of long-lasting effects [START_REF] Gersick | Time and transition in work teams: Toward a new model of group development[END_REF] [START_REF] Zijlstra | Setting the tone: Early interaction patterns in swift-starting teams as a predictor of effectiveness[END_REF]. We thus assume that the degree to which the team's positive affect after their first meeting will influence the degree of FLOW centralization at midpoint. H2: The degree of the team's positive affect after the first meeting will negatively influence the degree of FLOW centralization at midpoint.

In line with Totterdell et al.'s [START_REF] Totterdell | Affect networks: A structural analysis of the relationship between work ties and job-related affect[END_REF] assertion that social networks act like conduits for affect to flow and converge through, we furthermore assume that positive group affect after the first team meeting will decrease the incidence of social conflicts at the end of the project via decentralized communication structures at midpoint.

H3: Centralization will mediate the relationship between positive affect after the first team meeting and social conflicts at the end of the project.

To validate these hypotheses, we conducted a study with 34 student software projects.

Student software projects

At Leibniz Universität Hannover, the Software Engineering Group offers a yearly repeating course called Software-Project (SWP), which is scheduled in the last (third) year of the computer science bachelor curriculum. Participating in this course is a requisite in order to complete the undergraduate studies. In this course, the teams mostly consist of five students developing a software for a customer, who is usually part of the software engineering group and who has a real interest in project success. The projects resemble industrial projects, but also consider the academic environment 8 . The students need to organize themselves, i.e. they need to coordinate the meetings with the customer, within their team, and with the advisors at the right time and in an appropriate way.

The teams get supported by a coach who is part of the software engineering group.

Within the 15 weeks of the fall semester, the students learn to work in a team, talk to the customer and organize the internal communication. To support them and to get the ability to obtain feedback, the teams had to pass three quality gates -after the requirements elicitation, after the design and at the end of the project.

The students are free to choose time and location for their meetings. They also autonomously decide on how often they meet and which communication channels they use.

With regards to the technical experiences in executing a project, teams need to elicit requirements, design, implement, and test their product. Thus, they pass through all common phases of the waterfall model. They need to write a requirements specification and either create a design or implement a prototype of the product. Co-located in the process, they furthermore make a review of the design respectively the prototype of another team. In the last step, they develop the software, which needs to be approved by the customer.

Study Design

In 2012 and 2013, a total of 165 students participated in the Software-Project. They worked in 34 teams mostly consisting of five persons. There was only one team consisting of four students, and two teams with three students. Each team worked together for a period of 15 weeks. Due to missing data, we had to exclude one team from the analyses. The final sample therefore consisted of 33 teams (160 individuals).

During the course, the students were asked to fill in questionnaires at three specific dates: after the initial meeting with the customer, after half of the project duration and at the end of the project. Questionnaires contained items on e.g. positive affect and social conflicts. We did not ask the students to report on the cause of conflict, but the mostly arising conflicts have been caused by different attitudes to work, reliability and different abilities to work in a team. Additionally, the team members filled out a weekly online-questionnaire referring to the interactions with other team members.

To assess the communication within the teams, we asked each team member to record his or her communication with each other member of the team. They were free to choose gradations between "not communicated at all" and "very high". We did not raise the frequency of the used communication media. During a whole week, the frequency influences the perceived intensity, so that measuring perceived intensity is sufficient for our approach. Furthermore, each team member stated the used communication media with respect to every other team member. The channels "in one room", "video", "chat", "telephone" and "email" were available. Additionally, the project leader was asked to state the duration of all meetings and the presence of each team member.

Ethics Committee

The ethics committee at Leibniz Universität Hannover authorized this elevation of data. We informed the students about the collection of data and the further usage. All data records were anonymized and the data did not influence the success of passing the course.

Methodology

Measures. Within the scope of this contribution, we used the following data:

FLOW centralization at midpoint of each project's total duration was measured using a communication score derived from data obtained via the self-report in week 7. Using the individual ratings of intensity and media, an undirected communication matrix for each team and for every week was obtained by averaging the two scores for communication intensity and by determining the maximum value for media use for each communication pair, and then multiplying these two scores (see section 3.5). As described by the formula (*) in section 3.5, FLOW centralization was computed in adding up the differences between the most central team member's centrality and centralities of all other team members and subsequently dividing them by the theoretical maximum score of 576 (288 and 96 for the teams with four or three members respectively).

Social conflict was measured using the German version of Jehn's [START_REF] Jehn | A multimethod examination of the benefits and detriments of intragroup conflict[END_REF] intragroup conflict scale by Lehmann-Willenbrock, Grohmann and Kauffeld [START_REF] Lehmann-Willenbrock | Task and relationship conflict at work[END_REF], adapted to the context of teams. The scale consisted of four items with a six-level range from 1 = "never/none" to 6 = "very often/very much". An exemplary item was "How much friction is there among members in your team?" The measurement was taken at the end of the project. The reliability value for this scale was α = .87.

Positive affect was measured using the German translation of the positive and negative affect scale (PANAS) [START_REF] Watson | Development and validation of brief measures of positive and negative affect: The PANAS scales[END_REF] by Kroehne et al. [START_REF] Krohne | Untersuchungen mit einer deutschen Version der "Positive and Negative Affect Schedule[END_REF]. The response format ranged from 1 = "not at all" to 5 = "extremely". The questions were answered after the first team meeting in week 1. The scale, which consisted of ten items, showed a reliability of α = .85.

To obtain group level constructs for social conflict and positive affect, individual scores were mean-aggregated to the team level. Data Analysis. Statistical procedures were performed using SPSS 22 (IBM Corp.). In order to avoid alpha error inflation, all three hypotheses were tested in one mediation model. The PROCESS-macro for SPSS by Andrew F. Hayes9 was employed for the mediation analysis.

While the path from the mediator (FLOW centralization) to the dependent variable (social conflict) was used to test the first hypothesis, the path from the predictor (positive affect) to the mediator (FLOW centralization) served to test the second. As both of these hypotheses are directed, we will later report the results of one-tailed hypothesis tests. The third hypothesis was tested in calculating the indirect effect from positive affect via FLOW centralization to social conflict. Figure 3 shows the hypothesized mediation model10 .

Positive Affect

Results

Table 2 shows descriptive statistics and intercorrelations among the variables under study. As table 3 shows, the unstandardized coefficient between FLOW centralization and social conflict was statistically significant (p = .007/2 ≈ .004). The first hypothesis was thus supported. Showing a clear negative tendency, the relationship between positive affect and FLOW centralization also reached statistical significance (p = .063/2 ≈ .03). The second hypothesis was thus also corroborated. The relationship between positive affect and social conflict was mediated by FLOW centralization. We tested the significance of this indirect effect using bootstrapping procedures. Unstandardized indirect effects were computed for each of 1000 bootstrapped samples, and the 95% confidence interval was computed by determining the indirect effects at the 2.5th and 97.5th percentiles. The bootstrapped unstandardized indirect effect was -.3551, and the 95% confidence interval ranged from -.9553 to -.0169. Thus, the indirect effect was statistically significant, supporting hypothesis 3.

Discussion

In this section, we consider the study's limitations and threats to validity before interpreting and discussing our findings.

Limitations and Threats to Validity

Referring to our evaluation with students, we had to make some limitations with regards to the real world. These limitations may threaten the validity of the collected data and therefore influence the results of our calculations. Along with the classifications of threats to validity by Wohlin et al. [START_REF] Wohlin | Experimentation in software engineering[END_REF], we divide the threats into construct, external and internal validity and reliability.

Internal validity: We wanted to consider the changes over the course of the projects. Therefore, all threats concerning the internal validity (e.g. maturation, internal interactions and talking about the project, the questionnaires and the collected data) were desired and to some extent even necessary.

External validity: Although there are some modifications of the student projects towards industrial standards, the academic environment still influences the scope and the duration of the projects. The ability of working together in a room each week was supported by the academic environment, since all students mostly worked at university and have been there five days per week. Project leader were not able to access to a big pool of experiences, since they possessed the same amount of experiences as the rest of their team. Therefore, a coach of the software engineering group supported the teams, when any social, i.e. interpersonal, problems occurred. Furthermore, we only considered projects with a duration of 15 weeks with small teams (3-5 members). Almost all participants had the same background in theory and the team internal experiences and knowledge was comparable in all teams. This was given by forming the teams deliberately. Beside these threats, there are no more relating to the external validity.

Construct validity: We formulated the questionnaires for the students in a general manner and used reliable gradations and items. But we still cannot ensure that our comprehension of the items correspond with the student's comprehension. We tried to minimize the impact of this wrong understanding through the presence of one of the researchers involved in the project while the students filled out the extensive questionnaires. This threats arose by comparing the perceived communication intensities (the communication matrices have not been symmetric), for instance. We respected these irregularities in the definition of FLOW distance. The weekly report was formulated in a very general manner, so that we do not expect any deviations in the understanding.

Reliability: The study's results are statistically significant. But there are still a few threats concerning the reliability of the study. Different projects have different scopes and the knowledge and experience base of each team is different from the other teams. These factors can restrict the reliability of this study.

Interpretation

With our approach of using FLOW distance, we propose a way to comprehend the influences of different communication channels on project success. Along with the findings of our study, we are able to show two things:

(i) The mediation model consisting of FLOW centralization, social conflicts and mood. (ii) The appropriateness of using FLOW distance to combine the communication channels and the perceived communication intensity.

The experiment supports our three hypotheses:

1. The degree of FLOW centralization at midpoint is positively related to the degree of social conflict at the end of the project. (H1) 2. The degree of the team's positive affect after the first meeting negatively influences the degree of FLOW centralization at midpoint. (H2) 3. Centralization mediates the relationship between positive affect after the first team meeting and social conflicts at the end of the project. (H3)

A suitable amount of information sharing is necessary for project success. Therefore, ensuring information flow is very important for the project leader. Exchanging information goes along with communication -often in meetings, via e-mail, phone or in (video) chats.

Using certain communication channels can foster and ensure information sharing. Obligatory meetings each week can guarantee a minimum of information exchange. Phone calls, e-mails, conversations and chats in addition to the meetings are also mandatory, since they can minimalize loss of information.

Along with our findings, asking each team member about the perceived communication intensity and the used communication channels is a good way to monitor the information flow.

Combining these data using FLOW distance also indicates social problems and conflicts at the end of project. As shown in H1 and H2, high positive mood influences FLOW centralization, which depends on FLOW distance and thus on communication behavior. The FLOW centralization again has an impact on social conflicts which can influence the project success.

As the deadline approaches, collaboration is very important. Social conflicts at this point may impair project success, i.e. the successful completion of the overall project. FLOW distance is an indicator for that kind of conflicts. Knowing about conflicts arising with an increasing probability can help solving them before they occur.

Therefore, we are not only able to support the hypothesis that communication is important for project proceeding, for example because of its influence on information sharing. Our approach of using FLOW distance as a metric for the collaboration in teams is also target-oriented with respect to ensure an appropriate amount of information flow.

Conclusions

This work introduces an approach of using FLOW distance to foster a suitable amount of information flow in software development teams and therefore project success.

Internal team communication is very important for project success: In each part of the project, information needs to be shared within the whole team or with certain team members.

FLOW distance is a measure combining communication intensities and the used communication channels, which is much easier to assess than surveying every interaction between two or more team members. Furthermore, based on the calculation of FLOW distance, FLOW centralization can be calculated. It can be applied to methods in social network analysis supporting the recognition of team internal structures.

Using the data collection of 33 comparable software projects with 160 participants, we are able to show the relationship between FLOW centralization, social conflicts and mood at certain stages of the project. The degree of FLOW centralization at midpoint is positively related to the degree of social conflicts at the end of the project, which means that the chosen communication channels and the perceived communication intensity at midpoint are indicators for social conflicts at project's end. Furthermore, the degree of the positive affect negatively influences the degree of FLOW centralization at midpoint: Positive mood in the developing team (for example reducible to a successful start of the project) has a negative impact on FLOW centralization which depends on communication in the middle of the project. Moreover, the FLOW centralization mediates the relationship between positive affect after the first team meeting and social conflicts at the end of the project meaning that FLOW centralization -and hence communication -links good mood at the start of the project and social conflicts at project's end.

Therefore, considering FLOW distance helps the project leader to get an overview about possibly existing social conflicts and mood, which influence the information flow and therefore project success. Considering the FLOW distance can foster project success with respect to different metrics: requirement compliance [START_REF] Schneider | Requirements compliance as a measure of project success[END_REF], customer satisfaction, and the team mood by preventing unnecessary work through a sufficient information flow.

Future work will inter alia focus on the application of FLOW distance and FLOW centralization in social network analysis to analyze internal team structures and indicate critical interpersonal combinations.

Fig. 1 .

 1 Fig. 1. Modes of Communication [1]

  centrality max = max{centrality(j) : j ∈ A}.Then, we calculate the FLOW centralization by centralization = j∈A centrality max -centrality(j) centrality * , (*)

Fig. 2 .

 2 Fig.2. The star shape network with five persons. In this example, person E is the most central team member.

Fig. 3 .

 3 Fig. 3. Mediation model

Table 1 .

 1 Media weighting for calculating FLOW distance

	meeting 4
	video chat 3
	chat	2
	phone call 2
	email 1

  13 a 14 a 15 a 21 0 a 23 a 24 a 25 a 31 a 32 0 a 34 a 35 a 41 a 42 a 43 0 a 45 a 51 a 52 a 53 a 54 0

Table 2 .

 2 Descriptive statistics and intercorrelations among variables

		M	SD	Min	Max	1	2	3
	1 Pos. Affect	3.16	0.33	2.60	3.86	-
	2 Centralization 0.15	0.11	0.01	0.51	-.31 †	-
	3 Social Conflict 2.36	0.75	1.35	4.19	-.22	.50**	-
	† p < .1, * p < .05, * * p < .01

Table 3 .

 3 p < .05, * * p < .01 Results of the mediation analysis

		Centralization			Social Conflict
		Coeff. SE	t	p	Coeff. SE	t	p
	Pos. Affect	-0.11 † 0.05	-1.93	.063	-0.14	0.37	-0.38	.705
	Centralization -	-	-	-	3.37 * * 1.16	2.90	.007
	Constant	0.48 * * 0.17	2.78	.009	2.31 †	1.26	1.84	.076
	† p < .1,

*

This extension will not be part of this contribution.

The restriction of the image of d to the unit interval helps comparing the FLOW distances of different teams.

This area was fixed by the study design and may be adapted to other study designs.

The benefit of using FLOW centralization will be outlined in section 5.2.

Within a quality gate in project course, a responsible person, the so-called gate keeper, decides about the release of the next project step on the basis of clearly determined quality criteria[START_REF] Sondermann | Interne Qualitätsanforderungen und Anforderungsbewertung[END_REF].

A german description of all tasks can be found at http://www.se.uni-hannover. de/pages/de:lehre_fungate.

For further information see http://www.afhayes.com.

In order to ensure a better understanding of the results, coefficients are also included in the model.

Acknowledgements

This work was funded by the German Research Society (DFG) under grant number 263807701 (Project TeamFLOW, 2015-2017).