Supporting Collaborative Task Management in Email Steve Whittaker Sheffield University
RUNNING HEAD: SUPPORTING COLLABORATIVE TASK MANAGEMENT Corresponding Author’s Contact Information: Department of Information Studies University of Sheffield 211 Portobello St Sheffield, S1 4DP, UK Tel: +44 114 222 6340 Email:
[email protected] Brief Author’s Biography: Steve Whittaker is a Cognitive Psychologist with interests in the application of cognitive science principles and methods to the design of systems for computer mediated communication, collaborative systems, information retrieval and personal information management. He is Chair of Information Retrieval at the University of Sheffield.
1
ABSTRACT Email is one of the most successful computer applications ever developed. Despite its success, it is now dogged by numerous problems. Users complain about feeling overwhelmed by the volume of messages they receive, they have difficulties too in organizing and managing their email data, but most importantly they have problems in using email to manage collaborative tasks (Bellotti et al., 2003, Balter, 1998, 2000, Mackay, 1988, Whittaker and Sidner, 1996, Whittaker et al., 2002a). These require extended interaction with others for their definition and execution (Bellotti et al., 2003, Venolia et al., 2001, Whittaker and Sidner, 1996). As a result, users are often concurrently working on multiple outstanding tasks as they await responses from others concerning these tasks. This requires users to: (a) create reminders, (b) identify messages that relate to the same task, and (c) combine information from these related messages. Currently people try to use the email inbox to do this, but our data indicate it is ineffective for these purposes. Other recent approaches attempt to tackle Collaborative Task Management, but we show that these offer at best only partial solutions. In contrast, we present two systems, TeleNotes and ContactMap, that directly address Collaborative Task Management. These are motivated by empirical research into paper-based and people-based task management strategies. We describe how our systems implement these different strategies and present evaluation data for each system in use. We contrast the success of these two approaches with earlier work and discuss outstanding design and theory problems arising from our research.
2
CONTENTS Supporting Collaborative Task Management in Email................................................. 1 RUNNING HEAD: Supporting collaborative task management ................................. 1 ABSTRACT.................................................................................................................. 2 1.
INTRODUCTION .............................................................................................. 5
2.
THE PROBLEM OF COLLABORATIVE TASK MANAGEMENT ............... 5 2.1.
Collaborative Task Management: User Strategies and Problems............... 6
2.1.1.
Reminders About Collaborative Tasks ................................................... 7
2.1.2.
Identifying and Accessing Prior Task Context ....................................... 8
2.2.
Problems in Using the Inbox for Collaborative Task Management ........... 8
3. PREVIOUS SOLUTIONS TO THE PROBLEM OF COLLABORATIVE TASK MANAGEMENT .................................................................................................. 10
4.
3.1.
Message Removal ..................................................................................... 10
3.2.
Information structuring ............................................................................. 12
3.3.
Message Highlighting and Labeling ......................................................... 12
3.4.
Workflow Systems.................................................................................... 13
3.5.
Novel Designs to Support Collaborative Task Management.................... 13
TELENOTES: PAPER-BASED TASK MANAGEMENT.............................. 14 4.1.
Studies of Paper-based Task Management Practices................................ 14
4.2.
The TeleNotes System .............................................................................. 15
4.3.
How TeleNotes Supports Collaborative Task Management..................... 17
4.4.
Observations and User Feedback.............................................................. 17
4.4.1. 4.5. 5.
Findings ................................................................................................ 18 Future Redesigns Based on User Feedback .............................................. 19
CONTACTMAP: PEOPLE-BASED TASK MANAGEMENT....................... 19
3
5.1.
The Social Basis of Task Management..................................................... 19
5.2.
The ContactMap System........................................................................... 20
5.3.
How ContactMap Supports Collaborative Task Management ................. 22
5.4.
Evaluating ContactMap ............................................................................ 23
5.4.1.
Method .................................................................................................. 23
5.4.2.
Results................................................................................................... 25
5.5. 6.
Future Redesigns Based on User Feedback .............................................. 26
DESIGN AND THEORY IMPLICATIONS.................................................... 27
Notes ........................................................................................................................... 30 REFERENCES ........................................................................................................... 31 Figure 1 - TeleNotes desktop interface showing multiple piles, a ‘todo’ list and an open message .................................................................................................................... 39 Figure 2 – Opening a pile to access prior task related messages................................ 40 Figure 3 – ContactMap User Interface showing structured social representation...... 41 Figure 4 - Accessing emails exchanged with selected contacts, reminders and email alerts in ContactMap......................................................................................................... 42
4
1. INTRODUCTION Email is one of the most successful computer applications ever developed. According to marketing surveys, over 4 billion corporate email messages were exchanged per day in 2001, increasing to a projected 35 billion in 2005. Moreover, 97% of workers report using email multiple times per week for a daily average of 49 minutes, and 71% of people state that it is “essential” for their everyday work (Gartner 2001, Levitt, 2000, Pitney Bowes, 2000). Despite its success, however, recent research has identified significant problems with email. Users complain about feeling overwhelmed by the volume of messages they receive. They have difficulties, too, in organizing and managing their email data. Most importantly they have problems in using email to execute Collaborative Tasks. This seriously reduces individual and corporate productivity (Bellotti et al., 2003, Bälter, 1998, 2000, Mackay, 1988, Venolia et al., 2001, Whittaker and Sidner, 1996, Whittaker et al., 2002a). This paper describes empirical analyses of user problems with collaborative task management. These analyses then are used to motivate two systems designed to address these problems. Section 2 begins by characterizing Collaborative Task Management. In section 3 we discuss the limitations of previous technical solutions to the problem. Sections 4 and 5 describe and evaluate two novel email designs that are intended to address Collaborative Task Management, motivated by people’s current paper-based and people-based task management strategies. The final section analyzes relevant design and theory implications arising from this work.
2. THE PROBLEM OF COLLABORATIVE TASK MANAGEMENT This section first describes key aspects of collaborative task management and characterizes the three main user tasks that are needed to support it; reminding, identifying prior task information and accessing task information. We review common user strategies for carrying out these tasks, the problems with these strategies. We carried out a series of empirical investigations of email use to identify key user problems (Whittaker and Sidner, 1996, Nardi et al., 2000, Whittaker et al., 2002a). Overall these studies investigated email use by 64 business professionals in 15 different organizations collecting both qualitative and quantitative data. All were experienced email users. We (a) observed people using email to determine message processing strategies, (b) collected samples of email archives determining age, size and number of messages in the inbox and folders, (c) conducted semi-structured interviews about email reading, processing, reply and filing behaviors. Full details are supplied in the original papers; we summarize the main results here. Most people reported problems managing their inboxes. In one study (Whittaker and Sidner, 1996), we found that users had very large inboxes containing an average of 2482 items, which constituted 53% of all messages in their email system. Furthermore, when 5
we analyzed the contents of people’s inboxes we found that these messages were not all new - rather 847 (34%) of messages were more than 3 months old. Similar data are reported elsewhere (Duchenaut and Bellotti, 2001, Fisher and Moody, 2001). Why is the inbox so overloaded? Our interviews and quantitative data indicate that a major reason why the inbox is used in this way because people are using it to carry out Collaborative Task Management (Whittaker and Sidner, 1996, Whittaker et al., 2002a). Many email tasks are collaborative, involving iterative interactions with others in multiple processing sessions. As we shall explain below, messages tend to be left in the inbox over extended periods of time while these tasks are carried out. Similar observations have been made in other studies of email (Bellotti et al., 2003, Mackay, 1988, Venolia et al., 2001, 2003). Collaborative tasks are a major contributor to inbox overload, making collaborative task management a pernicious problem. One way to estimate their prevalence is by determining the percentage of emails that are part of a conversational thread, as threads indicate relations and common underlying activities among messages. Threading estimates range from 52% (Venolia et al., 2001, Bellotti et al., 2003) to 30% (Fisher and Moody, 2001). However, threading is necessarily an approximation of collaboration. People are often casual in the way that they reply to messages: they may fail to reply to an originating message using re: or begin a new task by replying to an earlier message from a relevant user (Erickson and Kellogg, 2001, Herring, 1999). Furthermore, these threading figures are likely to underestimate collaborative tasks. They ignore new collaborative tasks delegated to users who have yet to deal with them, and they do not register when collaborative tasks are forwarded to others. Nevertheless, they show that a substantial proportion of inbox messages involve collaborative tasks.
2.1.
Collaborative Task Management: User Strategies and Problems
Although collaborative tasks by definition involve interactions with others, our focus in this paper is how this affects individual users, specifically the strategies they develop for managing collaborative tasks and the problems they encounter with those strategies. Two critical aspects of managing collaborative tasks relate to (a) delays between messages, and (b) the fact that tasks often require multiple exchanges for their successful execution. Email is by definition an asynchronous medium, and there are often delays between different messages relating to the same collaborative task. Delays occur because email recipients lack the time or the necessary information to be able to respond immediately to address their part of a collaborative task. Collaborative tasks are also iterative, sometimes requiring multiple exchanges between participants before they can be resolved (Bellotti et al., 1993, Venolia et al., 2001, 2003, Whittaker and Sidner, 1996). Iteration may arise because people need to negotiate exactly what a task involves, or because multiple responses need to be synthesized. For example, one of our users, SC, a development manager, describes both these problems. Delays between related messages make it hard for her to remember task status and locating and collating messages for an extended task also poses difficulties. 6
“My main problem [with email] is remembering the status of my conversations. The thing that I kind of I get afraid of, in terms of, did I not reply to someone who is a customer. And you know, how can I keep track of that? … It’s worst when you have multiple people involved, ‘cause then you can’t keep track of who’s replied and who hasn’t. You want to know who all has gotten back to you, but you can’t do that. And that is a huge problem when you need to collate replies for a collective response”.
Delays and iteration give rise to three critical activities in managing collaborative tasks. Users have to leave themselves reminders about outstanding tasks, and to identify and access different elements of the same collaborative task. We now look at how people address these problems, and how they currently carry out these core collaborative task management activities.
2.1.1. Reminders About Collaborative Tasks Delays between task-related messages mean that users have to keep tasks in mind, sometimes for weeks or months. One reminding strategy involves setting up dedicated ‘todo’ folders containing reminders about outstanding tasks (Whittaker and Sidner, 1996, Whittaker et al., 2002a). However, we found that the majority of users (95%) abandoned this strategy, on the grounds that it required an additional cognitive step. Instead of being reminded about tasks as they access new email in their inbox, users have to explicitly remember to open the ‘todo’ folder, and they often forgot to do this. A common strategy when being delegated collaborative tasks is to respond or forward the original message to relevant others, leaving the original message in the inbox as a reminder about that task. This serves to manipulate attention. Users know that they will return to the inbox to access new messages. In the course of doing so they hope that they will see the reminder and recall the outstanding task. Another user, SF, a marketing manager, describes the strategy this way: “I don’t have any other system that keeps track of an email message that awaits a response … usually the next day, hopefully its still sort of near the bottom of the [inbox] … and I will see it when I look at new mail messages, so it won’t get scrolled off the screen.”
In a separate study Venolia et al. (2001) found that leaving a message in the inbox was by far the most frequent reminding strategy. It was much more common than other techniques such as using flags or classifying messages as ‘todo’ items. Although the strategy of leaving messages in the inbox works reasonably well for reminding about tasks that one receives, it is much less effective when delegating tasks to others. Most email programs keep a copy of sent messages, but these are generally stored in a separate ‘sent’ folder, so users do not see these every time they access new email. Having to remember to access the ‘sent’ folder suffers from the same weaknesses as using a ‘todo’ folder, and makes it especially hard to keep track of messages that one is “owed”. DC, a software support manager puts it this way: “well let’s say that someone has asked me something. And I say I don’t know. I will forward it to someone on my staff. Copy that person and say, ‘I need some help with this’. And that’s what, I will keep
7
that sent message as a reminder. But the problem is that I still have to remember to open my sent mail to remind myself that they haven’t replied yet”
Some users attempt to avoid this by copying themselves on every sent message to generate inbox reminders, but this overloads the inbox still further.
2.1.2. Identifying and Accessing Prior Task Context A related problem is that collaborative tasks are not discrete but iterative. As a task evolves, users have to combine task related information in incoming messages with prior relevant information. Prior messages are important because they contain context that is critical for interpreting the current message. This involves identifying previous related messages and accessing information relating to that task. In an ideal case, users should be able to access the complete task history from the current message, if other task participants have been careful to include this. Unfortunately, users cannot guarantee that the history will be present. JL, a corporate VP and chief technology officer talks about it this way: “X is unbelievable in that he never puts the context in which, of what he's replying to. He always comes up with these one line responses, and I have no idea what it is that he's talking about, you know, it's like, "Re: the Internet." ... And, in many cases, he's replying to something that somebody else sent, but I wasn't on the original distribution list, but he thinks that I'd be interested. So I get this totally out-of-context great idea"
And even when complete history is present in the current message, if multiple participants reply to the same message this creates a complex response tree that is often hard to decipher. Message combination therefore often involves scanning the inbox for related prior messages, and then extracting the relevant information. JP, a software architect talks about this: “What I do a lot of the time, is to wait until I have all the information I need about a task. When the replies are in, then I go through the inbox to find them all so I can do the task”.
So far we have identified strategies for collaborative task management in email. But studies of other technologies suggest that these generalize beyond email; collaborative task management is a pervasive problem in other technologies that induces similar user strategies with those technologies. Analyses of voicemail show that people amass messages in their inboxes to serve as reminders of outstanding collaborative tasks, as well as making these messages more available. And people’s habits with paper are similar: they often leave papers in their immediate workspace to serve as reminders about outstanding tasks and to keep these papers more accessible.
2.2.
Problems in Using the Inbox for Collaborative Task Management
However, many users experience severe problems with using the inbox for collaborative task management. Reminding, identifying and accessing prior messages are all highly dependent on visual scanning which becomes less effective as the number of inbox items
8
increases. Most email interfaces present a header list along with message body information for a selected message. Although users differ in how they configure their header list, they tend to operate with 10-20 message headers visible on the screen (Whittaker and Sidner, 1996, Whittaker et al., 2002a). This means, on average, that less than 1% of inbox messages are visible. This lack of visibility compromises reminding, as well as identifying and combining information from related messages. Because most inbox message headers are not constantly in view, users have to actively remember to scroll back to view older messages - making them both less accessible and less effective as reminders. Furthermore, even when users do take the trouble to scroll back several screens, it is still hard to identify specific messages when the inbox contains hundreds of messages. For this reason, older inbox messages are often characterized as being “out of sight and out of mind” (Whittaker and Sidner, 1996). JP, a software developer, characterizes the reminding problem in the following way: “When you’re dodging through all this other stuff its hard to pull out what could potentially be pretty important… like anyone else who may have that volume … after a couple of days you’re not going five screens up anymore. You’re just looking at your current screen and maybe one more. Who knows what you’ve missed.”
And visual scanning of a full inbox is equally problematic as a strategy for detecting relations to identify messages that pertain to a current task. Both the overall number of messages and their heterogeneity make it hard to find relevant messages. JL (the VP and CTO) describes the problem of identifying and accessing messages related to a given task: “That reply with the history of previous stuff… when some people do that and some don’t and the fact that its all interspersed with all kinds of other crap in my email, then I just can’t pick up an email and find out what else it belongs with.”
One alternative to visual scanning is to use threading to detect relations between inbox messages. This strategy is also somewhat unreliable, however, because threads are based on a common message subject line – and we have seen that this can be an inconsistent indicator that messages relate to the same task (Erickson and Kellogg, 2000, Herring, 1999). A minority (25%) of users attempt to reduce these problems by frequently filing messages to reduce overall inbox volume. However our studies and other research (Bälter, 1998, 2000) show that filing is extremely time-intensive to execute, as well as being cognitively difficult and fallible (Whittaker and Sidner, 1996). Furthermore, users who are inundated with large numbers of new messages are unlikely to be able to dedicate time to frequent filing (Bälter, 2000, Whittaker and Sidner, 1996). To summarize our user studies identify the following problems with using the inbox for collaborative task management:
9
1. Visual reminding is compromised when there are too many inbox messages. As the number of inbox items increases, older outstanding items are overlooked when processing new incoming messages. 2. Identifying relevant prior messages is hard when there are large numbers of inbox messages. Related messages are often interspersed with large numbers of different unrelated tasks, making it difficult to detect associations between them. 3. Accessing related messages is difficult when the inbox contains too many messages. Again the presence of large numbers of heterogeneous messages makes it hard to find and extract related information. To overcome these problems, we need to design new systems that provide more direct support for the three key aspects of Collaborative Task Management. Before describing our designs we first review other recent attempts to tackle email problems both to inform our designs and to evaluate how well they support Collaborative Task Management.
3. PREVIOUS SOLUTIONS TO THE COLLABORATIVE TASK MANAGEMENT
PROBLEM
OF
A number of different technical approaches have been proposed to address problems with email. All of them address the overloaded inbox, but take quite distinct approaches to the problem. They focus on message removal, information structuring, message highlighting, and workflow.
3.1.
Message Removal
Advocates of message removal argue that users’ main problem is that they receive too many messages with insufficient time to process these. According to this view, lack of time means that messages are left in the inbox, which then becomes unwieldy as unprocessed messages accumulate. A large volume of incoming messages also means that users don’t have enough time to remove processed messages from the inbox by filing them. Message Removal has the simple aim of reducing the overall number of inbox items, rather than providing direct support for collaborative task management. Specific Message Removal approaches include spam removal, personal filtering and assisted filing. Spam removal: Spam has become a major problem for most email users, with AOL estimating that it blocks 1.4M spam messages each day (AOL, 2003). Many organizations find it necessary to apply filters at the email server to remove suspect content. Spam detection has been relatively successful (if not yet completely accurate) because spam messages often have distinct properties such as large distribution lists, predictable headers and somewhat predictable message content (Cranor and LaMacchia, 1998).
10
Personal filtering: Personal filtering is similar to spam removal except that users define their own rules for message identification and filing. Personal filing has not been successful however. It is not commonly used (Bälter, 1998, Bellotti et al., 2003, Whittaker and Sidner, 1996) despite being introduced over 15 years ago (Malone et al., 1988, Mackay et al., 1989), and being available for several years in commercial products such as Outlook, Eudora, Netscape and NotesMail. One problem is that writing filtering rules is a programming task which most users find both hard and time-consuming. And often the users who are most in need of filters have the least time to dedicate to writing rules. One way to simplify the programming task is to provide predefined general rules (Bälter, 1998, 2000), but it is not clear that this approach has met with widespread success. Another serious problem is that users are often not confident that the rules they define will operate correctly (Pazzani, 2000). In particular, they are concerned that misdefined rules will lead to important messages being filed unseen and hence being overlooked (Whittaker and Sidner, 1996). Finally, such rules may have to be modified frequently to reflect changes in people’s work activities - making rule maintenance an important issue (Whittaker and Sidner, 1996). In sum, while personal filtering may work for very restricted message types with predictable characteristics (e.g. those originating from a specific newsgroup or user), this technique has limited utility for many messages that users receive. Assisted filing: Spam removal and personal filtering address new incoming messages. In contrast, assisted filing aims to reduce inbox clutter by helping users to file processed messages. Filing is a major problem for email users: categorization is a cognitively difficult task (Lansdale, 1988, Malone, 1983, Whittaker and Sidner, 1996) made yet more difficult because folder categories change as the user’s work focus shifts (Kidd, 1994, Whittaker and Sidner, 1996, Whittaker and Hirschberg, 2001). Whittaker and Sidner (1996) found multiple filing problems for email users. First, users are often unable to remember the definitions and names of existing folders, leading them to create new folders that are synonymous with pre-existing ones. Second, folders are often also too small to be useful. Our data showed that on average 35% of folders contain two or fewer items. These small ‘failed folders’ are problematic for 3 reasons: (a) they do not significantly reduce inbox clutter, (b) users have the initial overhead of creating them, and (c) they have to remember multiple folder definitions every time they make a filing decision. Several agent-based systems have been designed to provide assisted filing (Boone, 1998, Cohen, 1996, Mock, 2001, Segal and Kephart, 1999, Takkinnen and Shahmehri, 1998). These systems use machine learning techniques to automatically elicit the defining characteristics of existing folders, based on message header properties and content. These definitions can then be used to classify each inbox message suggesting the folder it best matches. Some of these algorithms have been tested offline on message corpora, showing that they can categorize inbox documents with a reasonable degree of success - reporting over 85% accuracy (Cohen, 1996). Although these results are promising, none of the systems has been tested in real usage contexts, and it may be that (as with the filtering techniques described above) users are unwilling to trust systems to assist in filing their messages.
11
More seriously, assisted filing does not get to the heart of the problem. Assisted filing classifies inbox messages into existing folder categories, whereas a major user filing problem is with defining new folders (Whittaker and Sidner, 1996). Many inbox messages relate to outstanding tasks, and users often only create folders for completed tasks when they need to archive these. This suggests that assisted filing will not address major problems with the inbox because the necessary pre-existing folders do not exist for many outstanding tasks.
3.2.
Information structuring
Information structuring predominantly tackles the problem of detecting relations between inbox messages to identify prior messages relevant to the current task. Unlike the Message Removal approaches described above, Information Structuring recognizes the need to support Collaborative Task Management, in particular that users have considerable difficulty in detecting relations between inbox messages. Almost all work on information structuring proposes novel visualizations for message threads. Such structure is intended to impose order on the undifferentiated inbox; thread detection simplifies the problem of having to deal with large numbers of undifferentiated messages, because it clusters related messages together. A number of different approaches have been taken to visualizing inbox threads (Bellotti et al., 2003, Rohall et al., 2001, Venolia et al., 2001, Venolia and Neustaedter, 2003). These range from combining the components of the thread linearly (Bellotti et al., 2003), to the construction of complex tree structures and subthreads (Venolia and Neustaedter, 2003). Most of these approaches are based on information derived from message subject lines (Rohall et al., 2001, Venolia et al., 2001, Venolia and Neustaedter, 2003). But as we have seen, topic drift means that subject line is only a weak indicator of relations between elements of a specific collaborative task (Erickson and Kellogg, 2001, Herring, 1999). One way to address topic drift is to develop novel algorithms for thread detection that combine information from the message subject line, body, and header information about sender and addressee (Bellotti et al., 2003). While these hybrid approaches are promising, they have not as yet been subjected to detailed evaluation, and it may be that to be effective they have to be tuned to an individual user’s email or to that of the user’s workgroup. Another way to infer structure is to apply clustering techniques (Willett, 1988) to the inbox to suggest new folders. While clustering has been applied elsewhere to document collections and web pages (Voorhees, 1996, Willett, 1988, Zamir et al., 1996), as yet the technique has not been tested on email. Email raises specific challenges because the length and character of messages are very different from the document domain where clustering has generally been applied.
3.3.
Message Highlighting and Labeling
Highlighting/labeling addresses the Collaborative Task Management subproblem of reminding. Messages are highly undifferentiated in the overloaded inbox, and many
12
commercial email interfaces allow users to visually mark various messages to indicate that they require special attention. Furthermore, both Outlook and Netscape allow users to label messages as ‘todos’, with this information appearing in a header field, allowing the user to sort and view ‘todos’ together. Both highlighting and labeling would seem to directly address the reminding problem. In our studies, we found, however, that, with one exception, users make little use of such marking. All our users, on occasion, marked as unread messages that they had actually read, but which required further attention (Whittaker and Sidner, 1996, Whittaker et al., 2002a). This was to ensure that they attended to these messages next time they accessed their inbox to access genuinely unread messages. It was uncommon to see sustained or effective use of more subtle forms of marking such as highlighting messages to signal urgency or status for self or others. And where such highlighting was used by others it was often overlooked or ignored; users receiving messages marked ‘highest priority’ were often unaware that message were marked in this way (Whittaker et al., 2002a). Independent work by Venolia et al., (2001) confirms this: marking outstanding messages as unread was judged to be much more effective for reminding than using dedicated ‘todo’ flags or other types of visual coding. Some recent systems (e.g. Bellotti et al., 2003) have implemented novel forms of marking schemes but as yet these have not been systematically tested with users.
3.4.
Workflow Systems
Workflow systems assume that collaborative organizational tasks have a predictable structure associated with different work roles (Prinz, 1993, Winograd, 1994). For example a purchase order may have to be initiated, approved by a manager and then processed by the purchasing department. In principle workflow systems address collaborative task management; they often support reminding as well as straightforward access and collation of related message. In practice, however, they have two major limitations: coverage and lack of integration. The coverage problem arises because many collaborative email tasks lack the predictability needed for the workflow approach to succeed. Workflow is effective for tasks that have predictable structure, but as we have seen, most collaborative tasks have an evolving structure and require iterative negotiation for their solution. This makes them inappropriate for workflow tools (Bowers et al., 1995, Dourish et al., 1996, Suchman, 1994). And even when tasks are amenable to workflow, there are integration issues. With a few notable exceptions (Borenstein, 1992, Borenstein and Thyberg, 1988), most workflow systems are not well integrated with email clients, so that users have to switch to a separate application - introducing extra cognitive overhead.
3.5.
Novel Designs to Support Collaborative Task Management
With some notable exceptions (Bellotti et al., 2003, Kaptelinin, 2003, Rohall et al., 2001, Venolia et al., 2001, 2003), most of the above approaches do not directly tackle collaborative task management. Because of the limitations of these prior approaches, we
13
employed a different strategy. In what follows, we attempt to break away from the prevailing model to explore radical new representations of email. In particular we wanted to find ways to more directly support the important subtasks of reminding, identifying and accessing prior relevant information. Our designs are motivated both by previous research and empirical observations of how users currently manage Collaborative Tasks. By basing our new designs on users’ current practices, we hope to exploit their existing strategies and knowledge. The design for our first system, TeleNotes, is based around people’s current desktop oriented, document-based practices – we call this our paper-based design. The second design is derived from observations of people’s informal communication behaviors in their social environment, which we call our people-based design. One repeated observation about email is that is used for multiple tasks (Duchenaut and Bellotti, 2001, Mackay, 1988, Venolia et al., 2001, Whittaker and Sidner, 1996). This wide range of email tasks makes it especially hard to build research prototypes that support all aspects of email usage. We are aware that there are other important email tasks such as filing (Whittaker and Sidner, 1996, Bolter, 1998, 2000); prioritization (Horvitz et al., 1999; Horvitz et al., 2002; Venolia et al., 2001); and archive management (Whittaker and Sidner, 1996) that are not directly addressed here. In what follows, we will take care to explore whether enhanced support for collaborative task management compromises these other aspects of email usage. Another important design issue concerns the fact that collaborative tasks are distributed across different applications. For example, users may respond to an email request with a voicemail if they feel the situation is urgent, requiring users to integrate both technologies for prior context (Whittaker et al., 1998). While it is possible to design technologies to combine task management across email and voicemail in a unified messaging system (Whittaker and Amento, 2003, Whittaker et al., 2002b), we will not deal with this here. In this paper we restrict our focus to email-centric task management.
4. TELENOTES: PAPER-BASED TASK MANAGEMENT 4.1.
Studies of Paper-based Task Management Practices
A great deal of research has looked at how people manage individual and collaborative tasks using paper (Bellotti et al., 2004, Blandford and Green, 2001, Kidd, 1994, Malone, 1983). It shows that people use a wide variety of task management techniques that range from the highly formal (e.g. day planners), to the highly informal (e.g. scraps of paper, sticky notes, document piles). One important limitation of more formal techniques is that they require transposition of information from one medium to another, e.g. accessing a task from voicemail, and logging it in one’s day planner. Because of this, there is a tendency for people not to combine information into a centralized master list, and people tend to leave information in the original delivery medium - whether this is email, voicemail or paper (Blandford and Green, 2001).
14
In contrast, there have been relatively few studies of electronic support for personal task management. Here, research suggests that centralized electronic ‘todo’ lists are experimented with, but often abandoned because (a) they require transposition of information from another medium; (b) they fail to support flexible methods to mark the status of different items; (c) they are inadequate for reminding (Blandford and Green, 2001). Because of the failure of these more formal ‘centralized’ systems, we mainly focused on informal paper-based methods for managing tasks. One highly salient feature of paper-based task management is the use of spatial cues, in particular, document piling and pile placement. Piles consist of sets of associated documents, which are often related to tasks, with documents relating to a particular task being stored together. Spatial placement of the entire pile can also be a critical reminding cue. People manipulate pile location, so that piles that must be dealt with immediately are placed in locations where they are guaranteed to be seen, e.g. on one’s chair or computer keyboard. Piles relating to less pressing tasks tend to get pushed away from the central workspace, reducing their visibility and hence their ability to remind. Piles also make task information readily accessible and users are able to rapidly access relevant information (Lansdale, 1988, Malone, 1983, Sellen and Harper, 2002, Whittaker and Hirschberg, 2001). Furthermore, workspace piles usually relate to outstanding tasks. As with email, once tasks are completed then the contents of the relevant pile are filed away for archival purposes. Desktop paper piles support Collaborative Task Management in the following ways: 1.
Reminding. By seeing the pile, the user should be reminded about the need to undertake some action related to its associated task. Implicit reminding based on piles and their locations is also supplemented with paper-based ‘todo’ lists that are explicit reminders of outstanding tasks.
2.
Identifying Prior Relevant Information. Piles are usually semantically organized, with information related to a particular task being stored in a single pile or sometimes across spatially adjacent piles. So both pile identity and spatial location are important cues allowing users to identify prior relevant information.
3.
Accessing Prior Relevant Information. Piles are deliberately left on the user’s desktop rather than being archived in a filing cabinet. This makes their contents more accessible, and readily at hand, allowing users to rapidly access information from relevant piles.
4.2.
The TeleNotes System
The TeleNotes system was intended to mimic this use of paper piles and their spatial organization for Collaborative Task Management. The User Interface is shown in Figure 1. The initial system was not intended to replicate all aspects of email functionality, in particular we did not provide direct support for archiving and search in our initial versions. The system was iteratively developed over 9 months incorporating user 15
feedback at each development phase. Here we present the results of the final design. A fuller description of TeleNotes’ additional features supporting informal communication is provided in Whittaker et al. (1997). Here we describe only those functions relevant to Collaborative Task Management. Figure 1 about here •
Messages are represented as document icons resembling sticky notes. Each document has a visible title based on the sender and the first few characters of the message (e.g. ‘jerry 03/23’, ‘steve phone’). Each document can contain attachments or HTML links. These are represented on the user’s regular computer desktop.
•
Messages are threaded and messages from the same thread are automatically stored at the same spatial location in piles. Messages that are responses to prior messages are initially allocated to the same pile as that prior message, but users can also manually modify the contents of existing piles using drag and drop operations to add or remove documents to, or from, existing piles. Figure 1 shows two piles involving communication with Jerry, one with Irene, and one with Candy.
•
Each pile can be given a label by the user, or alternatively the system uses the initial part of the message to allocate a label automatically. Figure 1 shows labels in white underneath the pile (e.g. for the Candy pile the label is ‘can you send me a sticky?’).
•
Clicking on a pile opens the stack of messages constituting the pile to provide access to the prior task history (Figure 2 shows an opened pile).
•
Documents and piles can be placed manually anywhere on the user’s computer desktop using drag and drop. New piles are positioned automatically.
•
Users can also create ‘todo’ lists (represented as blue icons). In Figure 1 the ‘todo’ list is entitled ‘and spreadsheet for plan’.
•
The system is implemented in Lotus Notes. It is integrated with NotesMail and messages can either be viewed (a) on the desktop (as shown in Figs 1 and 2) as documents and piles, or (b) in a traditional email user interface. Access to NotesMail is needed to support long-term archival and search behaviors.
•
The Notes architecture also makes it possible to replicate tasks across multiple systems, allowing users to update and synchronize their tasks across multiple machines, for example if they shift from a desktop to a laptop machine.
Figure 2 about here
16
4.3.
How TeleNotes Supports Collaborative Task Management
TeleNotes supports collaborative task management by mimicking people’s current use of physical desktop piles and spatial location in the following ways: •
Reminding. Documents and piles are spatially arranged on the computer desktop. These will be seen as users execute their everyday activities providing opportunistic reminding about outstanding tasks relating to those piles. This implicit reminding can also be supplemented with explicit reminders i.e. ‘todo’ lists.
•
Identifying Prior Relevant Information. Piles signal relationships between messages allowing users to identify prior relevant information. The system automatically sorts messages into piles according to conversational threads to indicate these relations. But because of known problems of topic drift, we also allow users to manually manipulate piles using drag and drop operations, supplementing automatic threading with manual organization. The fact that information is organized into task-specific piles also helps to reduce overall clutter and should help users keep key tasks in mind.
•
Accessing Prior Relevant Information. Piles are available on the computer desktop - which makes them and their associated information (such as attachments) more accessible than if that information was archived. Accessing prior task relevant messages is straightforward. Users can open the entire task history by clicking on the relevant pile.
These features contrast with current email UIs in which the overloaded inbox (a) fails to make task reminders salient; (b) makes it hard to find and access prior information relating to an outstanding task.
4.4.
Observations and User Feedback
The final version of the prototype was deployed and used by eight people in the course of their everyday work over a period of two months. The users consisted of 2 researchers, 2 administrative assistants, 2 managers, and 2 software engineers from a software development company. Feedback and usage patterns were gathered by semistructured interviews, comments elicited by email, and analysis of behavioral logs. Telenotes was used in combination with the user’s existing emailer NotesMail, but integration with NotesMail meant that messages could be viewed in either interface. We chose this combination approach, as preliminary interviews indicated that users were unwilling to shift to using TeleNotes for all their email processing as it lacked important features such as archiving and search, which had to be carried out in NotesMail. All TeleNotes messages appeared on the user’s computer desktop, along with the user’s regular desktop items.
17
4.4.1. Findings TeleNotes’ functionality was apparent to users who readily understood the relationship between the UI objects and their paper equivalents. The UI presented few difficulties, and all users were able to use it after a demonstration lasting only a few minutes. All users exploited the spatial aspects of piles in TeleNotes to engage in task management. They placed different tasks at different desktop locations to manage different ongoing communications, with a median of four different task piles at any one time. In addition, TeleNotes was used for personal reminding, with all users using it for sending "messages to themselves", e.g. "remember to confirm flight", relying on the visibility of messages to guarantee they saw the message. These reminders were highly brief, consisting of a few words only (mean 3.8 words). One unanticipated usage was to display large untransmitted messages on one's own machine to communicate information to others. One user left a message on her computer desktop saying "I'm out of the office today, contact phone, 123 4567", so that others could see it when they came into her office. The advantage she stated was that she could create this message from offsite, and still have it displayed in her office, where people would expect to find her. The system was also effective in allowing users to identify and access prior task context. All users were extremely positive about the ability to click on a pile to open sets of related messages to see and access task context. One situation in which this was reported to be particularly useful was for the collaborative exchange of multiple versions of an evolving document or spreadsheet. By clicking on the relevant task pile users could open a sequenced history of different versions of the file, with each message containing relevant attached comments for that version. One user commented: “it’s great. All the messages are there with the documents attached. It’s like (Lotus) 123 versioning, except that you can see everyone’s comments with the version they edited.”
Although all users exploited TeleNotes to manage some tasks, they did not abandon other methods of Collaborative Task Management; and they continued to manage some tasks in NotesMail. However, it seemed that people used TeleNotes to highlight important tasks. According to one user: “it’s good for pulling out tasks I want to be sure to remember, but I don’t want to use it for everything.”
We probed why users persisted in using NotesMail. One reason for not using TeleNotes (mentioned by 3 users) was that some messages concerned tasks that had been initiated prior to the installation of the system. Another reason was concerns about screen real estate (again mentioned by 3 users). Piles are deliberately designed to remain constantly visible on the user's desktop, as reminders about outstanding communication tasks. A difficulty, however, is that piles also consume space: constructing multiple piles reduces the space for viewing other desktop applications that the user is actively working on.
18
Although in most cases, people stated that the piles metaphor was obvious, on occasion the automatic threading mechanism was confusing, especially when there were multiple ongoing tasks involving the same person. Although we provided users with the ability to specify their own task labels to differentiate different threads, users sometimes inadvertently gave tasks similar labels – a problem we had observed with email folders. Two other users observed that when tasks became complex they wished to generate subtasks, which are not represented in the current design.
4.5.
Future Redesigns Based on User Feedback
We designed (and in some cases implemented) modifications to TeleNotes based on this field trial feedback. Reminding. Users commented that desktop piles can consume desktop screen real estate which may interfere with the use of other applications. We therefore implemented two modified versions of the prototype. We provided ways: (a) to reduce the number of piles visible on the desktop, and (b) to view piles as overlays to existing applications. To reduce the number of visible piles we allowed users to "save" piles into an email database, thus removing them from the desktop. We also provided users with two presentation modes of running TeleNotes, in which piles either "floated" on top of the current application, or below it. Putting messages in databases, or having them submerged beneath applications reduces their visibility - which may compromise reminding and accessibility. We therefore made both these features user configurable, allowing users to make their own decisions about how they wanted to represent their outstanding tasks. Follow-up interviews and observations of people using these versions indicated that 6 out of 8 users preferred to have TeleNotes tasks visible on the desktop or ‘floating’ over other applications rather than in databases. Prior Message Access. Two users had commented that piles were sometimes confusable and that they failed to represent complex task substructure. Possible refinements here would be to separately color code all piles making them more distinct, and to represent information about subthreads by capturing and displaying this automatically. Subthreads might for example be shown as smaller icons attached to a standard sized pile. Other possible ways to make tasks more distinct may be visually encode differences such as the age of the oldest message, the number of participants and number of messages/task. We might also allow users to resize messages and piles manually in order to represent importance.
5. CONTACTMAP: PEOPLE-BASED TASK MANAGEMENT 5.1.
The Social Basis of Task Management
Our second novel email system was based around people-centric task management. It was motivated by observations that social information is an important resource for our 3 critical Collaborative Task Management activities. Much recent research has shown how
19
workers use collocated colleagues to remind themselves about outstanding tasks, and as repositories of information about their current collaborative tasks. Reminding. Users frequently describe their task-related interactions as a series of social commitments, to others, that is, work they owe, or are owed (Nardi et al., 2000, Whittaker and Sidner, 1996, Whittaker et al., 2002a, Whittaker et al., in press). A shared social environment provides direct support for remembering and discharging such commitments. As people move around their workplace, casual encounters and meetings with others remind them about conversations they intended to engage in, helping them remember outstanding tasks they may otherwise have forgotten (Bly et al., 1991, Isaacs et al., 1997, Kraut et al., 1990a, 1990b, Whittaker et al., 1994). In this way, seeing other colleagues reminds people about outstanding tasks. Accessing Task Related Information. Another important element of a shared social environment is that it functions as a structured social interface for accessing information relevant to work related tasks. Shared social environments are usually configured to reflect both team affiliations and social relationships, and members of a project group working on common tasks are often collocated (Hinds and Kiesler, 2002, Kraut et al., 1990a). These collocated colleagues are often an important source of task-related information (Allen, 1997, Ackerman and McDonald, 1996, Granovetter, 1973, McDonald and Ackerman, 1998, Resnick and Varian, 1997, Wellman, 2001). Identifying Relevant Task Information. People exploit this social structure when attempting to access and organize task relevant information stored online. One common way users access online task information is to use project or ad hoc social groupings (Whittaker et al., 2002a, Nardi et al., 2000). They may first attempt to remember which set of people are involved in a given project task, then use these social relations to determine which online conversations are relevant to that task (‘I know that Julia, Mary and Phil were all involved in the new equipment purchase, so let me access the messages that they exchanged’).
5.2.
The ContactMap System
The ContactMap system is shown in Figure 3. The final design we describe was the result of four phases of iterative prototyping, involving high and low fidelity paper and software prototyping, over a period of 18 months. At each stage we collected and incorporated feedback from representative users. Our key goal is to support collaborative task management, making it natural to center the UI on a social representation of the user’s important colleagues. Similar observations have been made by Fisher and Dourish (2004), Farnham et al., (2002), and McDonald (2003), who have all built systems based around social representations, and explored how this information might be useful for various activities, such as locating expertise. ContactMap is based on the insight that there is a close mapping between people and tasks; not only do encounters with colleagues provide important reminders about outstanding tasks, but social information facilitates structured access to information about those tasks, because certain people are highly associated with particular tasks. 20
Figure 3 about here ContactMap therefore has the following characteristics (Whittaker et al., in press): • •
•
•
•
•
•
ContactMap is based around a social representation of the important people in the user’s life. We call these people “contacts”. Contacts are represented by photos, icons or labels. The social representation is structured: contacts are organized by the user, and relations are signaled by space or color. The structure shows social groupings and relations between contacts that are important to the user. For example many users organize contacts into work-related project groups, organizational affiliations or friends. Figure 3 shows three project groups (top of Figure 3), an organizational group (left) and loose associations of colleagues and friends (center and right). All personal images are blurred in the figure to preserve anonymity. Contacts can simultaneously be members of multiple groups. This is achieved either (a) by having one icon to represent an individual and signaling multigroup membership by striping (to show the multiple colors of the relevant groups), or (b) by allowing users to create multiple copies (‘clones’) of the icon and place these in the relevant groups. ContactMap also provides socially structured access to email (and other) data. Users can click on a given contact and access emails associated with that contact. They can also send messages to individual contacts or groups by accessing relevant contacts. And they can access all emails exchanged by people in a specific group by clicking on the group’s icon. Figure 4 shows how email information is accessed for the IM group. ContactMap is based around people rather than message header information. Unlike most email systems, it does not distinguish between sent and received emails, so that clicking on a contact will access all messages involving that contact regardless of who originated them. ContactMap provides explicit reminders to indicate that there is an outstanding task associated with a particular contact. Reminders are signaled by the presence of a blue dot on the contact, and specific notes can be associated with the reminder. These notes are revealed when the contact icon is moused over (See Figure 4). ContactMap supports alerting about new tasks, allowing users to determine when they receive new email from specified contacts. The presence of email from a specific contact is indicated by an envelope icon attached to that contact (See Figure 4). Alerting is user configurable and can be applied to individual contacts or groups, so that users can, if they wish, be informed when email arrives from anyone in, for example, the IM group. ContactMap provides tools to help the user identify and organize contacts. Early user feedback indicated that users found it onerous to set up their own social representation. Specifically, we provide tools to help users extract and organize important contacts from sources such as email.
Figure 4 about here 21
5.3.
How ContactMap Supports Collaborative Task Management
ContactMap supports collaborative task management in the following ways by mimicking important properties of the user’s social environment: Reminding. Users regard task-related communications as social commitments that they owe or are owed. ContactMap supports such social reminding in three ways. Reminders and alerts are two explicit ways by which the interface indicates to the user that they have such a commitment. Normal use of the map also leads to implicit reminding. As they use the map for accessing and initiating communications, users traverse different areas to find particular contacts or groups. In doing so, they should opportunistically notice other contacts not directly related to their current task, but who are often spatially (and hence conceptually) close to the accessed contact. Noticing these contacts may remind them about outstanding commitments associated with these contacts. This opportunistic prompting is designed to serve the same reminding function as bumping into people in a shared physical environment (Bly et al., 1991, Kraut et al., 1990b, Whittaker et al., 1994). Accessibility. ContactMap provides ready access to task related information by exploiting task-related social cues. When users need to discharge a task related to a particular contact, they can click on that contact and directly access emails associated with that person. And when the task involves groups of colleagues, ContactMap’s structure makes it straightforward to access group communications relating to the task. Identifying Relevant Task Information. ContactMap provides a structured social representation which can be used to detect and access relations between messages. Our interviewees noted they often needed to access a flow of messages within a project or across formal project lines. ContactMap’s social structure provides ways to determine such relations between messages. The map makes it easy to scan for both user defined and ad hoc groups of people, select them, and access all messages they sent or received. There are several important differences between ContactMap and standard email systems. Unlike ContactMap, email does not distinguish between messages from important and unimportant people, although certain email programs such as InformationLens (Malone et al., 1986) can be programmed to do this. Email also doesn’t allow people to use social information directly for task management and information access. ContactMap’s social organization contrasts with email’s overloaded inbox, because it (a) reminds about communication commitments; (b) exploits structured social information to allow people to find and access information relating to outstanding tasks. ContactMap’s social representation also contrasts with email utilities such as group address lists or aliases which are linear and cannot be used for accessing or initiating conversations. ContactMap’s representation is closer in spirit to the IM buddy list which supports social reminding as well as providing a way to initiate communication (Nardi et al., 2000b). However, the buddy list does not show complex social relations, nor can it be used for accessing prior conversations. A number of other recent systems have developed similar techniques for the social visualization of persistent conversations, although none
22
of these has tackled email (Donath et al., 1999, Erickson and Kellogg, 2000, Smith and Fiore, 2001, Viegas and Donath, 2000).
5.4.
Evaluating ContactMap
Our laboratory study compared ContactMap with people’s regular emailer to determine how well each system supported collaborative task management. This was a challenging test for ContactMap, as our users had a great deal of daily experience with using email for collaborative task management. Fifteen users participated in the experiment. Twelve used Netscape Communicator and 3 used Microsoft Outlook as their regular email program. They were researchers, managers, secretaries and marketing staff from a large industrial research laboratory. The experiment consisted of 3 phases: (a) map construction (where users ran an email analysis program that helped them select important contacts and organize them on the map), (b) task execution with task specific UI comparisons, and (c) general UI comparisons. There are some limitations to this type of study. It looks only at Collaborative Task Management, and is not intended to compare ContactMap and email for all tasks that email is currently used for, such as responding to, or composing messages. This type of study also cannot investigate long-terms aspects of usage. We used follow-up interviews to probe these other issues. One might also argue that map construction with ContactMap gave users practice with the map just prior to testing, and that they did not receive similar experience with email. This argument is false, however. Firstly, one might contend that our experimental comparison is unfairly prejudiced against ContactMap because users have an average of 3.2 years of constructive practice using their email systems for task management. Secondly, our design goal was that ContactMap would be used on a daily basis as a ‘social desktop’ being repeatedly accessed each day for many communication tasks. We should therefore expect people to be highly familiar with its layout (a situation promoted by the experimental set-up), just as they are highly familiar with the structure and functionality of their current email systems.
5.4.1. Method Users took about 45 minutes on average setting up their map. We logged the spatial layout and the structure of all contacts and groups on the map. The next two phases of the experiment took place a day later. Users first carried out five brief practice tasks to familiarize themselves with ContactMap functionality and the experimental procedure. Although all participants were experienced email users, we confirmed they were familiar with features that might be helpful for experimental tasks, by asking them to carry out similar practice tasks with their emailer.
23
They then carried out 2 experimental tasks1. The tasks were intended to test key aspects of collaborative task management, namely reminding and accessing information about current tasks. It is hard to directly test reminding in a lab setting, because the very act of asking about a task serves to remind the user about that task. We therefore chose to probe reminding in a more indirect way, by seeing how readily users had access to their current outstanding tasks. We called this keeping tasks in mind. •
Keeping Tasks in Mind. Users had to identify all their outstanding communication tasks and send a message to all relevant individuals to cancel these: “You have become ill and have to go into quarantine for the next couple of days, send an email message to relevant people canceling all relevant meetings and social engagements”.
In the second task we asked users to access information that was relevant to one of their current projects. We called this accessing task information. During map construction we had asked users to generate a list of their current projects, and we chose one of these at random. •
Accessing Task Information. Users had to access messages associated with a particular activity: “You are trying to track the status of activity X: find recent 5 messages sent and 5 messages received about that activity”.
There were 2 instances of each task type and all tasks were done in both ContactMap and the user’s regular emailer, to control for variability in users’ email archives and contacts. The order was randomized: half the users carried out a given task first with their emailer, and half started with ContactMap. Users were allowed a maximum of 2 minutes for each task. We logged key strokes, time to solution. We also measured task success by having users either send an email to a relevant set of people (keeping tasks in mind) or identify a set of messages (accessing task information). After each task, users made task specific UI comparisons. We asked them to express a preference for either ContactMap or their emailer for that task, giving a reason for their choice. After finishing all tasks, users answered questions comparing the suitability of ContactMap and their emailer for honoring communication commitments, keeping tasks in mind and following up on email. We conducted follow up interviews with six ContactMap users to obtain general reactions to the interface and suggestions for design improvements. These people used ContactMap to access their email for 3 days after the experiment. We also recorded spontaneous comments relating to interface design made during the experiment.
1
Our original experiment involved other tasks that are not directly relevant to Collaborative Task Management. These were about keeping in touch and social recommendation and will not be discussed here. 24
5.4.2. Results The spatial layout of contacts and their specific organization was important, and related to reminding and access. 9 users said they placed frequently needed important contacts and clusters at the top of the map, with less frequently accessed contacts and clusters below them. 7 users described placing “current projects” near the top of their maps and more archival information lower down. 8 users organized their social desktop into three main categories of work projects, work associates and personal groupings such as friends and family, with 13 having at least two of these three categories. Time and Success Measures For each task, we measured performance using (a) efficiency (time to complete the task), and (b) task success. We hypothesized that a better interface would let users: (a) find more task relevant messages; (b) find these more quickly. We compared performance statistically using two separate analyses of variance (ANOVA) where the independent measures were Interface Type (ContactMap, emailer), Task (keeping tasks in mind, accessing task information), Order (whether users carried out the task first using ContactMap and then their emailer or vice versa). The dependent measures in the two analyses were success or time. As we predicted, for the success measure, people performed better overall using ContactMap than with their normal emailer (F(1,112)=23.52, p0.10). There were also no order effects: users performed no better the second time they carried out a particular task (F(1,112)=0.1, p>0.10). The results were similar for the time measure. People performed tasks more quickly with ContactMap than their normal emailer (F(1,112)=11.07, p0.10). There were no order effects (F(1,112)=1.95, p>0.10). In a separate analysis we looked at whether there were differences between the emailers that people used. There were no differences between Netscape and Outlook emailers for either success (F(1,119)=1.5, p>0.10), or time (F(1,119)=0.2, p>0.10). Interface Preferences We now turn to users’ judgments about which interface was best for each task. They made a single comparison with scores ranging from -2 (strongly preferred emailer) to +2 (strongly preferred ContactMap). Both task types had overall positive preference scores favoring ContactMap: the respective means were 1.0 for keeping tasks in mind and 0.8 for accessing task information. On both tasks, users were significantly more likely to rate ContactMap as more suitable for both keeping tasks in mind (t(29) = 7.1, p < 0.001) and for accessing task information (t(29) = 3.0, p < 0.01). Results were less clearcut for general UI comparisons that users made at the end of the experiment. ContactMap was preferred for only 1 of these 3 questions: keeping tasks in mind (mean difference is 1.4, t(14) = 8.57, p < 0.0001). However, ContactMap was rated 25
as equivalent to their emailer for following up email (mean difference is 0.13, t(14) = 0.49, p > 0.10) and for honoring communication commitments (mean difference is 0.33, t(14) = 1.05, p > 0.10). We analyzed the comments users made after each task to explain their preference. The comments suggested how ContactMap supported social reminding as well as providing structured access to social information, contrasting this with email. As expected, ContactMap was effective for social reminding. Important contacts are constantly visible, which meant there was no need to remember their identity: “with ContactMap I could see all of my contacts at once and select them quickly. With Outlook, I had to scroll through the contact list to make sure I wasn't missing anyone. In the end I missed one person.” Even though important names and aliases were usually in the users’ email archives or address books, users considered it laborious to access data from those sources, instead they often tried to remember contacts. “ContactMap reminds me of who my friends are – in Netscape I have to remember myself.” Remembering is known to be less accurate than recognition (Baddeley, 1999). ContactMap also provided structural information that directed visual scanning when locating contacts: “ContactMap helped me to find the relevant people easily - I just looked in the relevant clusters to find them. I also got ideas by just scanning rather than searching for individual people.” As we had intended, ContactMap also supported associative reminding. Seeing one relevant contact seemed to suggest another: “it’s easy to see a quick overview of relevant people. They're across many different groups but it’s easy to pick them out spatially. Seeing a name often generates ideas of other people to pick, and finding them is easy.” The same structure was useful when trying to access archival information. In email, scanning was hard: relevant contacts were often spread across multiple folders, making it difficult to scan a large set of contacts quickly. And email folders do not allow using groups of contacts as retrieval cues, i.e. there was no way to view sets of messages involving defined groups of contacts. To summarize, there were no tasks for which users’ current emailer was preferred or better than ContactMap. The general superiority of ContactMap for collaborative task management for both objective and subjective measures was striking, bearing in mind that people had very brief exposure to ContactMap and lengthy experience with their emailer.
5.5.
Future Redesigns Based on User Feedback
Overall, users were positive about ContactMap. Here we report user data that have a significant impact for system redesign. One set of users’ comments addressed map complexity. Three out of six users we interviewed were concerned that having too many contacts or groups on the map could be distracting or might lead to difficulties in using and maintaining the interface. Such concerns may not turn out to be a major problem, however. We collected objective data which showed that user task performance was independent of the number of contacts or groups on the map. And visualization techniques could also be used to reduce the visual complexity of the map. For example, 26
hyperbolic methods could allow peripheral contacts to be constantly visible but shown smaller than core contacts (Furnas and Bederson, 1995). A related concern (mentioned by two interviewees) was the scalability of the interface as one’s set of contacts grows over time. But other studies of contact management suggest that one’s total number of contacts remains fairly constant with older inactive contacts being replaced by newer ones (Dunbar, 1998, Whittaker et al., 2002c), making scalability less of an issue than our users thought. Three interviewees also commented about map maintenance, pointing out the need to continually update their contacts. Consistent with our design, however, ContactMap was seen as a visual workspace; people felt that using it as a backdrop for work would implicitly prompt them to add new contacts as these become relevant. They also suggested that the application might be effective in a screensaver. And we might also supplement this implicit prompting with automatic methods for adding contacts. Future versions of the system might analyze recent email behavior prompting users to add potentially important new contacts based on the user’s prior contact selection behavior (Whittaker et al., 2002c). And that other study indicates too that maintenance may not be a major stumbling block, as all users find the process of constructing and updating contacts to be interesting and enjoyable, giving them insight into their communication behavior (Whittaker et al., 2002c). While all 6 interviewees were generally positive about ContactMap and its support for people-centric collaborative task tracking, they also indicated the continued importance of message-centric information. They noted that people-centric and messagecentric perspectives are complementary, supporting different types of communication tasks. The following comments point to these trade-offs: “Seeing contacts in really useful for doing things related to projects or tasks, but if I want to see recent messages or just quickly respond to a message, then Netscape is better.” “It’s great to see messages related to people, but I still need the time-based inbox view to give me an overall sense of what’s happened in the last hour or two.”
The ideal interface might allow users to switch between message-centric and peoplecentric views.
6. DESIGN AND THEORY IMPLICATIONS To summarize, current email systems fail to support Collaborative Task Management. We have discussed the limitations of other research that proposes solutions to this problem, and presented two novel systems that break away from existing approaches to email. TeleNotes and ContactMap are motivated by current paper- and people-based practices for Collaborative Task Management. Our evaluation studies show that our systems directly support key aspects of Collaborative Task Management, namely reminding, as well as identifying and accessing task relevant information. The research also suggests some outstanding design and theoretical issues. We first discuss design implications.
27
Centralized versus Distributed Task Management. People carry out much of their Collaborative Task Management in email (Bellotti et al., 2004, Duchenaut and Bellotti, 2001), but collaborative tasks are processed in other applications too, such as voicemail (Whittaker et al., 1998, 2002b), Instant Messaging (Nardi et al., 2000b), Lotus Notes (Whittaker, 1996) and Usenet discussion groups (Whittaker et al., 1998). Users also combine different applications (e.g. voicemail and email) in carrying out a single collaborative task (Whittaker et al., 1998). One design possibility would be to centralize all task management into a single user interface (e.g. Kaptelinin, 2003). Having to pay attention to a single task ‘todo’ list should mean that users are less likely to overlook important tasks. However such a centralized system requires careful design to ensure that integration is effective, and users may still be left with the additional overhead of transferring tasks into the task manager. Whittaker et al. (2002b) and Whittaker and Amento (2003) built systems that automatically integrated voicemail and email into a single mailbox. Despite the success of these unified systems, users did not want to completely abandon the separate underlying systems, leading to complex issues concerning the maintenance of consistent views across the two applications. Another possibility is to promote email as the primary application providing integration with other desktop applications to support it (Bellotti et al., 2003) or to combine communication applications to support ad hoc tasks as the need arises (Geyer et al., 2003). In both cases, however, such integration, needs to preserve the ability to exploit component applications. A related issue concerns the need to replicate task management across multiple machines, for example when people use multiple desktop machines and laptops, but still need to have consistent access to critical tasks. Here there are distinct advantages to taking a centralized approach. Radical Discontinuity versus Evolution. Both TeleNotes and ContactMap are radically different from most current email systems, although we have strong evidence that they supported key Collaborative Task Management activities. Nevertheless, our users did not completely abandon their regular emailer. One reason for this was that neither of our prototypes was fully featured, so that users had to revert to their regular emailer when they needed features that were missing from our systems (Duchenaut and Bellotti, 2001). Users may also have found it hard to abandon work practices they had developed in using their regular emailer over many years. They also had important data such as archives or addresses in their legacy system. This inertia with respect to new applications suggests that future email designs should overlay novel functions and interfaces onto existing systems. Specifically, we might want to implement ‘piles’ or ‘social representation’ as a view onto the underlying email data within the current system. Consistent with this, ContactMap users argued that there were certain contexts in which they wanted a social based task management and other occasions where a messagecentric management was appropriate. By implementing novel interfaces as views, we allow experimentation, while still providing a fully functional underlying system. Alternative Methods for Detecting Task Relations. A critical aspect of collaborative task management is recognizing relations between messages that belong to the same task. TeleNotes and ContactMap use different methods for inferring tasks. In TeleNotes tasks (i.e. piles) are a combination of automatic threads and manual user intervention, and in
28
ContactMap we assume a relationship between people and tasks. Other systems use a combination of these methods (Bellotti et al., 2003). We need to explore different methods for inferring tasks. One promising possibility is to use machine learning clustering techniques. We might expect that a combination of features derived from message headers (e.g. thread ID, author and cc fields) along with message content, would be important indicators of task. Again however these algorithms would have to be based on data collected from real users specifying how they define their tasks, and careful design work is needed to present this data effectively in the inbox. In particular, care has to be taken to avoid users’ lack of trust in automatic methods for classifying messages (Whittaker and Sidner, 1996). One promising approach we have employed elsewhere is to initially present automatic message classifications as hypotheses, which the user can confirm or disconfirm. Once users become confident the system is operating in the way they want they can cancel the need for confirmation (Whittaker et al., 2002b). Prioritization, Scheduling, Urgency and Importance of Tasks. Determining task importance and priority is another critical issue for task management. In TeleNotes and ContactMap, users exploit spatial cues to signal relative task importance, e.g. by placing key tasks or contacts where they will definitely be seen. Another approach is to use temporal information, where users associate dates with tasks - with urgency being more clearly signaled as the deadline approaches (Bellotti et al., 2003). One problem with this approach is that not all tasks have specific deadlines, forcing users to estimate when those tasks must be done. If these estimates are inaccurate this can undermine the effectiveness of the priorization system. Other research uses machine learning to infer priority. The Priorities project uses classification learning algorithms to help assign the relative expected importance of incoming email messages, and incorporates this information into the user interface (Horvitz et al., 1999; Horvitz et al., 2002). Early investigations suggest this is a promising approach. Again, however, algorithm development needs to be informed by empirical studies of how people determine and evaluate importance. We also need design work to effectively integrate the outputs of these algorithms into the interface, along with hypothesis confirmation to overcome users’ suspicions of automatic methods (Whittaker et al., 2002b). Individual Differences. There is strong evidence for individual differences in the ways that people process and manage email (Bälter, 2000, Gwizdka, 2002, Mackay, 1988, Whittaker and Sidner, 1996). These studies found a consistent set of processing strategies, relating to the frequency with which people file information, the extent to which they defer processing tasks and the size of their inboxes (Bälter, 2000, Whittaker and Sidner, 1996). The same individual preferences are found too with voicemail and paper processing (Whittaker et al., 1998, 2002b, Whittaker and Hirschberg, 2001). Gwidka (2002) has built interfaces that are optimized for different users and cognitive styles, and future research should explore this idea further. In addition to this design work, we also need more theoretical research to inform our design activities. The Collaborative Task Management strategies and problems described here are general; they occur not only with email, but also when people process voicemail or paper information (Whittaker et al., 1998, 2002b, Whittaker and Hirschberg, 2001).
29
This suggests that, if we can develop a principled understanding of Collaborative Task Management, this may have important general implications for how people process personal information, whether this arrives in email, voicemail, paper or via some other medium. How might we develop a theoretical account of collaborative task management? We might employ core theoretical insights from CSCW and distributed work (Greif, 1988, Hutchins, 1994, Schmidt and Bannon, 2002) to better understand it. Other important theoretical insights might be derived from theories of attention (Horvitz, 2003, Simon, 1982). This work describes how people allocate limited computational or cognitive resources to an overabundance of incoming information, and this is certainly one formulation of the problem of processing email. Another set of relevant theories come from the communication literature. It has been suggested that people’s email behaviors can be explained using cognitive theories of conversational interaction such as common ground (Clark and Schaefer, 1989, Clark and Brennan, 1991, Clark and Wilkes-Gibbs, 1986). However such theories are only intended to explain synchronous rather than asynchronous conversation. They will need considerable modification if they are to account for core phenomena arising from message permanence, i.e. reminding and message context regeneration. These problems are not addressed in current synchronous theories but they give rise to the main problems of Collaborative Task Management (Whittaker et al., 1991, Erickson, 1999, Whittaker, 2002a). Finally a complete account of collaborative task management needs to integrate these reactive aspects of task management with ideas about how people plan and anticipate future activities, addressing how they determine which of a set of possible commitments they execute at which time (Suchman, 1987). Such integration is critical if we are to provide effective support for prioritization and scheduling of Collaborative tasks. In all these areas, there are strong possibilities of synergy between theoretical, empirical and design work, but much work still needs to be done. In conclusion, email is a very promising area for future research from both an applied and a theoretical standpoint. From a practical point of view it is important that we develop new systems to address the severe problems that users currently experience. Furthermore, these problems are general ones; they occur in other contexts, such as voicemail and paper processing. This suggests that effective solutions to the problem of Collaborative Task Management in email may have important general implications not only for email systems, but also for other aspects of personal information management.
NOTES Acknowledgments. Thanks to Jakov Kucan, Candy Sidner, Jerry Swanson, at Lotus/IBM, and Mike Creech, Ellen Isaacs, John Hainsworth, Quentin Jones, Bonnie Nardi, and Loren Terveen at AT&T, as well as to Irene Grief, Julia Hirschberg and Candy Kamm for supporting this research. Thanks also to Marilyn Walker for comments on early drafts.
30
Support. This research was partially funded under European Union Framework 6 grant: FP6-2002-IST-1. Authors’ Present Address. Steve Whittaker: Department of Information Studies, University of Sheffield, 211 Portobello, Sheffield, S1 4DP, UK, Email:
[email protected]
REFERENCES Ackerman, M. and McDonald, D. (1996). Answer Garden 2: Merging organizational memory with collaborative help, In Proceedings of Computer Supported Cooperative Work, 97-105, ACM Press, New York. Allen, T. J. (1977). Managing the flow of technology. MIT Press, Cambridge, MA. AOL (2003). www.aol.com Arons, B. (1993). Speechskimmer: Interactively skimming recorded speech. In Proceedings of the ACM Symposium on User Interface Software and Technology, 187–196. Baddeley, (1999). Essentials of Human Memory. Taylor & Francis, London. Bälter, O. (1998). Electronic Mail in a Working Context. Doctoral Dissertation, Royal Institute of Technology, Stockholm. Bälter, O. (2000): Keystroke Level Analysis of Email Message Organization, In Proceedings of CHI 2000, 105-112, ACM Press, New York. Bellotti, V., Duchenaut, N., Howard, M., and Smith, I. (2003). Taking email to task: the design and evaluation of a task management centered email tool. In Proceedings Of Computer Human Interaction, New York: ACM Press. Bellotti, V., Brinda Dalal, Nathaniel Good, Peter Flynn, Daniel G. Bobrow, Nicolas Ducheneaut (2004). What a to-do: studies of task management towards the design of a personal task list manager. CHI 2004: 735-742. New York, ACM Press. Blandford, A. & Green, T. (2001). Group and Individual Time Management Tools: What You Get is Not What You Need. Personal and Ubiquitous Computing, 5, 4, 213-230. Bly, S., Harrison, S., & Irwin, S. (1993). Media spaces: Bringing people together in a video, audio and computing environment, Communications of the ACM, 36, 2845. Boone, G. (1998). Concept features in Re:Agent, an intelligent email agent. Proceedings of International Conference on Autonomous Agents, 141-148, ACM Press, New York.
31
Borenstein, N. (1992). Atomicmail. Computational Mail as a network infrastructure for computer supported co-operative work. In Proceedings of CSCW 1992, ACM Press, New York. Borenstein, N., and Thyberg C. (1988). Co-operative Work in the Andrew message system. In Proceedings of CSCW 1988, 306-323, ACM Press, New York. Bowers, J., Button, G., and Sharrock, W. (1995). Workflow from within and without. Proceedings of European Conference on Computer Supported Co-operative Work. Clark H. & Brennan, S. (1991). Grounding in communication. In L.B. Resnick, J. Levine & S. Teasley, Eds. Perspectives on socially shared cognition. Washington DC., APA Press. Clark, H., & Schaefer, E. (1989). Contributing to discourse. Cognitive Science, 13, 259292. Clark, H. & Wilkes-Gibbs, D. (1986). Referring as a collaborative process. Cognition, 22, 1-39. Cohen, W. (1996). Learning rules that classify email. AAAI Symposium on Machine Learning in Information Access, 18-25, AAAI Press, Menlo Park. Cranor, L., and LaMacchia, B. (1998). Spam! Communications of the ACM, 41 (8), 7483. Donath, J., Karahalios, K., and Viegas, F. 1999. Visualizing conversations. In Proceedings of HICSS-32, Maui, HI. Dourish, P., Holmes, J., MacLean, A., Marqvardsen and Zbyslaw, A. (1996). Freeflow: Mediating between representation and action in workflow systems. In Proceedings of Conference on Computer Supported Co-operative Work, 190-198. ACM Press, New York. Duchenaut, N., and Bellotti, V. (2001). Email as habitat. Interactions, 8(5), 30-38, ACM Press, New York. Dunbar, R. (1998). Gossip, grooming and the evolution of language. London. Polity Press. Erickson, T. (1999). Persistant conversation: an introduction. Journal of ComputerMediated Communication, 4(4). Erickson, T. and Kellogg, W. 2000. Social Translucence: An Approach to Designing Systems that Mesh with Social Processes. In Transactions on Computer-Human Interaction. 7, 59-83. New York: ACM Press.
32
Farnham, S., Turski, A., Portnoy, W., & Davis, J. (2002). Connections: Exploring Who Knows Whom through Social Networks. Paper presented at HCIC 2002, Winter Park, Colorado. Fisher, D. and Dourish, P. (2004). Social and Temporal Structures in Everyday Collaboration. In Proceedings of CHI 2004. New York, ACM Press., Fisher, D. and Moody, P. (2001). Studies of automated collection of email records. University of California Irvine, Technical Report, UCI-ISR-02-4. Gartner. (2001). Trends in email usage. Geyer, W., Vogel, J., Cheng, L., Muller, M. (2003). Supporting Activity Centric Collaboration Through Peer to Peer Shared Objects. In Proceedings of GROUP 2003, 115-124. New York, ACM Press. Granovetter, M. (1973). The Strength of Weak Ties. American Journal of Sociology 78, 6, 1360-1380. Greif, I. (1988). Computer Supported Cooperative Work. San Francisco. Morgan Kaufman. Gwizdka, J. (2002). Reinventing the Inbox. Supporting Task Management of Pending Tasks in Email. In Proceedings of Conference on Human Computer Interaction, 550-551, ACM Press, New York. Henderson, D., & Card, S. (1986). Rooms: The use of multiple virtual workspaces to reduce space contention in a window based graphical user interface. In ACM Transactions on Graphics, 5, 211-243. Herring, S., 1999, Interactional Coherence in CMC, Journal of Computer Mediated Communication, 4, 23-38. Hinds. P., and Kiesler, S. (2002). Distributed work. Cambridge, MIT Press. Horvitz, E., Jacobs, A., and Hovel, C. (1999): ‘Attention-Sensitive Alerting’, in Proceedings of UAI ’99, Conference on Uncertainty and Artificial Intelligence, Stockholm, Sweden, July 1999, Morgan Kaufmann: San Francisco, 305-313. Horvitz, E., Kadie, C. Paek, T., and Hovel, D. (2003). Models of attention in computing and communication, CACM, 46(3), 52-59. Horvitz, E., Koch, P., Kadie, C., and Jacobs, A. (2002): ‘Coordinate: Probabilistic Forecasting of Presence and Availability’, in Proceedings of the Eighteenth National Conference on Uncertainty and Artificial Intelligence, Edmonton, Alberta, July 2002, AAAI Press, 224-233. Hutchins, E. 1994. Cognition in the Wild. MIT Press, Cambridge, MA 33
Isaacs, E., Whittaker, S., O'Conaill, B., and Frohlich, D. (1997). Informal communication re-examined: new functions for video in supporting opportunistic encounters. In K. Finn, A. Sellen, S. Wilbur (Eds.), Video mediated communication. LEA: NJ. Kaptelinin, V. (2003). UMEA: translating interaction histories into project contexts. In Proceedings of CHI 2003, 353-360. New York, ACM Press. Kidd, A. (1994). The marks are on the knowledge worker. In Proceedings of Conference on Computer Human Interaction, 1994, ACM Press, New York. Kraut, R., C. Egido, and J. Galegher. (1990a). Patterns of contact and communication in scientific research collaboration, 149-17. In J. Galegher, R. Kraut, and C. Egido, (Eds.), Intellectual Teamwork: Social and Technological Foundations of Cooperative Work. Lawrence Erlbaum Associates, NJ. Kraut, R., Fish, R., Root, B., and Chalfonte, B. (1990b). Informal communication in organizations: Form, function and technology. In S. Oskamp and S. Spacapan, (Eds.), People's reactions to technology in factories, offices and aerospace, 145199, Sage Publications Lansdale, M. 1988. The psychology of personal information management. In Applied Ergonomics, 19, 55-66. Levitt, M. (2000). Email usage forecast and analysis, 2000-2005, IDC Report W23011. Leuski, A. (2001). Evaluating document clustering for interactive information retrieval. In Henrique Paques, Ling Liu, and David Grossman, editors, Proceedings of Tenth International Conference on Information and Knowledge Management (CIKM'01), 41-48. New York, ACM Press. Leuski, A. and Allan, J. (2000). Strategy-based interactive cluster visualization for information retrieval. International Journal on Digital Libraries (IJODL), 3(2):170-184. Luff, P. Heath, C. and Greatbatch, D. (1992). Tasks-in-interaction. Paper and screen based documentation in collaborative activity. In Proceedings of Conference on Computer Supported Co-operative Work, 163-170, ACM Press, New York. Mander, R., Salomon, G. & Wong, Y. (1992). A "pile" metaphor for supporting casual organizaion of information. In Proceedings of CHI'92 Human Factors in Computing Systems, 627-634, ACM Press, New York. McDonald, D. and Ackerman, M. (1998). Just talk to me: a field study of expertise location. In Proceedings of Computer Supported Cooperative Work, 315-324, ACM Press, New York.
34
McDonald, D.W. Recommending Collaboration with Social Networks: A Comparative Evaluation. Proceedings of the ACM 2003 Conference on Human Factors in Computing Systems (CHI'03), April 2003. Mackay, W. (1988): More Than Just a Communication System: Diversity in the Use of Electronic Mail, in Proceedings of Computer Supported Cooperative Work, 344353, ACM Press, New York. Mackay, W. E., Malone, T. W., Crowston, K., Rao, R., Rosenblitt, D., & Card, S. K. (1989). How do experienced information lens users use rules? In Proceedings of the Conference on Human Computer Interaction, 211-216. ACM Press, New York. Malone, T. (1983). How do people organize their desktops? Implications for the design of office systems. ACM Transactions on Office Information Systems, 1, 99-112. Malone, T. W., Grant, K. R., & Turbak, F. A. (1986). The information lens: an intelligent system for information sharing in organizations. In Proceedings of the Conference on Human Computer Interaction, 1-8, ACM Press, New York. Mock, K. (2001). An experimental framework for email categorization and management. In Proceedings of SIGIR Conference on Research and Development in Information Retrieval, 392-393, ACM Press, New York. Nardi, B., Whittaker, S., and Schwarz, H. (2000a). It's Not What You Know, It's Who You Know: Work in the Information Age. First Monday, www.firstmonday.org. Nardi, B., Whittaker, S., Bradner, E. (2000b). Interaction and Outeraction: Instant Messaging in Action. In Proceedings of Conference on Computer Supported Cooperative Work, 79-88, ACM Press, New York. Nardi, B., Whittaker, S., Isaacs, E., Creech, M., Johnson, J., and Hainsworth, J. (2002). Integrating Communication and Information Through ContactMap. Communications of the ACM, 45, 89-95. Pazzani, M. (2000). Representations of email filtering profiles: a user study. In Proceedings of Intelligent User Interfaces. Pitney Bowes (2000). Increased use of electronic communications tools among North American and European workers, press release, August, 2000. Prinz, W. (1993). TOSCA. Providing Organisational Information to CSCW applications. In European Conference on Computer Supported Co-operative Work, 139-154. Resnick, P. and Varian, H. (1997). Recommender Systems, Communications of the ACM, 40(3), 106-108.
35
Rohall, S., Gruen, D., Moody, P., Kellerman, S. (2001). Email visualizations to aid communications. IEEE Symposium on Information Visualization, 12-15, IEEE Press, New York. Schmidt, K., & Bannon, L. (1992). Taking CSCW seriously: Supporting articulation work. Computer Supported Cooperative Work, 1, 1-2, 7-40. Segal, R., and Kephart, J. (1999). MailCat: an intelligent assistant for organizing email. In Proceedings of Conference on Autonomous Agents, 276-282, ACM Press, New York. Sellen, A., and Harper, R. (2002). The Myth of the Paperless Office, MIT Press, Cambridge, MA. Simon, H. (1982). Designing organizations for information-rich worlds. Cambridge, MA: MIT Press. Smith, M. and Fiore, A. 2001. Visualization components for persistent conversations. In Proceedings of Conference on Computer Human Interaction, 136–143, ACM Press, New York. Suchman, L. (1986). Plans and Situated Actions. Cambridge, Cambridge University Press. Suchman, L. (1994). Do categories have politics? Computer Supported Co-operative Work, 2(3), 177-190. Takkinnen, J., and Shahmehri, N. (1998). CAFÉ: a conceptual model for managing information in electronic mail. In Proceedings of HICCS, 44-53, IEEE Press, New York. Venolia, G., Gupta, A., Cadiz, J.J., and Dabbish, L. (2001). Supporting Email Workflow. Microsoft Technical Report. MSR-TR-2001-88. Venolia, G., and Neustaedter, C. (2003). Understanding sequence and reply relationships within email conversations. In Proceedings of Conference on Computer Human Interaction. ACM Press, New York. Viegas, F.B. and Donath, J.S. (1999). Chat Circles, In Proceedings of Conference on Computer Human Interaction 9-16, ACM Press, New York. Voorhees, E. (1986). Implementing agglomerative hierarchical clustering algorithms for use in document retrieval. Information Processing and Management, 22, 465-76. Wellman, B. (2001). Computer Networks as Social Networks. Science, 293, 2031-2034. Whittaker, S. (2003). Computer mediated communication: a review. In Graesser, A. (Ed.) The Handbook of Discourse Processes. Erlbaum, New Jersey. 36
Whittaker, S., and Amento, B. (2003). Seeing what you hearing: coordinating responses to trouble reports in network troubleshooting. In Proceedings of European Conference on Computer Supported Cooperative Work, 219-238. Kluwer, Netherlands. Whittaker, S., Brennan, S., & Clark, H.H. (1991). Co-ordinating activity: an analysis of computer supported co-operative work. In Proceedings of CHI'91 Human Factors in Computing Systems, 361-367, New York: ACM Press. Whittaker, S., Frohlich, D., and Daly-Jones, O. (1994). Informal communication: what is it like and how might we support it? In Proceedings of Conference on Computer Human Interaction, 130-137, ACM Press, New York. Whittaker, S., and Hirschberg, J. 2001. The character, value and management of paper archives. Transactions on Computer Human Interaction, 8, 150-170. Whittaker, S., Hirschberg, J., and Nakatani, C. H. (1998). All talk and all action: strategies for managing voicemail messages, In Proceedings of Conference on Computer Human Interaction, 1998, ACM Press, New York. Whittaker, S., Hirschberg, J., Amento, B., Stark, L., Bacchiani, M., Isenhour, P., Stead, L., Zamchick G., & Rosenberg, A. (2002b). SCANMail: a voicemail interface that makes speech browsable, readable and searchable. In Proceedings of Conference on Human Computer Interaction, ACM Press, New York. Whittaker, S. Jones, Q., and Terveen, L. (2002a). Persistence and Conversation Stream Management: Conversation and Contact Management. In Proceedings of HICCS’02, IEEE Press, New York. Whittaker, S. Jones, Q., and Terveen, L. (2002c). Contact Management: Identifying Contacts to Support Long term Communication, In Proceedings of Computer Supported Cooperative Work, ACM Press, New York. Whittaker, S., Jones, Q., Nardi, B., Creech, M., Terveen, L., Isaacs, E., Hainsworth, J. (in press). ContactMap: Organizing Communication in a Social Desktop. To appear in ACM Transactions on Computer Human Interaction. 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. Whittaker, S., Swanson, G., Kucan, J., & Sidner, C., (1997). Telenotes: managing lightweight interactions in the desktop. Transactions on Computer Human Interaction, 4, 137-168. Whittaker, S. (1996). Talking to strangers. In Proceedings of Conference on Computer Supported Co-operative Work, New York, ACM Press.
37
Whittaker, S., Terveen, L., Hill, W., and Cherny, L. (1998). The dynamics of mass interaction. In Proceedings of Conference on Computer Supported Co-operative Work, New York, ACM Press. Willett, P. (1988). Recent trends in hierarchic document clustering: a critical review. Information Processing and Management, 24, 5, 577-597. Winograd, T. (1994). Categories, Discipline and Social Coordination, ComputerSupported Cooprerative Work, 2(3), 177-190. Zamir, O. Etzioni, O. Madani, O. and Karp, R. (1997). Fast and intuitive clustering of Web documents. In Proceedings of the 3rd International Conference on Knowledge Discovery and Data Mining, 287-290, 1997.
38
FIGURE 1 - TELENOTES DESKTOP INTERFACE SHOWING MULTIPLE PILES, A ‘TODO’ LIST AND AN OPEN MESSAGE
39
FIGURE 2 – OPENING A PILE TO ACCESS PRIOR TASK RELATED MESSAGES
40
Group Icons Icons Representing Individual Contacts Groups of Contacts
FIGURE 3 – CONTACTMAP USER INTERFACE SHOWING STRUCTURED SOCIAL REPRESENTATION
41
Reminders
Email alert showing new message Email viewer
Note associated with reminder
FIGURE 4 - ACCESSING EMAILS EXCHANGED WITH SELECTED CONTACTS, REMINDERS AND EMAIL ALERTS IN CONTACTMAP
42
