Fuks, H., Raposo, A., Gerosa, M.A., Pimentel, M. & Lucena, C.J.P.

(2007)
“The 3C Collaboration Model” in: The Encyclopedia of E-Collaboration,
Ned Kock (org), ISBN 978-1-59904-000-4, pp. 637-644.
Available at http://www.groupwareworkbench.org.br

The 3C Collaboration Model

HUGO FUKS1, ALBERTO RAPOSO2, MARCO AURÉLIO GEROSA1, MARIANO PIMENTEL1 & CARLOS
J. P. LUCENA1
1
Software Engineering Laboratory (LES) – Computer Science Department
Catholic University of Rio de Janeiro (PUC-Rio)
R. Marquês de São Vicente, 225, Gávea, Rio de Janeiro – RJ, 22453-900, Brazil
{hugo, gerosa, mariano, lucena}@inf.puc-rio.br
Phone: +55-21-3114-1500 x4304 Fax: +55-21-3114-1530
2
Computer Graphics Group (Tecgraf) – Computer Science Department
Catholic University of Rio de Janeiro (PUC-Rio)
R. Marquês de São Vicente, 225, Gávea, Rio de Janeiro – RJ, 22453-900, Brazil
[email protected]
Phone: +55-21-2512-5984 Fax: +55-21-3114-1848

1. INTRODUCTION
Collaboration may be seen as the combination of communication, coordination and cooperation.
Communication is related to the exchange of messages and information among people; coordination is
related to the management of people, their activities and resources; and cooperation, which is the
production taking place on a shared space. This model, which we call 3C model, was originally
proposed by Ellis et al. [1991], with some terminological differences. Cooperation, which Ellis
denominates “collaboration”, here characterizes a joint operation in a shared space.
The 3C model appears frequently in the literature as a means to classify collaborative systems, e.g.
as done by Borghoff & Schlichter [2000]. However, a few attempts have been made to use it in the
context of groupware implementation. An example is the Clover design model, which defines three
classes of functionalities, namely communication, coordination and production [Laurillau & Nigay,
2002, Calvary et al., 1997]. These three classes of services appear in each functional layer of the model
and, during the system design phase, they “must be identified and their access harmoniously combined
in the user interface”. The Clover model shares the same usefulness of the 3C model in terms of
groupware functional specification, because both deal with the three classes of functionalities that a
groupware application may support.
Given its complex interactive nature, groupware testing has not yet achieved its maturity. The 3C
model may also help evaluators focus their attention on the communication, coordination and
cooperation aspects, guiding the detection of usability problems. A groupware evaluation approach
based on a model similar to the 3C one is presented in [Neale et al, 2004].
We explore the 3C model as a means to represent a groupware application domain and also to serve
as a basis for groupware development. Regarding this last aspect, communication, coordination and
cooperation components could be plugged to the collaboration component frameworks.

2 . INSTANTIATING THE 3C MODEL

The relationship among the 3Cs of the model could be used as a guidance to understand a
groupware application domain. We are focused on the group work domain represented in Figure 1.
According to this instantiation of the 3C model, while communicating, people negotiate and make
decisions. While coordinating themselves, they deal with conflicts and organize their activities in a
manner that prevents loss of communication and of cooperation efforts. Cooperation is the joint
operation of members of the group in a shared space, seeking to execute tasks, generating and
manipulating cooperation objects. The need for renegotiating and for making decisions about non-
expected situations that appear during cooperation may demand a new round of communication, which
will require coordination to reorganize the tasks to be executed during cooperation.
generates commitments
Communication that are managed by
Coordination

fosters fosters
mediates mediates

Awareness

mediates fosters

demands arranges tasks for

Cooperation

Figure 1. 3C collaboration model instantiated for group work

Moreover, the 3C model can be instantiated in a way that represents other groupware domains like
Media Spaces and Family Calendars. Considering Media Spaces [Mackay, 1999], which are
multimedia-enhanced spaces aimed at informal communication among people, the 3C model may be
instantiated according to Figure 2a. The Media Space itself is the shared space. Since it is aimed at
informal communication, its main goal is actually to create opportunities for informal meetings, which
are coordinated by the standing social protocol, for example, by accessing the availability of remote
colleagues. These meetings generate conversation, which may occur using the media provided by the
system or any other available means, such as telephones.
Another example is the Family Calendar (Figure 2b). The main reason for the family calendar is to
schedule family activities. Modern family members have a variety of conflicting interests that can
render last evening defined schedules ineffective next morning. In order to restore proper family
coordination, negotiation among family members is needed. “This process involves seeing what has
already been scheduled, (…) and negotiating errand, ride and other responsibilities are needed” [Elliot
and Carpendale, 2005]. The reconciliation obtained after the negotiation round is placed on the shared
calendar. But as life never stops, next morning the cycle may start all over again.
Cooperation creates opportunities for Coordination Coordination demands Communication
(Media Space) (Social Protocol) (Schedules) (Negotiaton)
fosters fosters fosters fosters
mediates mediates mediates mediates

Awareness Awareness

mediates fosters mediates fosters

demands generates demands reconciliates

Communication Cooperation
(Informal) (Family Calendar)

(a) (b)

Figure 2. 3C collaboration model instantiated for the Media Space and for the Family Calendar domains
These cycles show the iterative nature of collaboration. The participants obtain feedback from their
actions and feedthrough from the actions of their companions by means of awareness information
related to the interaction among participants [Gerosa et al., 2003]. This awareness information
mediates each of the 3Cs, which are detailed in the next sessions.

3. COMMUNICATION
The designer of a communication tool defines the communication elements that will define the
communication channel between the interlocutors, taking into consideration the specific usage that is
being planned for the tool (time, space, purpose, dynamics and types of participants) and other factors
2
such as privacy, development and execution restrictions, information overload, etc. Then, these
elements are mapped onto software components that provide support to the specific needs.
The first communication element that must be considered is the choice of media. They can be
textual, spoken, pictorial or gestured, e.g., in a video or avatar form. The media adopted restrict and
influence the vocabulary used in the conversation, which is also influenced by the context.
The transmission mode defines whether the information is transmitted in blocks or continuously.
In an audio or videoconference and in some chat tools the information is transmitted continuously as it
is generated. In asynchronous and in other chat and messenger tools the information is transmitted in
blocks: the author edits the message and it is only sent with an explicit command. Asynchronous
communication tools are used when one wants to enhance reflection by the interlocutors, since they
will have more time before they act, while synchronous tools are used for communication bursts.
Restrictions policy is another communication element. For example, it is possible to restrict the text’s
size, characters allowed, bit rate (for video and audio), allowed vocabulary, etc. These restrictions are
used in some tools to reduce information overload and to save bandwidth.
Meta-information complements the information being transmitted in the body of the message.
Common meta-information available in communication tools are the subject of the message, its date,
priority and category.
Conversation structure defines how messages are structured, which can be in a linear,
hierarchical or network form. The conversation structure makes the relations between messages, which
are usually implicit within the text, visually explicit. The linear form is used when there are not so
many message interconnections, the chronological order of the messages is relevant and fluency in the
conversation is desired. Hierarchical structuring is appropriate when the relationships between
messages, such as questions and answers, need to be quickly identified. However, as there is no way to
link messages from two different branches, the tree can only grow wide and, thus, the discussion takes
place in diverging lines [Stahl, 2001]. Network structuring can be used to seek convergence in the
discussion.
Conversation paths can be used to restrict the possible directions the conversation can take.
Conversation paths formalize the conversation and it is not recommended when fluency is desired.
In order to provide proper support to communication, the designer should also take into account
coordination and cooperation elements. Coordination elements deal with access policies to the
communication channel, while cooperation elements deal with information rendering and registration.

4. COORDINATION
Coordination may be viewed as the link connecting the other two C’s in order to enforce the
success of collaboration. This is more clearly observed when we analyze the elements that need to be
coordinated, namely people, resources and tasks. The coordination of people, for example, is deeply
related to communication and context. The coordination of resources, on the other hand, is related to
the shared space (i.e., cooperation). For this reason, coordination aspects also appear in the discussion
about the other C’s of the model. In this section, we focus on the coordination of tasks. The
management of the tasks being carried out consists in managing interdependencies between tasks that
are carried out to achieve a goal [Malone & Crowston, 1990].
Some computer-supported collaborative activities, the so-called loosely integrated collaborative
activities are deeply associated with social relations and are generally satisfactorily coordinated by the
standing social protocol, which is characterized by the absence of any computer-supported
coordination mechanism—“a specialized software device, which interacts with a specific software
application so as to support articulation work” [Schmidt & Simone, 1996]—among the tasks, trusting
the users’ abilities to mediate interactions. Coordination, in these situations, is contextually established
and strongly dependent on mutual awareness. Through awareness information, the participants detect
3
changes in plans and understand how the work of their colleagues is getting along [Dourish & Belloti,
1992]. However, there are also the so-called tightly integrated collaborative activities, whose tasks are
highly interdependent, as the name suggests. They require sophisticated coordination mechanisms in
order to be supported by computer systems.
The great challenge of the designer in designing coordination mechanisms in groupware is to
achieve flexibility without losing the regulation, which is necessary in some situations in which the
social protocol is not enough. The system should not impose rigid work or communication patterns,
but rather offer the user the possibility to use, alter, or simply ignore them. Thus, coordination
flexibility and accessibility should be pursued by groupware designers. Flexibility is related to the
possibility of dynamically allowing redefinition and temporary modifications in the coordination
scheme. Accessibility is related to exposing the coordination mechanisms to system users rather than
having them deeply embedded in the system’s implementation.
Coordination can take place on the temporal and on the object levels [Ellis & Wainer, 1994]. On
the temporal level, coordination defines the sequence of tasks that makes up an activity. On the object
level, coordination describes how to handle the sequential or simultaneous access of multiple
participants through the same set of cooperation objects [Raposo & Fuks, 2002].
Communication and coordination, although crucial, are not enough. Given that coordination is
required to manage the tasks, according to the 3C model it is also necessary to provide a shared
workspace where cooperation will take place.

5. COOPERATION
Cooperation is the joint operation during a session within a shared workspace. Group members
cooperate by producing, manipulating and organizing information, and by building and refining
cooperation objects, such as documents, spreadsheets, artwork etc. The shared workspace provides a
number of tools for managing these artifacts, such as the recording and the recovery of previous
versions, access control and permission. By recording the information exchanged, the group is able to
count on collective memory, which can be consulted whenever necessary to recover the history of a
discussion or the context in which a decision was made.
Production is dependent on how the shared workspace is structured to present the cooperation
objects and the interaction that is taking place there. In a face-to-face situation, a large part of how we
maintain a sense of who is around and what is going on is related to being able to see and hear events
or actions with little conscious effort. On the other hand, in a computer-supported workspace,
awareness support is less effective since the means for making information available to sensory organs
are limited; however, irrelevant information can be filtered in a way that reduces distractions that
usually affect face-to-face collaboration.
Individuals seek the awareness information necessary to create a shared context and to anticipate
actions and requirements related to their collaboration goals. Thus, it becomes possible to interpret the
intentions of the members of the group in such a way that one can provide assistance in terms of their
work whenever it is convenient and needed [Baker et al., 2001].
The designer of a digital environment must identify what awareness information is relevant, how it
will be obtained, where it is needed and how to display it. Excessive information can cause overload
and disrupt the collaboration flow. To avoid disruption, it is necessary to balance the need to supply
information with care to avoid distracting the attention required to work. The supply of information in
an asynchronous, structured, filtered and summarized form can accomplish this balance [Kraut &
Attewell, 1997]. The big picture should be supplied and individuals could select which parts of the
information they want to work with, leaving further details to be obtained when required. There must
also be some form of privacy protection. The shared space must be conceived in a way that group
members could seamlessly move from awareness to work (Figure 3).

4
 COMMUNICATION COORDINATION

Transmission mode,
restrictions policy, media,
Interdependencies
conversation structure,
(resources and temporal)
meta-information,
conversation paths

structures defines
& &
negotiates enforces

executes executes
Execution of
the Task

creates modifies

feedback
feedback
C ooperation &
&
Objects feedthrough
feedthrough

captures information

Awareness

Shared
Space
COOPERATION

Figure 3. Interacting on a Shared Space

The register of group interactions is filed, catalogued, categorized and structured within
cooperation objects. Ideas, facts, questions, points of view, conversations, discussions, decisions, etc.
are retrievable, providing a history of the collaboration and the context in which learning took place.

6. DESIGN AND IMPLEMENTATION ISSUES

The 3C collaboration model has been used as a basis for the development of the AulaNet Learning
Management System. AulaNet is a freeware web-based environment for teaching and learning. It has
been under development since June 1997 by the Software Engineering Laboratory of the Catholic
University of Rio de Janeiro (PUC-Rio) [Fuks et al., 2005].
The AulaNet environment’s services are subdivided into communication, coordination and
cooperation services, as can be seen in Figure 4. The communication services provide tools for forum-
style asynchronous text discussion (Conferences), chat-style synchronous text discussion (Debate),
instant message exchange between simultaneously connected learners (Instant Messaging) and
individual electronic mail with the mediators (Message to Participants) and with the whole class, in a
list-server style (Message to the Class).
Coordination services support the management and the enforcement of group activities. In
AulaNet, coordination services include tools for notification (Notices), evaluation (Tasks and Exams)
as well as a tool that allows monitoring group participation (Follow-Up Reports). Cooperation services
in AulaNet include Lessons and Documentation, a list of course references (Bibliography and
Webliography) and course co-authoring support, both for teachers (Teacher Co-Authoring) and for
learners (Learner Co-Authoring).
During the design and implementation of groupware, the designer must have in mind that
collaborative applications must be flexible enough to adapt to group characteristics and to the
evolution of work processes. Although there is no way to foresee all features that will be demanded
from a groupware application, different groupware products share a number of characteristics.

5
 Communication

Message to the Class

conferencing Conference
systems Debate

message Instant Messaging

systems Message to Participant

Bibliography
Webliography Tasks
Documentation shared information Follow-Up Reports
Lessons space
Notices
Co-authorship intelligent
agents
group editors
Exams

electronic
meeting rooms workflow

Cooperation Coordination

Figure 4. Classification of AulaNet services based on the 3C Model.

The 3C triangle appears in Borghoff & Schlichter [2000]
This scenario is suitable for the application of component-based development techniques, which
provide the flexibility needed in projects with changing requirements. Groupware services can be seen
as groupware components that are plugged and unplugged from the system. The system’s architecture
comprises component frameworks, which define overall invariants and protocols for plugging
components.
AulaNet services were developed using a component-framework-based architecture, as can be seen
in Figure 5. There is a common structure implemented by the collaboration framework, which defines
the skeleton of the services, and plugged to this framework there are the communication, the
coordination and the cooperation component frameworks, which support each C of the 3C model.
Class frameworks are used to implement components, which are plugged to the corresponding C-
framework and implement the specific functionalities of the service.

Communication
Component
Framework Asynchronous
Collaboration
Framework Communication
Conference Channel Component
Coordination
Component
Framework
Access Control
Component
Cooperation
Component
Framework

Shared Space
Component

Figure 2. Architecture of a collaboration service.

For example, using the communication class framework, the developer implements components for
synchronous and asynchronous communication, message transmission etc. Using coordination class
framework, components for task management, participation follow-up, workflow, etc. are
implemented. Using cooperation class framework, components for managing the shared space and its
awareness elements, version management, among others are implemented.

7. CONCLUSION
Groupware systems are evolutionary because the composition and the characteristics of
workgroups change with time, as well as the tasks that need to be executed. For this reason, even if a
6
groupware designer is able to develop an “optimal” application for a group, it will eventually become
inadequate due to new situations and problems that certainly will appear.
Ideally, groupware should be prototyped because collaborative systems are especially prone to
failure [Grudin, 1989], hence demanding iterative evaluation during their development. However,
given the excessive cost of throwing code away, as demanded by “pure” prototyping [Brooks, 1975],
an incremental model can be considered more adequate, leading to the development of more advanced
prototypes in the subsequent cycles.
In face of construction and maintenance difficulties, the groupware developer spent more time
dealing with technical difficulties than moderating and providing support to the interaction among
users. Such problems led to the need to create a quicker and more effective way to develop groupware
in which low-level complexities resulting from distributed and multi-user systems were encapsulated
into infrastructure components of the architecture. Besides, the concepts of the domain’s modeling
should permeate all other activities and artifacts of the application’s development. This way, the
modeling done during the domain analysis could be mapped to implementation, thus increasing
productivity in groupware development and maintenance and making the applications more adequate
to the users’ collaboration needs.
The 3C collaboration model defines three types of services that a groupware may support. The
concepts and representation models described in this paper can be used to guide the functional
specification and to provide a common language for representing and describing the collaboration
aspects of a workgroup.

ACKNOWLEDGMENTS
The AulaNet project is partially financed by Fundação Padre Leonel Franca and by the Ministry of
Science and Technology through its Program Multi-Agent Systems for Software Engineering Project
(ESSMA) grant nº 552068/2002-0. It is also financed by individual grants awarded by the National
Research Council to: Carlos José Pereira de Lucena nº 300031/92-0, Hugo Fuks nº 303055/02-2,
Alberto Barbosa Raposo nº XX-X and Marco Aurélio Gerosa nº 140103/02-3. Thanks to Prof. Marcelo
Gattass, Head of Tecgraf/PUC-Rio, a group mainly funded by Petrobras, Brazilian Oil & Gas
Company.

REFERENCES
Baker, K., Greenberg, S. & Gutwin, C. (2001): Heuristic Evaluation of Groupware Based on the
Mechanics of Collaboration. 8th IFIP International Conference (EHCI 2001). Lecture Notes in
Computer Science Vol. 2254, pp. 123-139, Springer-Verlag.
Borghoff, U.M. and Schlichter, J.H. (2000): Computer-Supported Cooperative Work: Introduction to
Distributed Applications. Springer, USA.
Brooks Jr., F.P. (1975): Plan to Throw One Away. In: The Mythical Man-Month – Essays on Software
Engineering, chap. 11, pp. 115-123. Addison-Wesley.
Calvary, G., Coutaz, J., Nigay, L. (1997): From Single-User Architectural Design to PAC*: a Generic
Software Architectural Model for CSCW. Conference on Human Factors in Computing Systems
(CHI’97), pp 242-249.
Dourish, P. & Belloti, V. (1992): Awareness and Coordination in Shared Workspaces. In J. Turner and
R. Kraut (eds): Conference on Computer-Supported Cooperative Work (CSCW), pp. 107-114.
Elliot, K. & Carpendale, S. (2005): Awareness and Coordination: A Calendar for Families. Technical
Report 2005-791-22, Department of Computer Science, University of Calgary, Calgary, Alberta,
CANADA, T2N 1N4, May.

7
Ellis, C.A., Gibbs, S.J. & Rein, G.L. (1991): Groupware - Some Issues and Experiences.
Communications of the ACM, Vol. 34, No. 1, pp. 38-58.
Ellis, C.A. & Wainer, J. (1994): A Conceptual Model of Groupware, In T. Malone (ed): Conference
on Computer-Supported Cooperative Work (CSCW), pp. 79-88.
Fuks, H., Raposo, A.B., Gerosa, M.A. & Lucena, C.J.P. (2005): Applying the 3C Model to Groupware
Development. International Journal of Cooperative Information Systems (IJCIS), v.14, n.2-3, Jun-
Sep 2005, World Scientific, pp. 299-328.
Gerosa, M.A., Fuks, H. & Lucena, C.J.P. (2003): Analysis and Design of Awareness Elements in
Collaboration Digital Environments: A Case Study in the AulaNet Learning Environment. The
Journal of Interactive Learning Research, Vol. 14, No. 3, pp. 315-332.
Grudin, J. (1989): Why Groupware Applications Fail: Problems In Design And Evaluation. Office:
Technology and People, Vol. 4, No. 3, pp. 245-264.
Kraut, R. E., & Attewell, P. (1997): Media use in global corporation: electronic mail and
organisational knowledge, Research milestone on the information highway, Mahwah, NJ: Erlbaum.
Laurillau, Y. & Nigay, L. (2002): Clover architecture for groupware, Conference on Computer-
Supported Cooperative Work (CSCW), pp. 236 - 245
Mackay, W. E. (1999): Media Spaces: environments for Informal Multimedia Interaction. In M.
Beaudouin-Lafon (ed): Computer Supported Co-operative Work (Trends in Software: 7). John
Wiley & Sons, England, pp. 55-82.
Malone, T.W. & Crowston, K. (1990): What is Coordination Theory and How Can It Help Design
Cooperative Work Systems? Conference on Computer-Supported Cooperative Work (CSCW), pp.
357-370.
Neale, D. C., Carroll, J. M. & Rosson, M. B. (2004), Evaluating Computer-Supported Cooperative
Work: Models and Frameworks. Conference on Computer-Supported Cooperative Work (CSCW),
pp. 112-121.
Raposo, A.B. & Fuks, H. (2002): Defining Task Interdependencies and Coordination Mechanisms For
Collaborative Systems. In M. Blay-Fornarino, A.M. Pinna-Dery, K. Schmidt and P. Zaraté (eds):
Cooperative Systems Design (Frontiers In Artificial Intelligence and Applications Vol. 74). IOS
Press, Amsterdam, pp. 88-103.
Schmidt, K. & Simone, C. (1996): Coordination mechanisms: Towards a conceptual foundation of
CSCW systems design. Computer Supported Cooperative Work, Vol. 5, No. 2-3, pp. 155-200.
Stahl, G. (2001): WebGuide: Guiding collaborative learning on the Web with perspectives, Journal of
Interactive Media in Education.

8
Indexer Reference List for: Encyclopedia of E-Collaboration
Editor: Ned Kock, Ph.D.
Chapter Title: The 3C Collaboration Model
Author: HUGO FUKS, ALBERTO RAPOSO, MARCO A. GEROSA,
MARIANO PIMENTEL, CARLOS J. P. LUCENA

Term 1 – 3C Collaboration Model

• Also appears in text as: 3C Model.
• Also known as: n/a
• Similar to: n/a
• Associated in the manuscript with: “Groupware”, “Computer Supported Cooperative Work”,
“Collaboration”, “Communication”, “Coordination”, “Cooperation”
• Notable appearances of this term can be found on:
Page 1 - This model, which we call 3C model, was originally proposed by Ellis et al. [1991]
Page 1 – The relationship among the 3Cs of the model
Page 5 - The 3C collaboration model has been used as a basis for the development of the AulaNet
Learning Management System
Page 7 - The 3C collaboration model defines three types of services that a groupware may
support.

Term 2 – Collaboration
• Also known as: n/a
• Similar to: “Computer Supported Cooperative Work”
• Associated in the manuscript with: “Groupware”, “3C Collaboration Model”
• Notable appearances of this term can be found on:
Page 1- Collaboration may be seen as the combination of communication, coordination

Term 3 – Groupware
• Also known as: n/a
• Similar to: “Computer Supported Cooperative Work”
• Associated in the manuscript with: “3C Collaboration Model”, “Collaboration”
• Notable appearances of this term can be found on:
Page 1 - We explore the 3C model as a means to represent a groupware application domain and also to
serve as a basis for groupware development.
Page 1 - The relationship among the 3Cs of the model could be used as a guidance to understand a
groupware application domain.
Page 2 - the 3C model can be instantiated in a way that represents other groupware domains
Page 6 - Groupware systems are evolutionary because the composition and the characteristics of
workgroups change with time, as well as the tasks that need to be executed.

Term 4 – Communication
• Also known as: n/a
• Similar to: “communication elements”, “communication components”, “communication channels”
• Associated in the manuscript with: “3C Collaboration Model”
• Notable appearances of this term can be found on:
Page 1 - Communication is related to the exchange of messages and information among people
Page 2 - The designer of a communication tool defines the communication elements that will define the
communication channel between the interlocutors

Term 5 – Coordination
• Also known as: n/a
• Similar to: “coordination mechanisms”, “coordination components”
• Associated in the manuscript with: “3C Collaboration Model”

9
 • Notable appearances of this term can be found on:
Page 1 - coordination is related to the management of people, their activities and resources
Page 3 - Coordination elements deal with access policies to the communication channel
Page 3 - Coordination may be viewed as the link connecting the other two C’s in order to enforce the
success of collaboration.
Page 4 - The great challenge of the designer in designing coordination mechanisms in
groupware is to achieve flexibility without losing the regulation
Page 4 - Coordination can take place on the temporal and on the object levels

Term 6 – Cooperation
• Also known as: “production”
• Similar to: “cooperation elements”, “cooperation components”, “cooperation objects”
• Associated in the manuscript with: “3C Collaboration Model”
• Notable appearances of this term can be found on:
Page 1 - and cooperation, which is the production taking place on a shared space.
Page 1 - Cooperation, which Ellis denominates “collaboration”, here characterizes a joint operation in a
shared space.
Page 3 - cooperation elements deal with information rendering and registration.
Page 4 - Cooperation is the joint operation during a session within a shared workspace.

Term 7 – Awareness
• Also known as: n/a
• Similar to: “awareness elements”, “group awareness”, “action awareness”, “workspace awareness”,
“presence awareness”, “social awareness”
• Associated in the manuscript with: “3C Collaboration Model”
• Notable appearances of this term can be found on:
Page 2 - The participants obtain feedback from their actions and feedthrough from the actions of their
companions by means of awareness information related to the interaction among participants
Page 2 - This awareness information mediates each of the 3Cs
Page 3 - Through awareness information, the participants detect changes in plans and understand how
the work of their colleagues is getting along
Page 4 - Individuals seek the awareness information necessary to create a shared context
Page 4 - The designer of a digital environment must identify what awareness information is relevant,
how it will be obtained, where it is needed and how to display it.

10