Modeling Awareness Requirements in Groupware: From Cards to Diagrams

Up to now, groupware has enjoyed a certain stability in terms of the users’ technical requirements, being the awareness dimension one of its key services to provide usability and improve collaboration. Nonetheless, currently, groupware technologies are being stressed: on the one hand, the pandemic of COVID-19 has greatly driven the massive use of groupware tools to overcome physical distancing; on the other hand, the new digital worlds (with disruptive devices, changing paradigms, and growing productive needs) are introducing new collaboration settings. This, and the fact that software engineering methods are not paying enough attention to the awareness, makes us concentrate on facilitating its design. Thus, we have created a visual modeling technique, based on a conceptual framework, to be used by the developers of groupware systems to describe awareness requirements. This visual language, called the awareness description diagrams, has been validated in some experimental activities. The results obtained show that this is a valid technique in order to model the awareness support, that it is useful and understandable for groupware engineers, and that the visual representation is preferred to a more textual one in terms of expressiveness.

Modeling Awareness Requirements in Groupware: From Cards to Diagrams Crescencio Bravo , Rafael Duque , Ana I. Molina , and Jesús Gallardo Abstract-Up to now, groupware has enjoyed a certain stability in terms of the users' technical requirements, being the awareness dimension one of its key services to provide usability and improve collaboration.Nonetheless, currently, groupware technologies are being stressed: on the one hand, the pandemic of COVID-19 has greatly driven the massive use of groupware tools to overcome physical distancing; on the other hand, the new digital worlds (with disruptive devices, changing paradigms, and growing productive needs) are introducing new collaboration settings.This, and the fact that software engineering methods are not paying enough attention to the awareness, makes us concentrate on facilitating its design.Thus, we have created a visual modeling technique, based on a conceptual framework, to be used by the developers of groupware systems to describe awareness requirements.This visual language, called the awareness description diagrams, has been validated in some experimental activities.The results obtained show that this is a valid technique in order to model the awareness support, that it is useful and understandable for groupware engineers, and that the visual representation is preferred to a more textual one in terms of expressiveness.

I. INTRODUCTION
I N THE pandemic caused by the SARS-CoV2 virus, we have been forced as a society to get adapted to a massive use of technology to overcome physical distancing and, in so doing, to maintain the production activity, public services, teachinglearning processes, as well as social and family relations.This way, that teleactivity has greatly driven the use of groupware, although without planning or prior training [1].
To date, groupware systems placed in the time/space spectrum (colocated vs. distributed and synchronous vs. asynchronous) [2], enjoyed a certain stability in terms of the users' technical requirements along with the underlaying interaction metaphors and styles they needed to support.Nowadays, however, this technology is being stressed by disruptive devices, changing paradigms, and emergent necessities, which are configuring new collaborative settings, such as mixed reality [3], proliferation of wearables [4], implicit interaction based on physiological signals and emotional states [5], or the use of new senses for human-computer interaction [6].
In any of the scenarios, in order for collaborative activity to be effective and efficient, elements of knowledge are needed that contribute to a better follow-up of the group work.Thus, the concept of awareness arises, which Dourish and Belloti [7] defined as "knowledge of the activities of other users, which provides a context for one's own activity."This awareness information, subtle and ideally rich, allows one to know, and also to anticipate, the actions of others, which results in a more productive collaborative interaction.Awareness, therefore, becomes a main concept in the field of computer-supported cooperative work (CSCW), and several scientific works have proposed frameworks and conceptual tools to deal with it (e.g., [8], [9]).
However, the awareness design is far from being a solved problem: the gap between theory and design is an open area [10], and research is needed to conceive and test novel technology to support awareness and keep the coordination effort to a minimum [11].Moreover, the functionality of collaborative systems is made up of application domain requirements and collaboration support requirements, falling the awareness in the latter category.The elicitation and specification of collaboration and awareness requirements is a great challenge due to the difficulty of envisioning these collaborative services in the early stages of the development process [12] and the need to capture different knowledge for many different stakeholders [13].The aforementioned conceptualizations and frameworks help in the elicitation of awareness requirements, nonetheless, there is a lack of established guidelines, specific tools, and systematic support for the modeling and design of awareness requirements.
Consequently, the design of the awareness is a complex task, and commonly, it has to be developed from scratch for each groupware system.This way, our research objective is to fill the gap with regards to methods and tools to guide and facilitate the design and development of the awareness support, thus aiding the engineers in building a suitable awareness support for a groupware system according to the users' requirements and tasks.We pay particular attention to the emerging new collaborative settings where the implicit and multimodal interaction styles are widely used instead of, or extending to, the more classical user interfaces and collaboration metaphors of groupware systems.In a previous article, we proposed a descriptive technique to approach this challenge, called the awareness cards (ACs) [14], made up by compartments with the elements to characterize an intervention to provide awareness.This technique is based on a framework consisting of two views: information elements for awareness, organized into areas, and a catalog of widgets and interaction devices.
In this article, we present an evolution of this specification technique approached from two main directions: a more visual modeling language, and its extension to incorporate the users' senses which participate in the interaction.Graphical descriptions make the knowledge visible differently from textual descriptions.Specifically, they provide a visuospatial representation that shows the information in a multitude of forms by using fundamental graphical elements, such as icons (nodes) and lines (relationships) [15].Furthermore, graphical descriptions encourage inferences about the behavior or cause-effect relations of a system [16], which will be useful to express the dynamic nature of providing awareness.Second, with this new approach, we put the emphasis on the user-system interaction and on the devices, widgets, and controllers which support it in a collaborative activity.
The design of this new technique, called awareness description diagrams (ADDs), is inspired by our research working line through the study and development of collaborative systems in the domains of learning [17], of programming [18], and of design [19], and on the review of the state-of-the-art research.In order to study the validity of this awareness modeling technique, we have contrasted it with a review of some descriptive models for groupware systems in the literature, which characterize different types of awareness and conceptual structures so as to organize and provide awareness support, as well as some visual notations existent.Then, we have put the ADD technique to the test with some modeling activities with potential users of the technique, i.e., developers of groupware systems.
The rest of this article is organized as follows.Section II reviews awareness taxonomies and compiles visual techniques for specifying awareness requirements, from which we extract drawbacks of the main existing proposals; the AC technique closes this section.Section III describes the new ADD technique.Section IV includes a study on the use and validation of the proposed technique.The results are discussed in Section V. Finally, Section VI concludes this article.

A. Awareness in Collaborative Activities: Conceptualization and Approaches
Much research has addressed the study of the awareness support within the sphere of collaborative work and, thus, various types of awareness have been proposed and are well established as a design reference.
The workspace awareness (WA) emerged as "the up-to-themoment understanding of another person's interaction with a shared workspace" [20].Gutwin and Greenberg [21] proposed a framework that considers three categories of elements of information for WA in relation to the present: who participates in the collaboration, what they do, and where they interact.These categories were later extended with elements of information relating to the past: when the event happened, and how the operation took place and the artifacts came to be in a new state.Previously, Greenberg and Gutwin [22] had pointed out that WA can overlap with the other types of awareness: 1) informal awareness (IA), that enables the general sense of who is around and what they do; 2) social awareness (SA), that provides information about the context of others (whether they are paying attention, their emotional state, etc.); and 3) group-structural awareness (GSA), that describes people's roles.
With a focus on wide-scale collaboration settings, situation awareness was defined by Endsley as "the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future" [23].So that the users' decision-making starts from the perception of the environment itself.This type of awareness is not necessarily linked to collaborative environments and can be applied to single-user dynamic systems (for instance, an airplane pilot who must be aware of the atmospheric conditions, cockpit signals, etc.).
According to [24], awareness information should also describe the intentionality of the users when they interact with the groupware.They claim that "the heeding strategy that each person can at the same time see the computer monitor and what the other person is seeing is not enough."This favors an intentionality shared by all the members of the work group.Thus, the term we-awareness [25] arises to reflect this cooperative behavior, which must be provided by the awareness information.
With respect to the supply of awareness support, the output information is provided by the groupware systems that use awareness cues, which are "any signal, symbol or mark in the user interface-typically textual, graphical or auditory-the content of which is produced (or influenced), in real time, by the actions or properties of a remote person" [26].In line with this, in [27], it is proposed a framework so to generate awareness cues that provide a palette of common design patterns for collaborative game designers.
Groupware systems traditionally applied a What You See Is What I See paradigm, which implies that all the users have the same view of the system.However, the lack of flexibility of this approach made groupware systems evolve toward a What You See Is Not What I See paradigm [28], which means that users can have different views since they perform different actions, follow different roles, act in different workspaces, or have different aims, and the awareness cues must take all these into account and adapt to the specific necessities.Thus, shortcomings in the awareness cues provided by the groupware user interfaces could imply usability problems [29].

B. Techniques and Visual Languages for Awareness Description
After reviewing the key conceptualizations and types of awareness in groupware and the importance of awareness cues on the user interface development, it arises the challenge of having modeling techniques available that allow the designers to represent the awareness support that groupware should provide, with the final aim of incorporating these techniques into methodological processes to support the design and the implementation of this type of systems.
Yang et al. [30] have evaluated the usual awareness support of groupware and concluded that the tools included in all collaborative systems are quite similar: shared file space, threaded discussion board, calendar, file annotation, active user monitoring, and text-based chat.However, when groupware systems are used within the ubiquitous computing paradigm, the users interact with new devices embedded in the user environment.Hence, López and Guerrero [31] pointed out that current research proposals use lights, vibrotactile devices, sensors, tabletops, and eye trackers as components that collect data to provide awareness information.
Collazos et al. [8] have presented a framework consisting of a set of methods to identify the awareness information which should be provided by groupware.These authors consider that contexts change dynamically, and awareness information should provide descriptions of the current user's context, which is called nontraditional awareness information in their work.The context concept is referenced here as the information used to characterize the situation of a user that is considered relevant to the usersystem interaction and the computer-supported collaboration between users.
In relation to modeling visual techniques, mobile collaboration modeling (MCM) [32] is a visual language to represent mobile collaborative work.MCM focuses on the representation of computer-mediated interactions between users but does not provide elements to specify awareness information.Collaborative systems requirements modeling language (CSRML) [33] is an extension of the i * language to model groupware system requirements that include support to represent artifacts that enable the users to be aware of other user's presence/actions.Computer-supported interaction modeling notation (CIMoN) [34] is a visual modeling language that allows designers to represent autonomous agents that can provide awareness information.Notwithstanding, CIMoN notation does not provide support to describe and characterize awareness information that should manage these agents.
Kirsch-Pinheiro et al. [35] modeled user's physical and organizational contexts to provide awareness information by using the UML notation.This proposal is focused on groupware systems, which use mobile devices, but it neither consider other contexts nor other devices.
To sum up, we identify the following three gaps of the proposals previously reviewed.
1) Completeness of the support for modeling awareness: Most research works are neither comprehensive nor complete proposals that consider all significant issues: i) content and structure of awareness information; ii) dynamic contexts in which the collaboration is being carried out; and iii) devices (and widgets, as interfaces) that are source or target of awareness information.Thus, MCM, CIMoN, and the proposal of Kirsch-Pinheiro et al. [35] include support to model the structural components of groupware systems (for instance, a software agent) that collect and provide awareness information, although they do not provide support to specify what content should be included in this information.MCM and CSRML do not consider that groupware can be used in dynamic contexts.Moreover, none of the modeling proposals includes a list of specific interaction components (sensors, displays, widgets, etc.) that are related to the awareness information.
2) Visual notation: The framework of Collazos et al. proposes a flexible methodological approach that can be applied in dynamic contexts, but it does not offer a visual modeling language.The proposal of Kirsch-Pinheiro et al. [35] is based on UML and it does not provide specific visual languages since it does not use stereotypes.

3) Learnability and understandability criteria: MCM and
CIMoN provide visual notations that are evaluated by using learnability and usability criteria.And the CSRML visual notation is assessed in terms of understandability.Table I classifies the techniques and approaches presented above in the gaps identified: 1) support to specify awareness information; 2) support to model the context; 3) specific support to model the interaction components (sources/targets) involved in the awareness information cycle; 4) existence of a visual language; and 5) evaluation of the learnability/understandability of the technique.While some of them cover some of these gaps, none of them allow the connection of the functional layer to the operation layer, linking the user's and system requirements with the user interface components, i.e., widgets and devices.
This outlook motivates our research work, which consists in a proposal for modeling awareness that satisfies the criteria shown in Table I.

C. Awareness Cards
The AC [14] is a technique designed to describe awareness support in multimodal collaborative user interfaces.This is made up of two components as follows.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.2) A descriptive specification language, a pseudoformal and mainly textual technique to express awareness requirements, which uses the concepts of the framework (see Fig. 2).The technique approaches the awareness as a set of opportunities to intervene in the ongoing collaborative activity by acting in the user interface (e.g., displaying information and playing cues) to provide awareness knowledge to the collaborating users.Thus, an AC (Fig. 2) contains six compartments through which an awareness intervention is described by means of attributes and specifications, as follows.
1) Awareness areas and dimensions in which the intervention is instantiated.2) Specific information element (or elements) to which the intervention refers.3) Modality of interaction.4) Input event, from devices and widgets, that causes the intervention.5) Output actions, through the widgets and devices, to be fired as a result, such as cues or user-interface operations.6) Textual description of the intervention.Fig. 3 shows, as an example, the AC corresponding to the R2 requirement of the system for simultaneous downhill skiing (Appendix D), which is also specified in the next section with the ADD (see Fig. 5).
In order for this framework to be used in the development of groupware applications, a process of four steps should be followed: 1) preliminary analysis; 2) conceptual design; 3) awareness specification; and 4) design and implementation of the awareness support.

III. AWARENESS DESCRIPTION DIAGRAMS
As an evolution of the AC, we conceived a visual modeling technique as a tool to describe awareness requirements, called the ADDs.This is based on the same conceptual framework (see Section II-C), and its modeling language is semantically equivalent to the AC, although it incorporates some improvements apart from its more visual look.The ADD modeling technique follows a tree-form structure and includes building blocks and relationships between them (Fig. 4) as follows.
1) Blocks: Descriptive notes (marked with N in Fig. 4), awareness classification (A), the event intercepted for awareness intervention (E), the operations (and  parameters) to be executed to provide awareness (O), the widgets (or controllers) involved as source/target of the corresponding human-computer interaction (W/C), and the devices used (D).These blocks are decorated with specific icons.2) Relationships: Links between notes and the blocks to which they refer (marked with 1 in Fig. 4) (only the awareness classification, event, and operations blocks allow these links), the events and operations to be processed in the awareness requirement (2), relationships that express flows of information to events or from operations (from or to widgets, respectively) (3), and the associations between widgets (or controllers) and input/output devices (4).By widget, we mean a small embeddable application that can usually be executed within runtime containers in the user interface.On the other hand, so that they commonly have a physical nature, we refer to controllers as other more virtual widgets that are broker processes between devices and events/operations, which are characteristic of the implicit interaction.
The ADD technique is declarative but also procedural, since there is an explicit recognition of a cause-effect flow, modeled with an input-output pattern together with the use of notes to express the behavior in a pseudocode fashion linked to both the input and output.More details on the semantics of this specification are given in [14].
In contrast to the AC, the relationship between widgets/controllers and devices is now made explicit by means of a binary association that is decorated with the sense involved in the interaction (see legend in Fig. 4); also, the new note element allows a detailed although informal description of data for both the input event and the output operation, and of internal procedures for the operation.
The specification of the sense makes it possible to deal with haptic awareness [36] when implicit or explicit touch-based interaction and the use of touch-related devices and widgets are necessary, for instance, for users with special needs (e.g., [37]) or particular collaboration scenarios.
Fig. 5 shows an example of an awareness requirement (R2) in a fictitious setting of simultaneous downhill skiing (see Appendix D).The aim of the app is to ensure that the skiers go down safely and that no collisions occur between them.The skiers collaborate and interact in an implicit way, simply through their downhill activity.This model reads as follows.1) The awareness requirement fits in the context and environment area (a physical space) and where dimension, being the user's location the relevant information.
2) The app transmits the user's geolocation every 0.2 s from the GPS to the controller, generating the movement event (user_skiing), which is an implicit interaction.
3) The users' location is used in order to calculate whether they are too near to each other.In this case, a sonar-like acoustic signal of proximity and pressure on the bracelet each skier is wearing are activated for the nearby users.In order to illustrate the versatility and breadth of the technique, in a second example, we show a university enrolment system in Fig. 6 (see Appendix E).The ADD specifies that the awareness involved falls in the workspace area, and that the dimensions covered are who (carries out the task) and what (task is done).The different users do their work using forms and the mouse and keyboard, and this way the record is progressing to the next stage, so that when a user accesses his/her workspace-collaboration is asynchronous-awareness information is shown on the screen by means of the progress bar, event list, and participant list widgets.
We can also reflect on the applicability of our framework in CSCL scenarios, which usually consider three types of group awareness [38]: behavioral, cognitive, and social, to inform, respectively, about learners' activities, knowledge of group members and group's functioning, and issues covered by the awareness areas and dimensions.Also, the widget building block could be used to specify particular teaching-learning widgets, such as behavior radar, knowledge visualization, role representation, use of learning objects/resources, or assessment view.
The ADD technique is intended to tackle the weak points of the approaches studied before (see Section II and Table I).In doing so, ADD includes support to model awareness requirements, including dynamic contexts, and to consider devices and sources/targets of information; for this, it uses a visual semiformal language.With respect to its characteristics as a visual language, the following section presents the results of an evaluation carried out to assess its completeness, ease of learning, and comprehension, together with its usefulness and suitability for practical use.

IV. STUDY
In this section, we formulate a number of research questions, which we will explore from two perspectives: a theoretical view, paying attention to the conceptual structure of the ADD technique; and an empirical study, in which some experimental activities with users were performed and their results analyzed.

A. Research Questions
A comprehensive study was designed so as to validate the new ADD technique.The master research question (MRQ) was specified as follows: Is it feasible to use the ADD for the specification of awareness requirements of different groupware systems and usage settings, improving the AC at the same time?
The following four specific research questions (SRQs) were derived from the MRQ.
1) SRQ1: Is ADD a complete framework for the modeling of awareness support?2) SRQ2: Is the ADD technique understandable for groupware designers?3) SRQ3: Is ADD a suitable technique to model awareness requirements?4) SRQ4: Which are the improvements or positive features of the ADD compared to the AC?By a complete language, we mean that it allows us to model (identify and describe) the wide variety of services of highquality awareness that can occur in any collaborative scenario or task.This completeness also refers to the inclusion of all the elements identified by the systematic review of research proposals to support modeling awareness.
A visual language is understandable and, by extension, learnable, when it is easy to use and its building rules are intuitive and easily discovered by its users.
Being a suitable technique implies that it is feasible for the designers to use and combine the building blocks of the modeling language to express awareness mechanisms that satisfy the requirements of a specific groupware and, consequently, that the technique is useful for such a task.

B. Structural Assessment
So as to study the structural and conceptual coverage of the ADD technique, we analyze whether its concepts and modeling components allow us to address all the aspects related to the process of awareness information generation in line with the knowledge compiled in the literature.For this purpose, Table II collects five dimensions of study and modeling of the awareness: the first two refer to organization and informative content of the awareness; and the next three represent an interaction between a collaborative system and an external actor, which implies activity that is carried out or things that happen that are relevant for the users to be aware of in an input-output flow, in which widgets, sensors, and devices are the means of the interaction.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

TABLE II COMPONENTS IDENTIFIED BY THE SYSTEMATIC REVIEWS OF AWARENESS FRAMEWORKS
Accordingly, we studied the key contributions that have made a systematic review of the vast scientific work on this topic.These reviews have examined all the scientific production on the subject and have established classifications to arrange the elements that intervene in the generation of awareness information.We have excluded works such as [39] since they do not follow a systematic or mapping review protocol, although they could study models and theoretical frameworks awareness in the use of groupware systems.
Steinmacher et al. [40] and [41] carried out a systematic review and mapping of the literature on awareness support in distributed software development, however, they do not study other kinds of collaborative systems.These two works identify awareness information elements and areas that match with the ADD proposal (see Table II).The authors pointed out that they could not find any studies linking awareness in global software development and ubiquitous computing.It is worth noting that implicit interaction and ubiquitous computing are features covered with the ADD notation.
Teruel et al. [33] applied a thematic synthesis method so to analyze awareness interpretations in the literature to identify the awareness needs of collaborative games.Although this article has the final goal of defining a set of requirements for collaborative games, this article deals with a broader range of groupware.The awareness information identified in this article is included in the information elements and awareness areas and dimensions of the ADD (see Table II).
López and Guerrero [31] focused on a systematic review of collaborative tools that use ubiquitous mechanisms to provide awareness in the collaborative domain (see Table II).They reviewed over 400 papers and concluded that traditional interfaces and mobile devices are still the most common means.However, new ubiquitous devices and nontraditional interfaces are extending.For this reason, the ADD language includes the interaction modality block to identify whether the collaborative system supports explicit interaction (traditional interface) or implicit interaction (ubiquitous system).Moreover, the ubiquitous devices are specified within the input and output modeling blocks.

TABLE III UNDERSTANDABILITY OF AWARENESS AREAS
Collazos et al. [8] carried out a systematic mapping study of frameworks and design processes of awareness support.This article reviewed which types of awareness information have been useful to CSCW, and identified three types of context information sources: 1) people; 2) tasks or projects; and 3) resources, such as workspace objects.These awareness and context information sources can be related to some components of our conceptual framework (see Table II).Nonetheless, this review does not deal with techniques that model an interaction procedure, made up of inputs and outputs, that allows the communication of awareness information.
Similarly, a taxonomy of concepts related to awareness information is established by Mantau and Benitti [42], but then again this article does not approach the interaction procedure underlying to an awareness intervention.
It can be seen that the five modeling components of the ADD (shown in Table III above) have been widely used by the scientific community to study and classify the elements that intervene in the process of generating awareness information, which partially contributes to validate SRQ1.

C. Empirical Study 1) Tasks and Participants:
In the notation assessment activity, 66 participants who were taking a degree in Computer Science from the Spanish universities of Castilla-La Mancha, Cantabria, and Zaragoza were involved.All of them had taken a subject in human-computer interaction from second/third year of this degree, where they studied user interface design and groupware, and carried out design activities using CTT.They also followed a seminar on groupware that allowed them to have solid knowledge about awareness support and evened out their knowledge.These participants carried out the following four tasks.
1) Task 1: They analyzed the documentation that describes the ADD's framework and answered a questionnaire that allowed the assessment of its comprehensibility and completeness (see Appendix A). 2) Task 2: Next, some illustrative awareness models corresponding to two case studies, telepointers, and amusement park (described in [14]), specified with both the AC and the ADD, were presented to the designers.Then, the participants filled a questionnaire (see Appendix B) to compare the understandability, ease of use, and usefulness of both specification techniques.3) Task 3: Afterwards, a subset of 50 participants (those who had some spare time in their teaching schedule) approached an assignment which consisted in creating Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
four ADD models aimed at fulfilling the awareness requirements of the two following hypothetical apps: -Task 3.1: The first app was for supporting skiing downhills in group (see Appendix D).The participants had to complete the modeling blocks missing in two partial models.-Task 3.2: The second app allowed them to carry out collaborative virtual excursions in nature.An ADD had to be created from scratch.4) Task 4: Finally, the participants answered a post-task questionnaire to evaluate the complexity and usefulness of the different elements of the ADD proposal, after using it to build the models from Task 3 (see Appendix C).

2) Results on SRQ1. Is the ADD a Complete Framework for the Modeling of Awareness Support?:
In order to assess the completeness of the ADD technique, 66 participants who carried out Task 1 were asked about the structural components considered within the framework (Appendix A, question 2), i.e., awareness areas (WA, CEA, IA, SA, and GSA), awareness dimensions, and information elements.Six participants (9.09% of the population) answered that it would be desirable to incorporate a why dimension in the framework.Three participants proposed completing the IA dimension, although without specifying how they would do it.Two proposals were registered so that the SA area included a dimension to know the relationships between the users.
And 11 participants (16.67%) made several comments that did not coincide with the ones of the rest of the users.Some of the most significant comments are as follows.
1) One participant proposed that the WA area include a dimension for movements, and the CEA contains a dimension for changes.2) One user pointed out that information on the history of the emotional state of the user should be incorporated in the SA area.3) One respondent believed that the IA area should include a dimension to know what the users are looking at.4) One participant proposed including information on user skills on the GA area.5) One comment suggested that awareness, in general, shows feedback for the actions carried out.Finally, 48 designers (72.7%) expressed that they did not miss any components, which would mean that the structural set of areas, dimensions, and information offered them what they needed in order to model.
Besides the modelers' opinions, when the evaluators assessed the models built by the participants in Tasks T3.1 and T3.2, they did not discover that the participants had missed particular types of elements or of modeling blocks to fulfill the proposed tasks.
After gathering all these results, together with the structural assessment in subsection B, we can conclude that the framework is complete enough so as to model awareness support in terms of structure and modeling components.
3) Results on SRQ2.Is the ADD Technique Understandable for Groupware Designers?: The participants in the study who performed Task 2 assessed the ease of understanding of the different areas of the framework (Appendix A, question 1).For this purpose, a numeric scale was used with a range of values from 0 (worst value, the area is very difficult to understand) to 5 (best value, the area is very easy to understand).Table III shows the values of some statistical descriptive measures associated with each awareness area of the framework.It seems that the participants had difficulties in understanding the IA and SA awareness areas, whereas the WA, CEA, and GA areas got good valuations.This result is consistent with a similar task approached with the AC studied in [14], where the IA and SA areas were the least understandable (M = 2.56 and SD = 0.96, M = 2.56 and SD = 1.15, respectively), followed by the CEA area.
Once the participating engineers had experimented with the ADD and created the models of Task 3, they assessed the complexity of the notation (Appendix C, question 1).For this, a numeric scale was used from 0 (best value, the notation is easy to use) to 5 (worst value, the notation is very complex).The average value was 2.75, which could be interpreted as ADD not being easy but not complex to use.However, this average value has a standard deviation (SD) of 1.13, which makes it difficult to extract a uniform opinion from the results.
Hence, it can be considered that the ADD technique is understandable, especially its main awareness areas, and that it presents an acceptable degree of complexity.
4) Results on SRQ3.Is ADD a Suitable Support to Model Awareness Requirements?: Through Task 3, we proceeded to assess whether the participants were able to handle the ADD technique and use it to build models (suitability).Thus, it was proposed that they build ADD models which satisfied four requirements of awareness information (R1 and R2 from the case study in Appendix D and another two requirements from a different case study).Among them, two incomplete diagrams had to be completed (Task 3.1), the former is the one shown in Fig. 5 but without the block to specify awareness areas and dimensions (the root block), and the latter can be found in Appendix F.
Two experts in awareness and in ADD visual language assessed whether the syntax and semantics of the notation had been used correctly by the participants.This assessment was made by using a numeric scale between 0 (worst value, the participant uses the notation very inaccurately) and 5 (best value, the participant uses the notation completely accurately).Table IV shows the mean value with which the expert assessed the models built for each requirement.It is worth mentioning that the valuation is between 3.66 and 3.96, which are high scores that correspond to the 72%-78% of the best model (100%) for the requirement.
Once the participants had widely used the ADD to build models and were familiar with it, they were asked to assess TABLE V ASSESSMENTS OF THE ADD'S USEFULNESS the usefulness-defined as the degree to which a component facilitates the description of awareness requirements-of the following three components: 1) the conceptual structure of the framework (areas, dimensions, and information elements awareness); 2) the widget and device catalog; and 3) the ADD (as a descriptive language) (Appendix C, question 2).Each of these aspects was assessed using a numeric scale with values between 0 (worst value, not at all useful) and 5 (best value, very useful).Table V shows the mode, median, mean, and the SD values of the evaluations.
The results suggest that the framework, as a conceptual structure, and the catalog of devices and widgets are quite useful, and that the ADD is a bit less useful, although above the average usefulness.
Again, as in the previous article presented in [14] using the AC, the collection of devices and widgets for awareness support is considered the most useful element.Also, there was agreement about the identification of the most useful devices, which are those related to sight, hearing, and touch, but many others were identified in addition to those initially considered in the framework in three main categories, as follows.
1) About senses: holographic projector, smart contact lenses, and augmented reality glasses.2) About bodily properties: body motion sensor, smart sportswear, health parameter sensor, medical dispenser, fingerprint reader, and iris recognizer.3) About the environment: smoke detector, light sensor, pressure sensor, anemometer, outdoor thermometer, magnetic sensor, ambient lights, and rain gauge.With regards to widgets or controllers, the participants valued the ones related to the sense of sight as the most useful, and proposed new ones to extend the default catalog, such as sign language controller (recognizer/producer), avatars, and body motion controller.Obviously, all these devices and widgets, some of them with a futuristic flavor, should be input or output of relevant information from the point of view of collaboration.
5) Results on SRQ4.Is the ADD a Better Technique Than the AC?: By means of Task 2, we tried to test whether the new ADD modeling language, which evolves the AC (see Section III), constitutes an advance in understandability with respect to its predecessor.In this case, the participants had to choose which awareness modeling technique was easier to understand using a Likert scale (Appendix B, question 1), since the conceptual framework is the same.The participants distributed their answers equally among the options available, so there is not a clear preference for one or another (Fig. 7).
Similarly, they evaluated the ease of use (question 2) and the expressive power (question 3) of both the AC and the ADD with the same scale (Fig. 7).This was the expressive power, that is to say, the usefulness of the visual language, the aspect in which the ADD is significantly more suitable than the AC according to the participants' opinions.

V. DISCUSSION
Analyzing the results from the study described in the previous section, we can argue that the ADD technique is suitable for the purpose outlined, i.e., to model the awareness support in groupware applications; and that the ADD is a complete and understandable technique for designers of these types of systems.
Specifically, the conceptual structure of the framework is complete enough so to model awareness support from two points of view: the coverage of relevant aspects in the literature about awareness design and generation, and its capacity when used by potential engineers to build awareness models.The awareness organization areas of this structure were seen by these engineers, in general, as easy to understand; and they thought that the structural components of the technique together with the catalog of widgets and devices were quite useful.
With respect to the visual modeling language, after using it, the engineers felt that it was not particularly difficult to utilize.They were able to build models for specific awareness requirements of relatively good quality according to an external assessment by experts.And, in comparison with the AC, it is clear that the ADD visual language seems to be more useful and expressive, although at the cost of being less easy to use.
In short, gathering all the above results, we understand that the MRQ can be answered affirmatively.Nevertheless, we can learn some lessons from the results obtained as follows.
1) The participants had difficulties in understanding the IA and SA areas (MIA = 2.83 and MSA = 3.18) in view of the ratings of the other areas.This would suggest that some rearrangement among them, or a reorientation within their content, should be considered.
2) The awareness areas could be augmented with new dimensions or information elements, for instance, in relation to the history of emotional state or the reasons for the collaborators to act as they do, although it is complex to infer why users do things.
3) The usefulness of the ADD visual language (MADD = 3.17) is not so good in comparison with its structural layer, therefore, there is room for improvement.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
4) Despite the structural components of framework being extensible, specifically the lists of devices and widgets proposed, the new devices proposed by the designers could be incorporated in the default catalog.

A. Threats to Validity
There are a few issues that could affect the validity of the experimental activities carried out.
The size of the population under study could be a limitation: 66 people evaluated the technique, from which only 50 users were able to create models and use the technique in practice; although they built a total number of 200 models corresponding to four requirements and two case studies (see Appendix D and E).
Admittedly, the participants came from three different universities and form a heterogeneous group.However, they were all studying the same bachelor's degree in computer science engineering in which human-computer interaction is taught; and, to reduce the variety in the domain knowledge, they were given a leveling and refresher seminar on the groupware subject.
Last, the understanding and modeling tasks approached by the participants were from four systems: telepointers, amusement park, skiing downhills, and excursions in nature.The collaboration was distributed and synchronous in all the cases, and both the interactions explicit and implicit, with the use of geolocalization, sonar, vibration, smell, and emotions apart from more common widgets and senses.Nevertheless, all this could be considered as a lack of variety.In future articles with an evolved version of the ADD, we will consider all types of collaboration and a higher and varied number of systems and tasks which will cover all the features of the technique.

VI. CONCLUSION
The focus of this article is on the awareness dimension of groupware applications, a somewhat forgotten feature in software engineering methods.This awareness support is intended to ensure the usability of a groupware system and the efficacy and efficiency of the computer-supported collaboration between users when performing a group task.The awareness services can be seen, therefore, as users' requirements, either functional or nonfunctional.
In order to contribute to the complex task of developing such support, the fulfillment of the users' requirements, we have designed a framework to be used as a guide by the developers of groupware systems.Two of its components are inherited from the AC, a previous effort in our research trajectory, and they allow designers as follows.
1) To identify areas and dimensions in which to place the system's functionalities regarding awareness, as well as relevant knowledge to deal with in order to provide awareness.2) To select widgets and devices that are applicable in the design depending on the senses or interaction categories involved.
These catalogs must be seen as extendible components that can be enriched with new areas, dimensions, widgets, and devices of awareness as they arise.
The third component of this framework is a new visual modeling language, which is the core of the present article; its aim is to specify awareness requirements.Thus, the awareness support is conceived as a collection of interventions, following this way a pattern which represents the occurrence of an event (or the fulfillment of certain conditions) that implies a reaction (set of operations), which commonly involves acting on the user interface with the result of providing awareness and improving collaboration.
The types of applications for which this approach is applicable range from classical desktop and direct interaction applications to mobile and ubiquitous computing and virtual worlds, including the use of haptic devices, affective user interfaces, and other new devices at the cutting edge of technology.
During the study of the awareness phenomenon and the validation of the proposal in this article, a small benchmark has emerged through which to evaluate and classify awareness modeling techniques, and which considers the following conditions.
1) The completeness of the technique, i.e., its support for the modeling of i) the awareness information in an organized way, ii) the dynamic context of the collaboration, and iii) the sources/targets of the awareness information flow.
2) The existence of a visual modeling language.
3) The evaluation of the technique as well as the visual language in terms of learnability and understandability.The approach and the visual language proposed have been assessed by potential designers of groupware by carrying out some modeling tasks and questionnaires of subjective evaluation.We can conclude that both the conceptual framework and the modeling language have learnability and are, in general, complete, understandable, and useful tools, and that the visual form of the language is preferred to the more textual one in terms of expressiveness.
We believe that for collaboration-intensive systems, awareness could be a significant dimension of modeling and development within software engineering as in other types of systems are the data, processes, time, or usability.Thus, our aspiration is to incorporate our proposed visual modeling language into established software engineering processes, such as agile methods, or structured or object-oriented methodologies, following the steps of task modeling tools, such as CIAM [43] or CTT [44].
In the short future, we are going to address the limitations and areas of improvement highlighted in the previous section, in parallel with the creation of a metamodel of the ADD using the eclipse modeling framework technology so that a visual editor can be available to support direct engineering and model-driven development starting from awareness requirements expressed visually.
We also need to think about the effect on the ADD framework of the rapid advances in computer science technology, which introduces new metaphors and interaction spaces in our activities, such as digital and virtual worlds, where the awareness mechanisms have to be rethought and reinterpreted so that users can enjoy successful collaborative experiences in any domain (e.g., social and affective relationships, sport and gaming activities, purchase-sale transactions, teaching-learning spaces, or production processes).

APPENDIX
A. Questionnaire of Task 1 1.Assess the comprehensibility (ease of understanding; the opposite would be difficulty of understanding) of the framework presented by areas (from 0, most difficult to understand, to 5, easiest to understand) as follows: • WA.
2. Do you miss any areas, dimensions, or information elements of awareness?Which ones?

B. Questionnaire of Task 2
Given the two techniques, the AC and the ADDs, compare them according to the following conditions.
1. Their degree of understandability (ease of understanding; the opposite would be complexity of understanding), by selecting the statement you most agree with: • The AC are much more understandable than the ADD.
• The AC are slightly more understandable.
• I cannot decide (equality).
• The ADDs are slightly more understandable.
• The ADDs are much more understandable.
2. Their ease of use (the degree to which the technique is easy to use; the opposite would be complexity): • The ACs are much easier to use than the ADD.
• The ACs are slightly easier to use.
• I cannot decide (equality).
• The ADDs are slightly easier to use.
• The ADDs are much easier to use. 3. Their degree of usefulness or expressive power (the degree to which the technique facilitates the description of awareness requirements): • The ACs are much more expressive than the ADD.
• The ACs are slightly more expressive.
• I cannot decide (equality).
• The ADDs are slightly more expressive.
• The ADDs are much more expressive.

C. Questionnaire of Task 4
Now that you have a better understanding of the ADD technique, and considering the above awareness requirements and their corresponding models as an example, assess the following: 1. Complexity of the ADD technique (degree to which it is difficult to learn and use; the opposite would be simplicity), from 0, no complexity, to 5, very complex 2. Being the usefulness the degree to which the indicated element facilitates the description of awareness requirements, assess (from 0, not useful, to 5, very useful): 1) The usefulness of the framework (areas, dimensions, and information elements of awareness).
2) The usefulness of the catalog of widgets and devices.
3) The usefulness of the ADD, as a descriptive language.

D. Case Study #1: Skiing in Group
Let us suppose a smartphone app connected to wearables to be used by a group of skiers during a simultaneous downhill.The trajectory of each participant is shown graphically in a map (R1: requirement 1).Also, the proximity between nearby skiers is notified by means of both a sonar-like audio cue and a vibrating bracelet each skier is wearing in one of their arms, in order to avoid collisions with the others (R2).The skiers can bring earphones to better hear the cues.

E. Case Study #2: University Enrollment System
In an enrollment system, several user profiles work together in order to enroll a student: in admissions, the student's preenrollment is carried out; in academic management, it is checked the validity of the documentation provided, and an appointment ticket is assigned; in enrolment, the request is collected at the established appointment and the enrollment fee is calculated; the enrolment is effective when it is marked as paid by accounting.Each user needs to be informed when the record is ready for processing and to know what the previous steps have been and with which collaborators.

Fig. 4 .
Fig. 4. Components of the ADD visual language.

Fig. 7 .
Fig. 7. Comparison between the AC and the ADD.

F
. Incomplete diagram from Case Study #1 and Task 3.1

TABLE I ANALYSIS
OF AWARENESS MODELING PROPOSALS

TABLE IV EVALUATION
OF THE SEMANTIC AND SYNTACTIC USE OF THE ADD