Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

whittaker

VIEWS: 6 PAGES: 12

  • pg 1
									             Why Email is not Enough:
Combining Communication and Shared Representation
         to Support Activity Management


                                     Steve Whittaker
                                    University of Sheffield

                       Thomas P. Moran, Stephen P. Farrell
                               IBM Almaden Research Center

         THIS IS AN INCOMPLETE DRAFT, WHICH WE ARE MAKING
       AVAILABLE ONLY TO THE ACTIVITY WORKSHOP PARTICIPANTS.
                       PLEASE DO NOT CIRCULATE!

Email is Not Enough
Modern work is highly communication-centric. Research shows the critical role that
communication applications - in particular email - play in everyday work. Email is used to
organize and delegate tasks, to manage communications, as an archival repository for work
documents and as a contact manager (Bellotti et al., 2005, Duchenaut and Bellotti, 2001,
Whittaker, 2005, Whittaker and Sidner, 1996).

However, there are numerous problems using email for task management (Bellotti et al., 2005,
Whittaker et al., 2002, Whittaker, 2005). Users relying on email complain about:

   •   forgetting commitments from self and others (tasks that they ‘owe’ or are ‘owed’)
   •   tracking global task status (it’s hard to abstract from multiple messages to determine
       where a project currently stands)
   •   determining who’s involved in a complex task
   •   integrating information across different technologies (people may communication about a
       task in email, voicemail or using IM – and it’s often hard to combine information)
   •   managing attachments.

Partly because of these problems, there have been various attempts made to develop alternative
models and technologies for collaboration. The most significant of these are shared workspaces
such as TeamRooms and more recently Wikis. The defining feature of these technologies is that
they support collaboration using a Shared Representation - which provides the structure into
which participants can publish their contributions, or organize collections of objects.

Let us consider a system that addresses activity management by providing a shared representation
of activities.


ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                      1
Unified Activity Management
In IBM Research, we are concerned with the larger context of work than is captured by
communication tools. We believe that by the notion of “activity” is the pivotal concept. Shared
workspaces are used mostly to capture representations of the content of an activity, not the
activity itself. The Unified Activity Management (UAM) project hypothesizes that an explicit
representation of the activity itself is beneficial (Moran, 2005). By the larger context of work, the
“activity itself,” we mean:

            o    the social arrangements: who is involved and in what way;
            o    the plan of work: the work breakdown and who’s responsible for what;
            o    the temporal constraints of the work such as deadlines;
            o    the relevant resources: the materials used, worked on, and produced (the object of
                 the work); and
            o    the relationships to other activities, such as dependencies, similar cases, patterns,
                 and just vague relatedness.

To address all these facets, we need a comprehensive representation - Unified Activity. It is called
“unified” because the representation must cut across the various tools and systems that users must
deal with and provide a generic representation that captures the common essential elements of
what we mean by activity, especially informal collaborative activity (Moran, Cozzi, & Farrell,
2005).

Unified Activity is an extensible schema for constructing explicit representations of activities by
the participating actors themselves for purposes of managing the activities (Moran, 2003).
Descriptions of specific activities reside in a database. These descriptions can be manifested in
several different kinds of external representations: todo lists, timelines, resource clusters and
piles, discussion trees, social networks, etc. A basic, familiar external representation is a
checklist. We have implemented prototypes based on the metaphor of a shared hierarchic
checklist. It is shared to support coordination and awareness across collaborators.

Figure 1 shows an example of a shared hierarchic checklist. The checklist is in the left panel. It is
a hierarchy of activities and subactivities. The example is the activity of writing a proposal to
respond to an RFP (request for proposals), labeled “RFP #0518 from Company A.” This activity
has several subactivities, giving the basic work breakdown: to assess the opportunity, assemble a
team, plan the response, prepare the proposal, etc. Each of these subactivities has different
people, resources, deadlines. The figure shows that the user is focused on the activity
“clarification with Company A,” a subactivity of planning the response. The right panel shows a
description of the activity, its status, and the constituent people (and roles), resources, and events.
The orange in the box for the activity signals that it is critical because of delays in scheduling
Company A’s VP. All the participants can see this activity description, which summarizes the
current state.




ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                             2
Figure 1. An example of a unified activity representation
for the activity of writing a proposal in response to an RFP.
(shown in our Eclipse-based prototype client).



With this example in mind, let us return to the notion of activity management. Activity
management is meta-work (sometimes called “articulation work” [ref]), i.e. the work needed to
do the “real work.” Activity management includes the following kinds of meta-work:
             o being reminded or alerted to do the activity;
             o setting up the environment to do the activity;
             o coordinating the work with others;
             o switching between activities;
             o responding to unanticipated interruptions;
             o overviewing and orienting to the activity;
             o organizing, planning, and scheduling the activity;
             o accounting for, reporting on, and documenting the activity.

Activity representations, such as the one in Figure 1, are thus representations to support the meta-
work of managing an activity. The substance of the activity is supported by domain-specific
representations, such as the RFP document or the meeting agenda document.

In supporting meta-work, the shared checklist is a place to represent complex information about
the structure of the activity, its participation, status, etc. (If the activity was carried out solely by
email, then this kind of information would be implicit or dispersed in the email stream.) Having


ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                               3
the checklist encourages participants to be explicit about the work and its allocation, and thus to
negotiate so that the work is distributed appropriately. As the work proceeds, people can work in
parallel and attach key results of their work into the checklist. The participants can track the
overall state of the activity, and coordinate with others as needed.

But this is still not the whole story, of course. People still have to communicate (such as by
email), and so the checklist does not replace communication, but rather complements it.

Communication and Shared Representation
Both communication and shared representation are needed in activity management. We want to
understand how these two techniques combine to support collaboration. We first discuss
theoretical and empirical work that examines the roles that communication and representations
play in collaboration. We use this discussion to present a theoretically motivated framework for
comparing these approaches - which helps highlight the strengths and weaknesses of each
approach. We then use this framework to return to the UAM system to assess how
communication and shared representation support activity management.

Clark’s theory of common ground elaborates the underlying processes involved in collaboration
(Clark and Brennan, 1991). The theory proposes that common ground is the backdrop that makes
collaboration possible. Common ground is both the understanding shared by participants and a
protocol for maintaining that understanding. Common ground can also be supported by an
external representation – the aspect of the theory we explore here.




Figure 2: Talk and Representation Combine to Support Scheduling a Meeting.



ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                         4
Various studies have employed the concept of common ground to examine the interplay of
communication and shared structures to organize synchronous collaboration - probing the relation
between talk and artifacts (Bly, 1998, Tatar et al., 1991, Tang, 1991). In one such study
(Whittaker et al., 1991) we investigated how talk and representations combine to support
collaboration. We gave 3-person distributed teams a shared workspace which supported both text
chat and collaborative drawing to carry out co-ordination and design tasks; such as arranging a
meeting or deciding on criteria for a house purchase. Teams were not instructed as to how they
might use the shared workspace to solve the task, as we were interested in how groups would
negotiate this. As we discuss below there were major differences in modus operandi: some teams
chose to generate representations such as Figure 2 for scheduling while others relied exclusively
on textual communication for this. These differences in group strategy allowed us to compare the
contributions of communication and representation in solving the task

Figure 2 shows a team carrying out a scheduling task. The team initially used textual
communication to determine their modus operandi setting up the matrix representation for the
days and times of the week. They erased their initial conversation and proceeded with the task in
parallel by entering their respective available times into the matrix supplementing data entry with
textual communication to clarify and confirm what went on in the matrix. The figure shows the
final configuration with the completed matrix combined with discussion/comments about what
had been decided.

Overall across our 12 subject groups we observed two main benefits for textual communication.
Text-based communication was effective for simple exchanges such as providing small amounts
of information, or answering quick questions. It was also invaluable when participants were
negotiating their modus operandi i.e. how they would carry out the task. However textual
communication was both laborious and error-prone for complex exchanges involving large
amounts of information. Some teams attempted to schedule by relying solely on textual
communication – stepping through various potential meeting times: (“Is anyone free on Mon 9-
11?”), collating people’s responses and then continuing (“OK. How about Tues at 12 then?”) if
this was not a good time for meeting. Groups who relied solely on textual communication and did
not used representations performed worse overall on objective task metrics than other groups who
chose to use representations. One obvious reason for this is that the serial nature of textual
communication does not allow people to collect or collate complex information, in the way that a
shared representation does.

In contrast, shared representations were highly efficient for organizing complex content. They
provided a structure for group contributions that allowed the teams to work in a highly parallel
manner, entering data independently without communication. They also allowed participants to
straightforwardly track group progress through their task to determine how much of the task
remained or who had yet to contribute. But these advantages were offset by several problems.
First, representations had a high overhead and start up cost. Participants who used shared
representations needed to dedicate a substantial part of their problem solving time to collectively
deciding on an appropriate representation for the task, and then setting up this representation
before they could proceed to the task itself. A second problem was alerting. Shared
representations allowed participants to work in a highly parallel manner but this meant that is was
often difficult to attract the attention of others, e.g. to clarify an entry they had made, or to check
a potential solution. Participants usually started by using textual communication to attract
attention. This often failed so they resorted to writing in the representation or in others’ dedicated




ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                             5
workspaces – which sometimes interfered directly with their work, but was always successful in
getting their attention.

Finally, in addition to comparing the functions of textual communication and representations, we
were also able to examine their interplay. For example, communication precedes representation;
communication is needed to negotiate and agree on the representation at the outset. Secondly
communication is used to address problems with the representation.

Let us summarize our results so far by articulating some issues that serve as dimensions for
analyzing the tradeoffs between using communication and representations:

Focus

This is crucial in helping people determine what aspects of the task are important. Alerting
messages can help to orient people about what to focus on, and multi-tasking is when people
switch focus. In general communication applications are poor at signaling focus, as there are no
methods (other than recency discussed below) for signaling importance. In contrast a well-
designed representation can show people where to focus their efforts.

Recency

Recent events often have to be responded to next. Communication applications are temporally
ordered by default and so they naturally indicate recency. Unless they are specifically designed to
do so, representations do not usually depict recency.

Organization of work

Organisation is critical for successful collaboration. Plans are one example of organization, and a
plan may include both parallel activities (those that can be done independent of each other), and
dependent activities (where one activity is a pre-requisite for another). A key function of
representations is to show plans, whereas plans only tend to be implicit in communications.
Explicit plans serve as an organizational framework allowing collaborators co-ordinate their
contributions.

Common ground

Common ground is the shared understanding that holds between participants, and this is vital for
collaboration. Representations are a highly effective way of fostering common ground as they are
persistent, integrative, and shared. Asynchronous communication such as email are often not fully
shared (as not everyone in a collaboration receives all messages). A further weakness of
asynchronous communication in this context is that it fades in time, as messages become less
recent.

Annotation

Email is highly expressive (anything can be said can be said in it), whereas representations are
constrained to the “language” of the representation. Indeed a design feature of representations is
that they are intended to constrain contributions in order to structure and co-ordinate activities.

Start up & maintenance




ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                         6
One obvious weakness of representations are that they have costs associated with generating them
(which often involves lengthy negotiation between collaborators). In contrast, conversations can
be applied to any task or situation (provided of course that the collaborators shared the same
language).

Reusability

A related issue is reusability. One way to defray the costs of setting up a representation is to reuse
one generated for other purposes.

Assessing Collaboration Technologies

We can use these observations to evaluate the communication and representation-centric models
of collaboration.

Communication Applications (in Particular Email)

In this discussion we mainly focus on email as this is the predominant communication technology
used to support collaboration. Our empirical analysis of the strengths and weaknesses of
communication is echoed by research evaluating email. Just as we observed with textual
communication in our experiment, email (another predominantly textual communication method)
is highly effective for simple tasks, e.g. answering questions, or providing information. It is much
less effective however, for complex tasks where there is a need to organize multiple
communications from different people or responses that are distributed over days or even weeks.
Email users are engaged in multiple concurrent tasks, and they experience major problems in
trying to collate complex information across multiple interleaved message sequences, where
information about a given complex task may be interspersed with messages about unrelated tasks.
For example arranging a multiperson meeting is often highly inefficient in email, as is trying to
collate complex project information (Whittaker et al., 2002). Attempts to rely on manual
foldering for collation do not succeed, both because of the inherent cognitive difficulty
categorizing messages, and the fact that many users do not use folders (Whittaker and Sidner,
1996). Threading using header information also does not succeed because of the weakness of
subject line as a cue to underlying message task (Whittaker, 2005).

Various new technologies have been developed to address these email problems by providing
support for abstracting high-level structures from the email communication stream - allowing
users to collate related information together. Both Whittaker et al. (1997) and Bellotti et al.
(2003) provide users with support for organizing and collating information related to a specific
task. Both approaches use a combination of subject line, and sender to automatically identify
task-related information, and in both cases users can reorganize or reclassify information
manually. A different approach to information collation is taken in ContactMap where messages
can be viewed or organized in terms of social network structures represented directly in the
interface. For example ContactMap provides support for users identifying and organizing
important people in the user’s worklife – allowing them to straightforwardly construct social
organizations related to work projects – which can then be used to organize and access
communications. For example, users can find information associated with a project by accessing
the part of the social network representation that relates to that project.

One weakness of these approaches however is that they are fragmented and single-faceted,
providing either task-centric or social network-based views of information. It would seem



ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                            7
however that a solution to this problem requires support for both views of information, allowing
users to collate information using multiple organizational cues.

Shared Workspaces

In the same way we can apply insights from the collaboration study to understand and evaluate
representational technologies such as TeamRooms and Wikis. These technologies are successful
for example when activities are highly parallisable (Whittaker, 1996), or when expertise is
distributed and the task divisible (Wikipedia). In these cases, the technologies are very efficient;
teams can work in a highly parallel manner, using the representation itself to inspect how they are
proceeding with their collective task, rather than having to communicate about it. (Note, however,
that that Wiki's “work” because of the integration of the representation with the change log,
which solves problems like finding out what's changed, and providing a way to undo a change.)

Just as in our experiment, however, one of the major limitations of these technologies is start-up
cost, with many users preferring to inefficiently undertake tasks in email rather than migrate to a
TeamRoom because of the initial effort involved in doing this. Representations such as
teamrooms are also ineffective when the task involves large amounts of negotiation, as
participants then find it hard to identify a representational structure that they can agree to use
(Orlikowski, 1992). There are also significant issues involving alerting. How can users be kept
informed about potentially important changes made to other parts of the representation, when
they are engaged in highly parallel activity in different parts of the representation? One solution is
to use communication to alert them about important changes, but this approach potentially
overloads users with multiple messages concerning parts of the representation that are irrelevant
to their current activities.

Adding Communication to UAM

All activity management cannot be done thru representations like the checklist. There is a great
deal of necessary communication - email, instant messaging, telephone, and face-to-face. There
are different approaches to support communication in activity management: (1) providing
communication within the activity management system, (2) having the activity system work with
email, and (3) some blend of the two. A companion project to UAM, Activity Explorer (Muller et
al., 2004) it taking the first approach. It is providing a discussion style of organizing documents,
notes, chats, etc. in a thread of responses. This approach attempts to replace email with a different
form of communication. UAM has been exploring the 2nd approach. A hint of this can be seen in
Figure 1. On the bottom right is a button “Open Inbox.” This triggers the email client to bring up
its inbox view right next to the UAM client. The user can select messages in the inbox and
associate them with the selected activity in the UAM client. In this way, related messages are part
of the activity description. The UAM client can trigger the email client to filter the inbox to show
only the messages associated with the current activity. Thus the two clients work closely together
to keep the user “activity centered.” We currently have a more sophisticated version of this. It is
an activity plug-in the the Mozilla email client, Thunderbird. The email client has its own
condensed view of activities, and the user can work only in email. But the plug-in exchanges
activity information with the UAM server, and so the user can go to the UAM client to work in
the activity checklist view.

UAM is now exploring a blended approach. The part of the unified activity representation shown
above is the structural part; it describes the current state of an activity. The dynamic, temporal
part of UAM is the Activity Log. There is an Activity Log associated with each activity, which
shows the sequence of the communications taken to manage the Activity. The Activity Log is like


ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                            8
a blog: a sequence of entries. The entries can be of different kinds. The simplest log entry is a
Note, a simple posting to the activity. Notes can also be about or in response to other entities in
the Activity. A Note can be posted in response to another Note (simple threading). Or a Note can
be about a document that is a resource of the Activity. This Note is not only associated with the
activity, but also with the document. So I can later filter the log to see just the notes that are
associated with the document. Finally, I can send a Note as an email and emails can be captured
as logged Notes. Thus the Activity Log is the communication component of UAM and the
checklist is the representation. These are both necessary and complement each other.

As the communication component of UAM, the Activity Log optimal for short exchanges:
questions, requests, clarifications, discussions. The log is temporally organized. The most recent
entries are the most relevant, and they lose their relevance over time, that is they are ephemeral.
(It is for this reason that the Activity Log is organized in reverse chronological order.) Whenever
a Note entry contains some content (in the body or as an attachment or pointer) that should
persist, the user can add the content to the resources of the Activity, where it will stay visible over
time. This Note will then be about the the newly-added resource. A Note can also be about an
Event (e.g. “the meeting needs to discuss the new requirements”) or about an Involvement (e.g.
“John will take the lead from Jim”). Thus the Activity Log can be filtered to show the
communications about any entity. The importance of expressing a referent of an statement is
shown in the experiment in Figure 2, where the subjects placed their statements near the elements
of the matrix they were referring to. This gave up the sequential structure of the communications
and it cluttered up the representation. The scheme here – a temporal log filterable by referents –
preserves the temporal order and does not clutter the representation.

Costs of Representing Activities

As users work, they have a choice about whether to organize and manage their work using an
explicit activity representation like the checklist or use “traditional” means like email. The added
cost of the explicit representation can be reduced by appealing to a common metaphor – the
checklist – so they do not have to invent such a representation (as the subjects in the scheduling
study did). Even so, they do have to take the trouble to write down the activities, associate the
people, attach the documents, etc.         Some of this can be mitigated by fluid user interface
techniques. For example, simply dragging a document from the desktop into the checklist client
causes an activity to be created with the document as the resource; people can be associated by
dragging their icons from a buddy list; etc.

Another powerful concept is an Activity Pattern. A pattern comprises the reusable parts of the
activity abstracted from the idiosyncrasies. For example, the respond-to-RFP activity is
initialized by instantiating a pattern that gives an activity structure embodying the practice at that
company. In addition to the sequence of necessary steps, the pattern can contain references to the
documentation, tools, and people that others have found helpful. Since patterns can be modified
like other activities, they provide both a guide to doing complex processes, as well as a way for
those who are so-inclined to make their insights and connections available to others. That said,
people still have to detail the specific work plan embodied in the pattern for each case, but the
discussions involved in doing this seem like good work practice.

People will use an explicit activity representation only if it makes their work easier. An explicit
activity structure promises to do this by:

            1. Encouraging consensus to be reached early by dividing the work up into
               components and assigning those components to team members;



ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                             9
            2. Enabling ongoing negotiation of the scope and roles played in the activity by
               maintaining the activity structure as the work proceeds;

            3. Displaying a shared representation of that work as an interactive artifact in each
               team member's work space;

            4. Providing people, tools and resources at close proximity (“setting a context for
               the activity”), and making it easy to create new associations;

            5. Supporting a temporal overview of the activity, including what's changed, who's
               done what, and what new resources are available (even if facets of the activity
               are taking place in diverse tools).

In stressing the first four of these, the checklist enhances good work practices, like organization
and planning. However, we think that the success of activities will turn on how well activities
bridge the gap between planning and acting. Part of this gap can be illustrated by the issue of
alerting. The client in Figure 1 is fairly primitive in this regard. It highlights activities that
changed since you last looked at them (like email’s “unread” messages). This is not satisfactory,
since everyone doesn’t want or need to see every activity. The color-coded alert signs (e.g. the
orange in Figure 1) are set manually so people can draw attention of others. Another component
of the gap is that many things simply cannot be communicated by the checklist or any other
activity structure, and for these things people rely on informal communication through messaging
and voice. For example, negotiating who is assigned to subtasks and assessing priorities are
difficult to do at best by manipulating a checklist. Alerting and informal communication share a
dependency on time and, in fact, are likely to be intertwined temporally. For example,
assignment might induce a conversation which, in turn, results in a new assignment. For this
reason, it is important to understand the interaction between planning, communicating and
notification.

Outstanding Issues

We believe that Activities can combine the benefits of communication and representation to
address problems with traditional technologies to support activity management. Nevertheless
there are several outstanding theoretical, empirical and design issues associated with the
Activities approach:

    •   Identifying when to use Activities instead of Communication. We have established that
        communication approaches are effective for simple tasks, and that representational
        approaches are only worthwhile for complex tasks, given representational start-up costs.
        But how do we characterize the set of tasks for which Activities will be valuable? If we
        know this we can give users guidance about when it’s worth the extra work of creating an
        Activity rather than using email. This is both an empirical and a theoretical question.

    •   Making Activity Creation Lightweight. One major barrier to practical use of Activities is
        that as representations they have start-up costs. One crucial way to reduce these start up
        costs is to create a catalogue or library of Activity instances. Users can then draw on
        these, selecting and modifying a pre-existing instance of a related Activity rather than
        designing a new Activity representation from scratch. Again there is much empirical
        work to be done here to determine repeated patterns of Activities, and identifying
        similarities and differences between them, in order to organize and design a useful set of
        Activities that users can exploit. There is also design work needed in cataloguing to make


ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                        10
       it easy for users to identify Activities related to their current collaborative task. Finally
       careful software design will be needed to ensure that Activities can be created in the
       minimum number of user steps – an approach which favors developing simple activity
       representations first and then building up to more complex instances. We have already
       begun work evaluating different lightweight interface designs for supporting Activity
       (Muller, ).

   •   Integrating Activities with Communication Applications. We have already documented
       the communication-centric nature of collaboration and the critical role that applications
       such as email have in supporting that activity. We have also demonstrated the interplay
       between communications and representation for negotiation and alerting. It is therefore
       critical that any new form of representation such as Activities, be tightly integrated with
       communication applications such as email, so that alerts, logs and commitments can be
       accessed and viewed through communication. Such integration is necessary both because
       email is the most frequently used application for most users, but also because
       collaboration teams might involve participants who make minimal use of the Activity
       software but who nevertheless need to be kept current with aspects of the collaboration.


References

   1. Bellotti, V., Ducheneaut, N., Howard, M., Smith, I.E. (2003). Taking email to task: the
      design and evaluation of a task management centered email tool. In Proceedings of
      CHI2003, 345-352. New York: ACM Press.

   2. Bellotti, V., Ducheneaut, N., Howard, M., Smith, I.E. & Grinter, R.E. (2005). "Quality
      Versus Quantity: Email-Centric Task-Management and its Relationship with Overload."
      Human-Computer Interaction, 20(1 & 2).

   3. Bly, S. (1988). A use of drawing surfaces in collaborative settings. In Proceedings of
      Conference on Computer Supported Cooperative Work, 250-256, New York: ACM.

   4. H.H. Clark, S.A. Brennan, Grounding in communication, in: L.B. Resnick, J.M. Levine,
      S.D. Teasley (Eds.), Perspectives on Socially Shared Cognition, APA Books,
      Washington, 1991.

   5. Ducheneaut, N. & Bellotti, V. (2001). Email as Habitat: An Exploration of Embedded
      Personal Information Management. Interactions, 8(5), pp. 30-38.

   6. Moran, T. P. (2003). Activity: Analysis, Design and Management. Symposium on the
      Foundations of Interaction Design, Ivrea, Italy. November 12-13, 2003.

   7. Moran, T. P. (2005). Unified Activity Management: Explicitly Representing Activity in
      Work-Support Systems. ECSCW 2005, Workshop on Activity.

   8. Moran, T. P., Cozzi, A., & Farrell, S. P. (2005) Unified Activity Management:
      Supporting People in eBusiness. Communications of the ACM, December, 2005.

   9. Muller, M., Geyer, W., Brownholtz, B. Wilcox, E., and Millen, D. (2004). One hundred
      days in an activity-centric collaboration environment based on shared objects. CHI 2004.



ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                         11
   10. Unified Activity Management project: www.research.ibm.com/uam.

   11. Tang, J., (1991) Findings from Observational Studies of Collaborative Work,
       International Journal of Man-Machine Studies, 34, 143-160.

   12. Tatar, D., Foster, G., & Bobrow, D. (1991). Design for Conversation: Lessons from
       Cognoter, International Journal of Man-Machine Studies, 34(2), 185-210.

   13. Whittaker, S., Brennan, S., and Clark, H (1991). Co-ordinating activity: an analysis of
       computer supported cooperative work. In Proceedings of CHI'91 Human Factors in
       Computing Systems, New Orleans, USA, Eds., S. Robertson, J. Olson & G. Olson, NY:
       ACM Press, 360-367.

   14. Whittaker, S., Jones, Q., Nardi, B., Creech, M., Terveen, L., Isaacs, E., Hainsworth, J.
       (2004). ContactMap: Organizing Communication in a Social Desktop. ACM Transactions
       on Computer Human Interaction.

   15. Whittaker, S. and Sidner, C. (1996). Email Overload: Exploring Personal Information
       Management of Email. In Proceedings of ACM CHI’96 Conference on Human Factors in
       Computing Systems, 276-283.

   16. Whittaker, S. (2005). Collaborative task management in email. Human Computer
       Interaction, Human-Computer Interaction, 20(1 & 2).




ECSCW 2005 (European Conference on Computer Supported Cooperative Work)
Workshop on Activity: From a Theoretical to a Computational Construct
Paris, September 20, 2005                                                                    12

								
To top