The e-collaboration tools available in open environments offer services supporting the interaction and the synchronization between users, who are typically involved in parallel activity spheres; e.g., different projects and home schedules. However, such tools provide the user's with separate views on her activities and collaborations; moreover, they support workspace awareness by delivering unstructured notification streams, which challenge the user's attention and cannot be filtered or grouped on a relevance basis. As an answer to this issue, we present an Integrated Collaborative Environment offering a unified view of the user's parallel collaboration spheres. This environment includes a notification management model supporting the selective deferral of notifications on the basis of the user's focus of attention.
With the large availability of wireless connectivity, broad band internet connections and
mobile devices, people result being on-line most of the time. This Web presence offers
opportunities to manage different spheres of activity, concerning both work
collaborations, as done in project management and cooperative work (e.g., see [
Currently, many applications support the synchronous and asynchronous
interaction between users; e.g., Instant Messaging, Shared Workspaces, Forums, e-mail, audio
and video Web conferences, and similar. However, with the exception of some Project
Management vertical tools [
– Each tool presents the state of the user’s collaborations concerning the kind of activities it supports; e.g., calendar information, versus document sharing information. Thus, the user is provided with a partial view on the overall set of events concerning her collaboration spheres (e.g., activities, commitments, and tasks to be performed). – As each tool separately handles its own awareness information, the user is overloaded with a flow of unrelated notifications, which cannot be filtered on a relevance basis, or managed by following a specific notification policy.
In order to get an overview of the events occurred within a specific activity sphere
(e.g., those concerning the presence of collaborators, and the scheduling of meetings),
the user has therefore to extract the relevant awareness information from the parallel
streams of notifications generated by the collaboration tools she exploits. This issue
becomes even more relevant if the user uses multiple tools supporting the same
collaboration functions, e.g., one at work and a different one at home, as all such information
streams have to be fused as well. For instance, [
The above discussion highlights the need for collaboration environments that enable users to manage all their spheres of activity, by supporting the integration of external applications, and offering a unified awareness support. The last aspect is particularly important to make awareness information easily accessible and to prevent the user from being overloaded by flows of unrelated notifications.
As an answer to this issue, we developed an open Integrated Collaboration Environment (ICE) supporting e-collaboration in multiple spheres of activity. The ICE is based on the integration of a set of collaboration tools and can be extended with additional applications, in order to provide new collaboration features, or to comply with specific user requirements. Given the set of integrated applications, the ICE manages a unified view of the state of the collaborations the user is involved in and it provides a context-aware delivery of the awareness information to the user. This is achieved by: – Replacing the subjective view on collaboration groups, which most collaboration tools offer, with a centralized management of the activity spheres and of the associated user groups. – Enabling the fusion of the awareness information generated by each of the integrated applications. This fusion is based on the introduction of an agent, the Notification Manager, that acts as an intermediary between the user and the collaboration environment and generates personalized notifications for the user.
This paper focuses on the provision of awareness information and presents the
notification management model developed in our ICE to adapt the awareness support to the
user’s notification preferences. This model is based on alternative mediation policies
[
In the following, Section 2 deals with awareness in e-collaboration environments. Section 3 describes the ICE and the awareness management. Section 4 provides some technical details. Sections 5 and 6 describe the related research and conclude the paper. 2 2.1
The effects of interruptions on people’s activities have been thoroughly studied in the
literature: it has been repeatedly noted that an interruption has a disruptive effect on
both a user’s task performance and emotional state [
Interruptions are particularly critical in collaboration environments, which base the
awareness support on the delivery of notifications to their users. For instance, in
Computer Supported Cooperative Work, the notifications of other people’s activities support
group awareness during synchronous or asynchronous collaboration [
A collaborative workplace poses novel issues concerning interruptions:
coworkers may be involved in multiple tasks, belonging to different projects [
The previous discussion suggests that a correct handling of interruptions is critical to achieve a balanced trade-off between interruptions and awareness. In this perspective, we analyzed the impact on users of a set of notification policies providing different filtering criteria for the organization and presentation of the awareness information. Our hypothesis was that the overhead on users might be reduced by mediating the notification delivery. As a collaboration environment can be used to manage parallel activity spheres, each one generating its own awareness information, we hypothesized to filter and defer notifications on a contextual basis. This led us to hypothesize some contextbased notification management policies that could be robust enough to significantly reduce the disruptive impact of interruptions in user’s work, but also as flexible as to give the user an acceptable level of awareness of her collaborators’ activities.
We performed a test with final users (21 participants, 11 males and 10 females) to evaluate the effects of interruptions by notifications in a collaboration environment. Users were divided into three groups of 7 participants each, and each group experimented a different notification policy: – In the no filter situation, all the notifications, from all the projects the user was involved into, were submitted (7 notifications from 3 different spheres, originated from regular users and administrators). – In the context filter situation, only the notifications from the user’s focus of attention (i.e. the project she was actually working at) were submitted (3 notifications from the sphere of activity of the user, originated from regular users and administrators). – In the priority filter situation, the notifications of administrators’ activities from all projects, plus those included in the context filter, were submitted (4 notifications from 3 different spheres; notifications from administrators were considered with high priority and submitted even if originated from spheres of activity different from the user’s focus).
All the filtered notifications, if any, were displayed to the user when she completed her main task, in the form of a single e-mail message.
Users were asked to perform a simple task (alphabetically sorting a list of names) belonging to a shared project, and they were told that this had to be their main focus of attention. They were also instructed that they were involved in two other projects (planning a conference and planning their participation to an English class) and that notifications of other people’s activities concerning the same projects could interrupt them.
Notifications pop-up windows were displayed in the low-right corner of the screen. Users were told to behave in the most normal and spontaneous way when reacting to an interruption. For example, they could choose to access their e-mail application to visualize the full text of the e-mail and eventually reply to it or just ignore the notifications, proceed with the primary job and then process all e-mails once their primary job was fully accomplished, according to their personal attitude and current state.
All the interruptions were simulated by the experimenter in a Wizard of Oz modality; to be able to monitor a subject’s on-screen activity, a RealVNC server was installed on the subject’s computer. The experimenter, through a client application, watched the subject’s task execution and simulated interrupting events in real time.
At the end of the test, a NASA-TLX survey was submitted to the users in order to
evaluate their total subjective workload [
The context filter emerged as the best choice for our notification policy. The priority filter (which featured only one more interruption than the context filter) performed particularly bad, especially with users that had no previous experience at working in shared ambients, and was therefore discarded. 3
Our prototype ICE supports the coordination of personnel activities (professors, students, etc.) within a University Department. The ICE currently includes a calendar management application, a document sharing tool and a process management component which handles the workflows of two University projects. 3.1
The ICE is based on the SynCFr environment for the synchronization of applications
[
Our ICE extends SynCFr with the integration of a set of components supporting the user’s collaboration and the management of workspace awareness. In particular: – The User Agent manages the identities and the notification preferences of the users registered in the ICE. Moreover, the agent tracks the sphere of activity in their focus of attention, while they operate within the environment; see Section 4.2. – The Group Manager supports the users in the definition of the spheres of activity and of their associated collaboration groups. The spheres can be private or shared with other registered users. We assume that, within an organization, a set of public spheres is defined to organize projects and other similar activities; moreover, any registered user can create her own spheres, to integrate the management of personal commitments with the workplace ones. – The Notification Manager mediates the delivery of notifications to the user, according to the notification preferences stored in the User Agent. 3.2
The policies applied in our ICE are aimed at deciding whether a notification should be immediately delivered or it should be deferred. According to the results of the tests described in Section 2.2, the criterion used to steer the deferral of notifications is their relevance to the sphere of activity the user is focusing on. In particular, the ICE offers the following policies, which the user can explicitly select: – The default policy is the context filter. – The user can however set as her notification preference the no filter policy. – Furthermore, the user can keep the context filter as a default, but she can apply the no filter policy to one or more specific spheres of activity.
In the management of deferrals, two main factors should be taken into account: on
the one hand, as noticed in [
Given such requirements, our ICE enables the user to select the maximum amount of time a notification can be deferred. While the user operates in the ICE, she is notified about all the deferred notifications as soon as one of them reaches the deadline. Moreover, the environment delivers all the deferred notifications at each focus shift.
At the actual stage of development, when a set of deferred notifications has to be delivered, it is reported in a single e-mail message, in a format supporting the user in the inspection of a possibly long list of messages. The message is an interactive web page in which the notifications are grouped by sphere of activity. For this purpose, the page contains a set of clickable tabs, one for each sphere, among which the user can switch by means of a click. In order to highlight the notifications concerning the user’s focus of attention, the corresponding tab of the page is presented as the front one. Each tab includes a list of message headers, available as links. For each message, the following information is displayed: – subject, including the application that generated the notification and the object; – sender, i.e., the user who originated the notification; – date. 4
The management of the notification policies is based on three elements: 1. The association of the events generated by the ICE applications to their reference spheres of activity; see Section 4.1. 2. The recognition of the user’s focus of attention, i.e., of the sphere of activity she is working at, at any given moment; see Section 4.2. 3. The mediated notification management; see Section 4.3. 4.1
For each application integrated in the ICE, the adapter wrapping the component is in charge of tagging the events it generates with the sphere of activities they belong to, or with the list of users involved in the event, depending on the kind of component.
Specifically, if the component explicitly manages contexts (e.g., process management components do that), the adapter can tag such events appropriately. However, most collaboration tools only support the sharing of objects with sets of users; e.g., documents in GoogleDocs. In this case, the wrapper tags the event with the list of users sharing the object. If the same users participates to more than one sphere of activity, the event is implicitly associated to all such spheres, and thus ambiguously tagged. 4.2
From the viewpoint of the notification management, the user’s behavior in the ICE is summarized by two context variables: – The user’s activity status specifies if the user is active, idle, or off line. 2 – The focus of attention stores the systems’s hypotheses on which sphere of activity the user is working at: this is a list of spheres, representing alternative hypotheses, and is empty when the user is off line.
The User Agent associated to a user receives the context information about ’s activities available in the Cross-Application Context and it analyzes such information in order to update her focus of attention (henceforth, ):
– When the User Agent receives the notification that the user is active, it initializes with all the user’s spheres of activity. Moreover, it sets the history ( ) of the discarded hypotheses to the empty list. is a buffer of discarded hypotheses, which might need to be rescued, given the new evidence about the user’s behavior. – Each time the Agent receives a new piece of context information describing a user action (e.g., she has uploaded a document in the shared space), it analyzes the reference groups (henceforth, ) of the event. 3 Then, it updates and accordingly. We assume that, if there is no evidence of a focus shift, then the user is continuing to work within the same sphere of activity (continuity assumption). Thus, and are updated as follows:
If , we hypothesize that the new evidence contributes to restrict the focus of attention. Let and denote the updated values of and , respectively. Then, . Moreover, . This means that the history is cleaned; then, it is set to the hypotheses just discarded from the focus of attention plus those provided by the new event which were not included in because they were not consistent with the continuity assumption (they introduced new focus hypotheses). For instance, suppose that is , that the focus is and that the new event is tagged as . Then and .
If , we assume that the user has shifted to a new sphere of activity.
Thus, .
Notice that the ICE components publish events concerning both the actions performed by the user and those triggered within the applications she uses. For instance, GoogleDocs can be polled to retrieve events of type [Document uploaded by user at time ] each time a user saves a new copy of a document , or the document is automatically saved by the application. Thus, the User Agent receives a regular flow of evidence while the user is active in the ICE. When the flow of activities stops, the Agent sets the focus of attention to the empty list. 4.3
The Notification Manager handles the notifications directed to each user registered in the ICE by filtering them according to her preferences. Each time an event concerning the user is published in the Cross-Application Context, the Notification Manager operates as follows: – If the user is off line, it stores the event in an internal buffer; when the user is on line again, it discards all the events older than 24 hours; then, it merges the other ones (cleaned from redundancies) into a message, structured as described in Section 3.2, and sends the message to the user by e-mail. – If the user is on line, the notifications are delivered, or deferred, depending on her policy preferences:
If the user has selected the no filter policy, the Notification Agent notifies the user by generating an Instant Message via the IM application. 3 This is done by retrieving the spheres of activity to which a list of users belongs. Otherwise (context filter), it reads the user’s focus of attention (F), and calculates the intersection between F and the tagging information of the event (RG). If , or one of the reference groups in RG belongs to the non filtered spheres, then the Notification Manager sends the notification to the user; otherwise, it defers it.
If the user’s is online but the focus of attention is empty, this means that the user is working outside the ICE. Thus, the Notification Manager defers all the notifications, except for those concerning the non filtered spheres. 5
The notification management approach presented in this paper is based on the mediated
notification management model, which is largely used and has been identified as one of
the best performing methods; see [
This differs from the awareness support offered by e-collaboration environments such
as BSCW [
Our work strictly relates with the ecology of collaborations proposed by Mark and
Su in [
We have described an Integrated Collaboration Environment (ICE) supporting e-collaboration within multiple spheres of activity; e.g., different projects users are involved in at work, their social activities, and so on. Specifically, we have focused on the notification management issue and we have defined a novel notification policy supporting the context-dependent delivery of messages to the user. We based the definition of our notification policies on the results of a user test carried out within our lab; the test evaluated the context filter, which defers notifications on the basis of their relevance to the user’s focus of attention, as the policy most suited to the user’s needs.
The next step of our work is the evaluation of our ICE prototype with users. In particular, we will focus on the proposed notification management policies, in order to evaluate the impact of the ambiguity in the identification of the focus of attention on the selection of the notifications to be deferred.
Currently, we do not analyze the user’s activities in detail, e.g., to identify different
phases in the execution of a task; e.g., see [