Opportunities for Automating Email Processing: A

Need-Finding Study
Soya Park Amy X. Zhang Luke S. Murray David R. Karger
MIT CSAIL MIT CSAIL MIT CSAIL MIT CSAIL
[email protected] [email protected] [email protected] [email protected]

ABSTRACT 1 INTRODUCTION
Email management consumes significant effort from senders In the 50 years since email was invented, it has become
and recipients. Some of this work might be automatable. We not only a ubiquitous tool for private and group commu-
performed a mixed-methods need-finding study to learn: (i) nication [6, 32, 58] but also a place for managing personal
what sort of automatic email handling users want, and (ii) information [10], activities and events [5, 56], and tasks [12].
what kinds of information and computation are needed to As a result, email today has become closely associated with
support that automation. Our investigation included a de- work, and for many people, a majority of their workday is
sign workshop to identify categories of needs, a survey to spent within email [21, 56].
better understand those categories, and a classification of ex- Given the workload it generates, there has been a long-
isting email automation software to determine which needs standing desire to automate various aspects of email process-
have been addressed. Our results highlight the need for: a ing, reaching at least as far back as procmail, released in
richer data model for rules, more ways to manage attention, 1990, which let authors write regular-expression scripts to
leveraging internal and external email context, complex pro- filter email into chosen folders. Over time, richer automation
cessing such as response aggregation, and affordances for functionalities have emerged. For example, Boomerang [8]
senders. To further investigate our findings, we developed a permits users to defer received emails, pushing them off to
platform for authoring small scripts over a user’s inbox. Of be re-received at a later date. Different apps offer different
the automations found in our studies, half are impossible in automation features, forcing a user to juggle a suite of 3rd
popular email clients, motivating new design directions. party plugins to manage all their needs, rely on a human
assistant, or simply do everything manually [5].
CCS CONCEPTS
• Social and professional topics → Automation; • In-
Approach. In this work, we sought to explore the breadth
formation systems → Email;
of needs that users have regarding automating their email
KEYWORDS experience, with the eventual goal of designing a useful,
general purpose email automation system. We conducted
email; task management; personal information management
this work through a series of three distinct need-finding
ACM Reference Format: probes as shown in Table 1. First, we aimed to gather from a
Soya Park, Amy X. Zhang, Luke S. Murray, and David R. Karger. broad audience of users wishful thinking ideas for automat-
2019. Opportunities for Automating Email Processing: A Need- ing email in their own inboxes. From a formative design
Finding Study. In CHI Conference on Human Factors in Computing workshop with 13 email users who were asked to brainstorm
Systems Proceedings (CHI 2019), May 4–9, 2019, Glasgow, Scotland commands in natural language that they would like to exe-
UK. ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/
cute, we developed a series of common categories of needs,
3290605.3300604
including attention management and prioritization, filing
Permission to make digital or hard copies of all or part of this work for and labeling, automated content processing, and rules based
personal or classroom use is granted without fee provided that copies are not on contextual modes. These categories informed the design
made or distributed for profit or commercial advantage and that copies bear of a survey that we distributed to 77 additional people. The
this notice and the full citation on the first page. Copyrights for components survey contained sections dedicated to each category with
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
open-ended prompts asking for more ideas for automations
redistribute to lists, requires prior specific permission and/or a fee. Request users would like to perform.
permissions from [email protected]. Moving from users’ ideas regarding automation, we next
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK sought to identify the ways in which users were already au-
© 2019 Association for Computing Machinery. tomating aspects of their email to see which needs have been
ACM ISBN 978-1-4503-5970-2/19/05. addressed. As automation capabilities available to end users
https://doi.org/10.1145/3290605.3300604
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK S. Park et al.

in many email clients are limited, we instead examined au- % of Needs

tomations implemented by programmers, who have greater # of
Impossible to
ability to carry out their desires for personalized automation. Probe Method Participants
Express in
We conducted this probe by mining public repositories on or Scripts
Current Interfaces
Github that make use of the IMAP (Internet Message Ac-
Open-ended survey 77 47.1%
cess Protocol) API. From around 500 scripts, we developed a
taxonomy of 8 types of automated email processing tools. Large-scale email
499 90.6%
Even for programmers, writing a standalone mail automa- scripts review
tion program is a substantial task. This could deter many Email programming
12 40.4%
automations from ever being created. Therefore, informed by deployment
these two probes, we developed a platform called YouPS that Table 1: Three different probes of email need-finding.
makes it possible for users to write, test, debug, save, and
continually execute simple Python scripts that can manipu-
late emails arriving in their inbox. YouPS exposes a small set
of Python functions for basic actions such as accessing an could not be expressed using common email clients today,
email field or moving an email to a particular folder, hiding for instance with Gmail and Outlook tools for writing fil-
all the complexity of turning these function calls into invo- ter rules. Thus, meeting those needs requires new features
cations of the IMAP API to manipulate the users’ email on within email systems, such as expanding email’s data model
their server. This platform served as a probe into what kinds to add latent structure, as well as incorporating more context.
of scripts email users would write given the opportunity to In addition, systems need new mechanisms for users to be
easily test and run them over their own email. We invited 12 able to express how they want emails to be presented and
subjects to write and execute scripts on YouPS for a week; processed.
we then examined their scripts and interviewed them about On the other hand, we also found that over half of the
their experiences. automation examples from the survey and the deployment
of YouPS could already be implemented in today’s email sys-
Results. Our design workshop identified several common tems, as shown in Table 1. However, some implementations
categories of needs in email automation, which were eluci- are not straightforward, involving hacks that repurpose ex-
dated through our later studies. The first was a richer data isting email features like the read/unread signal. This lack
model for an email to capture latent structured information of usage coupled with workarounds using existing features
such as priority, topic, deadline, and need for a reply. The suggest that email users are not satisfied with existing tools
next was automation leveraging the context of an email, both for automation in current email interfaces. We touch on fu-
within and beyond the email inbox. Some examples include ture work towards designing interfaces for general purpose
the time of day, characteristics of the email thread (e.g., pre- email automation authoring.
vious replies by a recipient, number or rate of responses by
others), and the state of the recipient (e.g., busy, sleeping, in 2 RELATED WORK
the office, on vacation). These attributes and contextual infor- Email management has been explored through many differ-
mation are needed to drive automations that help recipients ent lenses by the HCI community. Some of the categories
with attention management of email through the configu- identified in our probes have been touched on by prior work.
ration of different forms of notifications and presentations
of messages. In an interesting inversion, we also found that Organizing Email. While there has been substantial research
senders wanted to leverage rich data and context to reduce on email users, much of it has focused on organization and re-
load on recipients, for example by automatically delaying an trieval needs rather than automation needs. Email users view
email from being sent until the recipient is in a not-busy email as a repository for personal information management
context or at a suitable location. Finally, users sought auto- (PIM) [55], where they have different strategies for retrieving
mated content processing, for example to aggregate replies information [3, 40, 47, 49, 51]. For instance, users frequently
to an invitation or to extract attached photos into a relevant send emails to themselves as a way to store information [10].
storage location. Szóstek et al. [50] identified six needs for information or-
From these findings, we consider how email systems could ganization: email annotation, reliable structure, prioritizing
better allow users to automate and customize email handling. emails, informative overview, flexible sorting, and efficient
We found that many users’ needs required information and search. Finally, others study usage beyond PIM, including
affordances that are not currently available in email sys- shared inboxes jointly accessed by a team [39]. Our research
tems. From our three studies, 47%, 90%, and 40% respectively builds upon this work by identifying additional needs as well
Opportunities for Automating Email Processing: A Need-Finding Study CHI 2019, May 4–9, 2019, Glasgow, Scotland UK

as considering how systems could address such needs, given that they were not already doing. As open-ended articulation
that current email clients do not fully address them. of needs can be challenging for users, we began with a small,
in-person, formative workshop to develop initial categories
Systems for Triaging Messages. When it comes to existing
of needs that then informed the structure, questions, and
automations, automatic classification is one that is widely
examples in a survey that we distributed at a larger scale.
offered in email clients. Many email clients automatically
The survey aimed to determine whether the needs identified
classify and prioritize emails using machine learning tech-
in the workshop would be reflected in a broader and more
niques [25, 29, 57]. Beyond spam classification, clients like
diverse population as well as gain deeper insight into user
Gmail offer additional classifications by default such as “So-
desires for automation.
cial” or “Promotions”. However, users may wish to classify
their emails in a different or more fine-grained manner than Formative Design Workshop. We conducted a design work-
the default classes email clients provide. So many clients pro- shop with 13 participants (10 females, 3 males). Subjects were
vide simple explicit rule-authoring interfaces for end-users all computer science students with knowledge of program-
and programmers [23, 44]; for example, users can specify ming. We asked them to use natural language or pseudocode
rules for placing messages in folders. to write email rules that they would like to execute on their
While most existing filter interfaces are focused on ex- inbox as either senders or receivers of email, invoking any
plicit metadata within messages, other ways of classification methods or objects that they could imagine existing. Over
and sorting of messages have been proposed [15, 42, 50]. the course of 45 minutes, participants came up with 42 dif-
For instance, research has found that email users tend to see ferent rules. Afterwards, the authors as a group analyzed the
messages as tasks and have a desire to conceptualize email as rules that participants generated and identified five major
a task management tool [4, 13, 27]. In this work, we provide categories of needs.
empirical examples of the kinds of alternative classifications,
prioritizations, and actions following from these that email Survey. Based on the needs identified from the design work-
users would like, in order to guide the design of future sys- shop, we designed a survey to explore each category of needs
tems. We also demonstrate how desired classifications and in more depth. We asked open-ended questions about how
priorities can be time-varying based on the user’s state. the user would like to automate their email. To prompt users
to think outside the realm of what is currently possible but
Automation for Recipients & Senders. Email users are both
also be explicit in their descriptions, we told participants to
senders and recipients, and systems provide automation ca-
imagine using a smart robot that can organize their email and
pabilities addressing both roles. For instance, email clients
change how it is presented to them. The questions offered
provide two types of reminders. Email users can set a re-
rules drawn from the workshop as examples. The survey
minder for messages to get back to it later (reminder as a
was structured into eight randomly ordered sections based
recipient) and remind their recipients to solicit responses
on the needs identified in the workshop:
(reminder as a sender) [1, 8, 18, 19, 34]. There are also plat-
forms that allow users to write simple triggers and actions • Triaging and prioritizing incoming emails
to integrate with different applications [26, 37]. • Moving incoming emails to different locations
As recipients, users want to easily draft responses [28], • Labeling emails with richer data as sender or receiver
automatically adjust views for different email data [16], and • Sending email only at a particular time or context
organize cluttered messages [17]. Email users also want to ag- • Sending email to only the right people
• Different email modes that can be toggled (vacation, etc.)
gregate replies to manage bulk emails [30] and automatically
• Altering the presentation of emails in the inbox
process responses using pre-defined queries [36]. Senders • Aggregating or processing multiple emails or email replies
on the other hand would like to hint to their recipients how
to respond [20]. Borenstein et al. [9] suggested Tcl language- The survey was distributed through various mailing lists
enabled email to deliver executable contents (e.g., a prompt within a private university and by word of mouth. It was
window) to recipients. In this work, we draw from and build taken by 77 people (31 females, 41 males, 1 other, rest unan-
upon this prior work to explore the general space of email swered). The median age range was 20–29. While most of
automation for both email recipients and senders. our respondents were affiliated with the university, 34.5%
of our respondents were not students or faculty. In addi-
3 PROBE 1: WISHFUL THINKING tion, 48% of respondents did not have technical backgrounds,
To identify common categories of desired automations that instead working as administrative staff or as students in non-
are difficult or impossible to recreate with current email technical majors. All of our participants fall into the general
inbox technology, we began by asking email users to come up category of “knowledge workers”, an important category
with ideas for ways they would like to automate their email that has been the focus of much study [11, 46].
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK S. Park et al.

We used a grounded theory approach [48] to identify time-varying). For example, the rule “Send a message if I
themes in the survey answers. Two authors individually haven’t touched base for a month” requires interaction
open-coded the responses, then discussed them after the history with the recipient of the message (internal context),
fact, merging similar codes and grouping codes into distinct as mentioned in the prior category. Another state that was
themes. To validate the merged codes, we selected 10 survey often referenced was whether a recipient had replied to the
participants at random, and the two authors independently original message: “If the recipient hasn’t replied
re-labeled each of their survey responses using the merged for n days, send them a reminder”.
codes. From the 90 responses that were coded, we found an In contrast, “Don’t notify emails from these campus
inter-rater reliability (IRR) of 79% using Cohen’s κ. mailing lists during my summer vacation” requires
external context that involves determining whether the ar-
Results rival time of an email is during a user’s summer vacation.
We describe the main categories of needs uncovered in the The external context may also change more frequently, for
workshop and the analysis of the different survey responses instance when one respondent said: “I don’t think priority is
within each category. In the survey, we compared responses a consistent definition. For 30-40 hours per week, my research,
between academics and non-academics, as well as between colleagues, advisors are high on my priorities. However, out-
people with and without technical backgrounds, overall find- side of that time, my priorities shift around a little: my side
ing no major differences between these groups. Thus, we project becomes my focus...one idea is to have these incoming
present survey results across all participants. messages reflect this ebb and flow of priorities.” Motivated
by several rules during the workshop referencing different
Richer Data Models. Many of the email rules that partici-
external contexts, we asked survey participants to come up
pants devised required access to latent information about the
with email modes that could trigger different behavior in
message that was not explicitly given in the email headers
their inbox. Respondents thought of many types of modes:
or in attributes of each message like sender or date. From
the survey, we identified the following desired latent data: conference, work, vacation, home/family, busy,
progress (e.g., pending, done), deadline, topic, priority, task. study, distraction, class, important, person, block-
Users desired automatic annotation of messages with these /harassment, waiting, application, sleep, week-
latent attributes that could be used to drive rules. For exam- end, evening, summer, semester, daytime, emotion,
ple, there were rules such as: “If the content of the recreation, meeting, ignore
message seems like it requires an action, label Each of these modes came with distinct rules for behav-
it as ‘pending’” and “If the email has a deadline, ior. For example, a user’s conference mode had a rule that
tag the deadline”. highlighted only conference-related emails (e.g., meet-ups,
Because prioritization was a commonly articulated need announcements). The emotion mode came from a user who
in the workshop, in the survey we asked users to describe proposed having different modes that would kick in depend-
attributes that signal priority specifically. Respondents used ing on their mood, such as when they felt anxious or tired.
information about the sender, assigning high priority for
Attention Management. Many users’ needs for richer data
messages from important contacts and lowering the priority
models and context related to the end goal of managing at-
of automated or blast emails. Respondents also wanted to
tention as a recipient of email. Users described many ways to
prioritize by the number of follow-up tasks, so a message
leverage these priorities to change the notification behavior
requiring no action (e.g., an FYI) would have a lower prior-
or presentation of emails, including (automatically) marking
ity. Finally, 14% of users wanted to take into account their
them as read or unread, moving them to other less or more
previous interactions with a person or organization when
attended folders, hiding emails until a particular time, and
prioritizing an email. For example, some respondents wanted
bringing them to the top of the inbox or pushing them farther
to have emails marked as high priority if they had sent re-
down. The way users repurposed interface affordances for at-
sponses to the last several emails from the same sender and
tention management—for example, marking a read message
low priority if they had not opened or sent a response.
as unread in order to make it stand out—raises the question
Using Internal/External Context. While some attributes of whether there might be other attention-getting techniques
of an email such as deadline can be determined by examining that would be a better fit.
the message in question, others require access to a broader How to configure push notifications also arose frequently,
context [2, 53] around the message. This includes both inter- reflecting that email (once an asynchronous communication
nal context involving other messages within the inbox of the medium) has taken on some attributes of more synchronous
sender or receiver generally, as well as external context [60] communications such as instant messaging. Users overall did
regarding the state of the user and the world (which is often not want to be notified about every email, but did want to
Opportunities for Automating Email Processing: A Need-Finding Study CHI 2019, May 4–9, 2019, Glasgow, Scotland UK

be immediately notified about certain prioritized emails [35]. as moving, hiding, or sorting emails, we asked survey par-
Users considered a variety of push notification channels such ticipants to consider potential new presentations of their
as buzzing the phone and sending SMS messages. Other users inbox [14, 22, 54]. We found many interested in alternative
came up with automatic rules to mark-as-read emails that views for email threading. Participants suggested different
should not trigger such notifications. Still others wanted to presentations such as a tree-like network visualization of
mute notifications entirely or receive digest notifications replies per email thread, echoing prior work [45]. Partici-
after they had accumulated for a while instead of for every pants also wanted to break up long messages, group together
email. Examples of notification rules users wrote include: short messages, or group by different attributes like sender.
• Don’t notify me about emails from these campus One participant said: “In Slack, you can send individual sen-
mailing lists during my summer vacation tences/thoughts one-by-one as you’re typing a larger message,
• If this sender sends me too many emails within a so it’s easier to divide big thoughts into bite-sized chunks. I
short period, mute emails from the sender mean, who wants to send a one-line email?” Connected to
message segmentation, another participant said she’d like
Sender Affordances. While email research generally fo- to be able to reference or quote from prior emails so that
cuses on users reducing their own email workload, evidence recipients could follow the source.
shows that users care significantly about the impact their
email sending has on others’ workloads, and seek ways to Content Processing and Aggregation. Finally, we found
reduce that impact [58]. Some subjects asked for a reaction many rules regarding complex processing of content within
or upvote feature to signal that they saw a message with- emails in order to make decisions about forwarding emails to
out burdening the recipient with another response. As an- other people [33] or extracting information to send to other
other example, senders wanted to be able to set emails to platforms or store in other formats. For instance, several
expire at a certain time or when other conditions were met: subjects said that they wanted to extract event information to
“For event announcement emails, self-destruct the store within a calendar application. Other examples include:
emails from recipients’ inbox after the event”. • If I forward this email to a certain email address,
Context regarding a recipient’s availability or responsive- parse the content and add it as a note
ness [52] could also be used by a sender to decide when • If a message contains attachments, add them to
or how to send a message. Unfortunately, today, such con- one of my cloud folders
text is often delivered to senders in a catchall fashion using Survey respondents additionally came up with ideas for
auto-replies (e.g., out-of-office replies), which forces an ex- response aggregation [30]. For example, when scheduling a
tra message. For instance, one person wanted to send an meeting, attendees can either respond to everyone, or to
automatic response to incoming emails if their inbox had the sender, but a sender cannot collectively aggregate re-
surpassed a certain number of unread emails. sponses into a poll. Respondents said they would like to see
As an additional way to reduce load on recipients, senders a summary of a group of responses rather than a series of
wanted a way to target only the right recipient subset of different emails containing all of the original responses. Also,
a mailing list. In particular, in the workshop there was a others mentioned interest in some sort of chart, calendar, or
high demand for querying particular groups of recipients other aggregate visualization of responses. Besides the novel
(e.g., people I have exchanged email with more than three presentation required, this demands a richer data model for
times, people who reside in a particular city, people in my email to represent the data to be aggregated.
address book). These queries typically required metadata
from previous emails (internal context) or even from 3rd 4 PROBE 2: EXISTING AUTOMATION SOFTWARE
party applications such as a calendar (external context): Our second probe aimed to identify email automation needs
• If I reply to an email thread, send my reply only that (programmer) users have taken into their own hands to
to those who expressed interest address. To do so, we mined Github to identify and examine
• Send only to people in lab right now because I code written to automate email processing. In contrast to
need a stapler our first probe which only called for (lightweight) wishful
Recognizing that recipients may not always be paying thinking, this probe allows us to identify needs that were
attention to the group thread or mailing list, several users important enough to actually implement. Of course, our
also wanted the tagging feature common in social media to focus on code means our user population has narrowed to
signal importance to certain recipients. programmers. Probe 1 did suggest that overall, programmers
and non-programmers recognize similar needs, so seeing
Altering Inbox Presentation. In addition to the existing what programmers implemented may suggest automations
capabilities in email clients for managing presentation, such of value to non-programmers. We also did find that Probe 2
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK S. Park et al.

Category Count system. Some scripts attempted to download message con-

tents, particularly attachments (e.g. receipts, contact info),
Triggering actions based on content 134
to places such as their desktop or the cloud.
Altering default presentation of email client 118 Many of these scripts echoed the need for content process-
Archiving emails to new locations 110 ing and aggregation in Probe 1 to automate repetitive tasks.
Email as middleware 48 Many scripts also extracted latent structure from emails,
Customized notifications 39 reflecting the desire for richer data models. Overall, we
Email analytics and productivity tools 25 found complex processing needs were prevalent, comprising
Detecting and removing spam 25 around 50% of scripts. This may be because people who pro-
Inbox cleanup and “Inbox Zero” 23 cess large amounts of information via email were compelled
Table 2: 8 major functions of email scripts on Github. to write scripts to save themselves time and effort and thus
were more represented in Probe 2 than in Probe 1.
Altering the default presentation of email clients. Echo-
ing survey results on altering inbox presentation, a number
revealed some needs that a non-programmer may not have of scripts focused on displaying email threads in a different
or may not realize can be resolved by automation. way, mimicking applications like Slack or Facebook. We also
Method. On Github, we searched for code that made use found scripts with more minor tweaks to current email client
of IMAP (Internet Message Access Protocol), the standard presentations. For instance, there were scripts that displayed
protocol for connecting to a user’s mail-server account and one’s inbox not by email subject lines but rather by some
accessing and manipulating email on it. We focused our metadata of the email content. Several scripts also aimed
search to code written in Python, which has a built in library to personalize push notifications for new emails, similar to
called imaplib. We also included searches for two particu- rules in Probe 1 regarding attention management. For exam-
larly popular wrapper libraries for imaplib called imappy ple, one script interfaced with a Raspberry PI and displayed
and imapclient. To exclude the many artifacts that used visual effects when an email arrived in the user’s inbox.
IMAP simply to send application notifications, we also lim- Email as middleware. In a divergence from the survey, we
ited the search to repositories that included the term “email” found scripts that attempted to use the inbox as middleware,
in their README documentation. towards performing actions outside of a user’s inbox. Given
From an initial 524 scripts, we excluded 25 that were code- the accessible and ubiquitous nature of email, some scripts
example skeletons that had not been filled in, resulting in enable users to use email as a form of cloud storage. Others
499 scripts. The first author went through each script using enable users to trigger defined actions via email, such as
an open-coding approach as in the survey to identify the uploading pictures to an online library, or controlling soft-
main functions performed. Eight codes emerged, with each ware remotely through the use of keywords. This technique
script labeled with one or more codes. To validate our codes, a is relatively technical, so it is understandable that it didn’t
second author used the identified categories to independently occur to our survey respondents as a possibility. Previous
re-label a random sample of 30 scripts, achieving an inter- studies [38] have found similar uses, such as users using a
rater reliability of 64.9% using Cohen’s κ. folder to label emails that have to be printed.
Results Inbox cleaning and spam removal. We saw a number of
In Table 2, we present the 8 major categories of functions and scripts focused on inbox cleanup to remove unimportant or
their frequency in our dataset. Some scripts performed two spam emails. Some scripts attempted to delete unimportant
or more functions and so had multiple labels. While many messages regularly so that users could focus their attention
of the scripts addressed needs that were found in the first on important messages. For instance, we encountered scripts
probe, we also noticed some new categories of needs. concerned with the “Inbox Zero” approach to email man-
agement. The goal of this approach is to achieve as close
Processing, organizing, and archiving content. Over a to zero messages in a user’s inbox at any given time. These
fifth of the scripts triggered some sort of action (e.g., send scripts offer similar functionality to the sweep rule feature
auto-responses, mark read, move to a folder) based on infor- in Outlook, which runs at regular intervals to delete emails
mation parsed from an email. The most popular example was based on a user’s rules.
extracting part of an email and then replying with or send- Some scripts were also focused on auto-removing spam
ing the processed content to another user. Almost equally emails. Unlike the survey respondents, programmers in-
popular were scripts that exported content from the email corporated engineering techniques to automatically extract
Opportunities for Automating Email Processing: A Need-Finding Study CHI 2019, May 4–9, 2019, Glasgow, Scotland UK

spam-related attributes of emails at a fine-grained level. Some Method Description

of these scripts used machine learning libraries to train spam
[get, set]_mode() Managing email modes
filters. It was unclear based on the scripts alone whether the
programmers were attempting to replace current spam filter get_history(contact) Return interaction history with
functionality in common email clients, or whether they were the given contact
simply trying to implement basic machine learning models. get_[content, date, Return metadata of the email
Spam was not mentioned as frequently in Probe 1, possibly label, sender, subject,
because users were satisfied with their existing spam filters. recipient]()
Table 3: Examples of YouPS methods
Email analytics and productivity tools. Finally, we ob-
served instances of the reflective conversation [24] when it
came to tasks within emails, such as scripts that collected Why did you implement
the code this way?
analytics such as response rate or frequency of recipients.
The scripts provided statistics and insights to the users about
how well they accomplished and completed email actions.
Popular statistics like response rate were used as a mea-
sure of productivity week-to-week. This category was not
mentioned as often in Probe 1, again possibly due to an over- @Clerkbot
representation of users in Probe 2 who have more intense https://github.repo#L10
“To engine facilitate..”
workloads within email, or due to a correlation between pro-
gramming skills and an interest in visualizing data about or
Subject: [calendar] Seminar announcement on Thu, 20 Sep 2018 00:30:15
optimizing one’s own activities (i.e., the “quantified self”). >> Forwarded to work contacts
>> Added the
5 PROBE 3: FIELD DEPLOYMENT OF SIMPLE conversation to
the code repository!
INBOX SCRIPTING Figure 1: The YouPS interface. Users can program and debug Em
Our final probe involved having users author rules to ad- their email rules with interactive editors and a console.
dress their needs in a real environment over time. Even for
programmers, writing an email automation is a significant
programming task, which will likely deter many of them IMAP API
from undertaking the work. Thus, to inspect how program-
mers might customize email handling if it were less work, we
deployed an experimental email engine that aims to dramat-
ically simplify the task of authoring email rules. In contrast Email client Email Server YouPS
to Probe 1, we can see the rules users would actually write,
as well as revise, over the course of a week on real emails, Figure 2: YouPS accesses each user’s inbox through IMAP
as opposed to simply users’ ideas for automation. and generates a sandbox environment to execute their rule.
To facilitate this probe, we developed YouPS, a system
that lets users write email processing rules in Python and ex-
ecutes them over their IMAP API mailboxes. YouPS provides
email mode. Users can write different rules for each mode
a Python environment populated with objects representing
so that their inbox behaves differently depending on the
the user’s email and folders, and methods that can access and
current mode. User can set their active email mode using a
manipulate them; it implements those methods by interact-
dropdown menu on the YouPS web interface or by calling
ing with the user’s IMAP server. Table 3 lists some example
methods to change the mode programmatically. Users can
methods of YouPS. Given the importance of context in our
view execution logs and rule output in a console window
prior probes, we provided access to their inbox’s status and
below the editor as seen in Figure 2.
interaction histories with specific contacts (internal context)
Each YouPS method prints logs when it is executed, and
and modes that let users indicate and leverage a variety of
users can also choose to print logs using Python’s native
external contexts.
print methods. Before actually running their rules over
Design of YouPS. YouPS provides an editor for writing so- their inbox, users can test out their rules by telling YouPS to
called filter rules for incoming emails. Each rule is triggered print out all logs from a user’s rules but not actually execute
only when there is a new email at the user’s inbox. Users can the action. Users can also enable and disable different email
add multiple editor tabs, each corresponding to a separate rules. If an error occurs while processing a user’s rules, YouPS
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK S. Park et al.

notifies users by sending them email and logging the error Email modes. During the deployment, 24 unique modes
to the interface. were created by the participants. One user said that he didn’t
use standard filters in email clients because he couldn’t ac-
Deployment. We recruited 12 email users (3 females, 9 males,
tivate them only for particular periods. In comparison, he
mean age=23.5) through a university lab mailing list and
found YouPS email modes useful for temporarily activat-
word-of-mouth. Participants were undergraduate or gradu-
ing rules. Another user described the modes they created in
ate students studying fields in engineering who could pro-
YouPS as: “I have a research mode (active from 9am-5pm) and
gram in Python. We introduced participants to YouPS and
sleep mode (active from 11pm to 8am). In my research mode, I
had them link their email to the system and author scripts
mark all emails as read and move them to the TODO label. I do
for their inbox. Over the course of the week, they could re-
this so that I don’t notice my new emails right away...and I can
turn to the interface to edit, debug, or create new scripts.
go through the new emails in my TODO folder periodically.”
After the deployment, we had a one-on-one interview with
One participant wrote a script to programmatically change
each participant. Participants were compensated $35 for their
their mode to “concentration mode” after the arrival of an
time.
important email:
Results 1 urgentWords = [" important ", " deadline "]
2 for w in urgentWords :
We present our analysis of rules made by participants as well
3 if w in g e t _ s u b j e c t (). lower ()
as themes from the interviews, where users described their
4 or w in g e t _ c o n t e n t (). lower ():
experience writing, editing, and testing email rules over time.
5 move(" Important ")
Almost all the rules that participants wrote were comprised
6 set_mode (" Concentration ")
of chained conditionals. Participants wrote 4.8 if conditions
on average per script. The conditions involved the subject Example 3: Switch modes after receiving an email
line 60 times, the sender information 49 times, contents of Another user described how they could configure fine-
the email 41 times, and interaction history 25 times. Actions grained filters using email modes: “This [is] a way to write
performed on a condition included moving to a folder (40 in- auto-replies that will be sent to co-workers, but not to family
stances), marking as read (22), labeling (6), programmatically members, when going on vacation...Or, to snooze work-related
switching a mode (6), and deleting a message (3). email during the evening, but still allow family-related email...”
Of the YouPS rules that our users created, we found that
40.4% could not be expressed using common email clients Leveraging interaction history. Echoing our survey re-
today, while the rest were common capabilities (e.g., filtering sults, users incorporated interaction history to triage emails.
by keyword or sender). Below is an example of a script trig- Prior interactions implied that the email they were receiving
gered by a sender and email body that performs the action from a person was likely to be important. One user said:
of moving to a folder. It is possible to do this using email “If I’ve talked to someone via email, then their later messages
filter tools today. are important to me”, while another said: “You have different
interaction periods with a person and those lead to different
1 auto_read_sender = [" LevelUp ", " Twitter "..]
priorities.”. Conversely, users could automatically disregard
2 if g e t _ s e n d e r () in auto_read_sender
messages from certain senders if there were too many mes-
3 or auto_read_sender in g e t _ c o n t e n t ():
sages within a short time period:
4 mark_read( True )
1 interaction = g e t _ h i s t o r y ( g e t _ s e n d e r ())
Example 1: Mark as read a message depending on a 2 if interaction [ ' received_emails '] > 5
sender and email body 3 and g e t _ s e n d e r () in mailing_list :
4 mark_read( True )
However, other scripts had more complicated conditions.
For instance, similar to our survey, we saw rules that per- Example 4: Disregard if too many emails within
formed actions only during certain time periods: short time
1 hour = datetime . now (). hour
(Non-)use of existing email client features. From inter-
2 if hour in range (12 ,14)
views, we found that many users still manually process
3 and " free food " in g e t _ s u b j e c t ():
emails, even repetitive ones, despite the fact that current
4 d e l e t e ()
features within email clients can automate some of this ac-
Example 2: Remove irrelevant emails during a cer- tivity. Similarly, during the deployment, more than half the
tain time range rules written by participants could have been done already
in their current client. We asked users why they didn’t use
Opportunities for Automating Email Processing: A Need-Finding Study CHI 2019, May 4–9, 2019, Glasgow, Scotland UK

features in their current interface. Some participants said Linking inboxes to other applications. We repeatedly
that it was difficult to write proper rules: “I’d select the option encountered a desire to leverage internal and external con-
to take emails from a certain address & marking them as read, text. Breaking with current email clients, this requires un-
but it didn’t always work.” This suggests that we need better derstanding users’ inboxes beyond a single message and
ways to debug and test automations. even further, beyond information stored within the inbox.
One surprise from YouPS was that many of our subjects Some of this context could be inferred rather than explicit,
(10 out of 12) preferred writing rules in Python to using their such as using number of unresponded emails or average
mail clients’ rule-authoring interfaces. One said the reason response time to estimate a user’s current load. However,
they didn’t like email interfaces for rule authoring is that context could also be determined explicitly, given the ability
they are cumbersome: “Adding a new one often takes a lot of to link to other applications like calendars. As another exam-
clicks and typing, even when there is an obvious pattern.” In ple, some participants wanted to incorporate context such
contrast, a second said “(YouPS is) so much lower friction. I as current geolocation from their phone. This suggests that
can copy-paste rules or even produce similar rules in a loop, email systems should make it easier for users to leverage
and use familiar programming concepts to combine their logic data from other applications when generating rules.
or make exceptions.” We also saw a need for complex content processing and
Clearly, a programming language offers more flexibility interfacing with other applications, including use of email
than typical interfaces, but YouPS hides the complexity of as middleware for other activities or to archive information
talking to an IMAP server, so it may offer an attractive sweet- to other places. Existing tools for task automation [26, 37]
spot on the simplicity versus power tradeoff; this requires demonstrate one way to make it easier for email systems to
further investigation. interface with other systems, though some of these features
may have greater adoption if integrated into email clients
themselves.
6 DISCUSSION
Features from other social platforms. We found that email
Our findings demonstrate that users would like more au-
users wanted to incorporate features that are common on
tomation in their email management. The three distinct need-
other social platforms. Indeed, prior work has pointed to
finding probes we carried out consistently identified certain
ways that email usage, for instance within mailing lists, and
common categories of email needs: capturing richer data
social media usage, for instance on Facebook Groups, have
models and internal and (time-varying) external context, us-
become more similar [58]. This suggests additional ways
ing them for recipients to manage attention and for senders to
that email systems could be adapted to suit how people
reduce load on recipients, and automated content processing
conduct online discussion today. For instance, senders said
to, for example, aggregate replies to an invitation or extract
they wanted to be more aware of their recipients, such as
attached photos into a relevant storage location.
whether they were online or busy [41]. Users wanted more
lightweight and casual ways of interacting as well as push
Hacks that overload existing email features. As a way notifications for certain content, blurring the lines between
to manage attention, we noticed users coming up with hacks chat systems like Slack and email [59]. Users also wanted
that repurpose existing email functionalities. For instance, richer data models for their contacts in order to target mes-
several probes saw users marking emails unread as a way sages, much like the user profiles that social media sites keep
to remind themselves to revisit those emails. Several scripts today. Finally, participants mentioned wanting community
from Probe 2 and 3 also tried to develop customized notifica- Q&A features like designating contacts to respond to a query,
tions by marking incoming emails as read and moving them following or unfollowing threads, and the “average time to
to different folders to suppress the default notification. respond” metric available in tools like Piazza. They said see-
This kind of overloading of existing features suggests that ing information about their own responsiveness would help
email systems could provide a richer data model for email increase productivity; we saw examples of this in Probe 2.
users to manage attention. Is binary marking (e.g. marking as
Customizing inbox presentation. Email has a broad spec-
read/unread or starred) enough to imply different intensities
trum of users from various backgrounds and contexts. A fixed
of attention? Is labeling messages with priority effective
interface for an email client cannot meet the diverse needs
given the eventual need for updates? One survey respondent
of email users. We noticed a desire to customize email in-
said she often forgot to update her ‘todo’ labels, ending up
terfaces in all three probes. This ranged from sorting emails
with too many labels after a while. This suggests we need
in other than chronological order, highlighting important
more dynamic or automated ways to mark emails, including
emails, and hiding some emails depending on time. Probes 1
ways to signal different and intersecting forms of priority.
and 2 also identified more structural changes to email clients,
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK S. Park et al.

permitting alternative ways of viewing threads or messages. why more generally-accessible solutions do not exist, forcing
Since changing the interface requires manipulating users’ programmers to write one-off scripts. YouPS aims to lower
email client, we need to further investigate ways to allow the bar for this.
email users to customize their interface.
8 FUTURE WORK
7 LIMITATIONS Our preliminary deployment of YouPS yielded evidence that
Two of our three studies explicitly focused on programmers our extended email vocabulary is suitable for scripting the
due to the lack of existing non-programmer tools for automat- rules users want. But we need a larger-scale deployment
ing email, while the other skewed towards engineers due to to gain confidence in this evidence. By deploying YouPS
our sampled population. This raises questions of external to more users over a larger duration, we hope to inspire
validity. However, the needs we identified did not make ref- participants to be more ambitious in their automations. Users’
erence to any programming-specific topics, and were similar descriptions of things they would like to do with YouPS
between programmers and non-programmers. but cannot will reveal gaps in our vocabulary and ways to
So far, we have developed YouPS as a system for program- fill them. As the rules written in YouPS become large and
mers. Its successful deployment validated our initial vocabu- complicated, we will look for common patterns in those rules
lary of actions and data model drawn from our first probe, capture them in new vocabulary that makes it possible to
demonstrating that users’ desired rules were easily and con- simplify those rules. We will also seek insight from prior
cisely described using this richer vocabulary. This offers the tools for end-user programming [7, 31].
hope that new graphical interfaces (and machine learning At the same time, we aim to extend the email automation
tools) leveraging this richer vocabulary could permit even capabilities of YouPS to non-programmers by creating GUIs
non-programmers to create their own email automations. for expressing rules that use the broader vocabulary. For
Because the questions in our survey were influenced by initial guidance we can look to existing email clients’ inter-
the design workshop, the survey responses may have been faces that permit non-programmers to create filters; these
artificially steered to match the design workshop. At a mini- interfaces generally offer drop down menus of attributes
mum, however, the survey did reveal that many users shared and constraints that can be applied in filtering. We believe
the needs of those in the design workshop, even if we failed such an interface could be augmented with the new concepts
to identify some other needs. YouPS exposes a generic and identified in the work presented here. We will also consider
obvious set of actions such as metadata access and email alternatives, e.g., block programming but with support for
foldering; our subjects were not specifically constrained to reusing and remixing email rules [43], in a way that is usable
address the same categories of needs as those found in the for non-programmers.
other studies, but they did so.
Although our studies revealed many needs that cannot be 9 CONCLUSION
met by current clients, we cannot conclude what numerical We conducted a series of need-finding probes regarding email
proportion of needs are not being met. It is possible that users automation. First, we led a design workshop to identify cate-
primarily focused on unmet needs, artificially amplifying gories of email needs, followed by a larger survey to deepen
that portion; alternatively, it is possible that familiarity with our understanding of the needs we identified. We performed
existing capabilities led users to focus more on needs that a second probe by mining open source code on Github to see
could already be met. But regardless of the proportion, we what needs have already been enacted by programmers. Fi-
believe we have identified a number of interesting categories nally, we conducted a deployment of a programmable email
of needs that are not currently addressed. system YouPS which enables users to write custom email
Probe 2 identified scripts where programmers wrote code rules through a simple programmatic API wrapper of IMAP,
to address needs. One could therefore argue that these needs as well as a study of users’ interaction with the system over
have been met by the extant code. However, of the 499 scripts, the course of a week. We found limitations in the implemen-
only 12 provided pre-packaged applications (e.g. browser ex- tation of current email clients that do not satisfy the complex
tension or desktop application) that could be used in turnkey desires of email users. The needs discovered in our studies
fashion by non-programmers. The remainder were either will guide future designers and developers of email clients
code libraries or scripts that other programmers would need and inbox management systems.
to configure for their own environments by editing the source.
It seems unlikely that exactly one person needed each script’s 10 ACKNOWLEDGMENTS
solution, but the average number of non-author “watchers” We thank our participants and reviewers, particularly our
of a project was 1.3, suggesting most of the projects are one- shepherd for their help improving the paper’s structure. Soya
off and not widely used. Thus, it is still important to consider Park is partly supported by the Kwanjeong fellowship.
Opportunities for Automating Email Processing: A Need-Finding Study CHI 2019, May 4–9, 2019, Glasgow, Scotland UK

REFERENCES [16] Mark Dredze, Bill N. Schilit, and Peter Norvig. 2009. Suggesting Email
[1] Foundry 376. 2017. Mailspring. https://getmailspring.com. View Filters for Triage and Search. In Proceedings of the Twenty-First In-
[2] Gediminas Adomavicius and Alexander Tuzhilin. 2011. Context-Aware ternational Joint Conference on Artificial Intelligence (IJCAI ’09). AAAI,
Recommender Systems. Springer US, Boston, MA, 217–253. https: Palo Alto, CA, USA, 1414–1419. https://www.aaai.org/ocs/index.php/
//doi.org/10.1007/978-0-387-85820-3_7 IJCAI/IJCAI-09/paper/viewFile/488/909
[3] Tarfah Alrashed, Ahmed Hassan Awadallah, and Susan Dumais. 2018. [17] Mark Dredze, Hanna M. Wallach, Danny Puller, and Fernando Pereira.
The Lifetime of Email Messages: A Large-Scale Analysis of Email Re- 2008. Automatically classifying emails into activities. In Proceedings
visitation. In Proceedings of the 2018 Conference on Human Information of the 13th international conference on Intelligent user interfaces (IUI
Interaction&Retrieval (CHIIR ’18). ACM, New York, NY, USA, 120–129. ’08). ACM, New York, NY, USA, 199–206. http://doi.acm.org/10.1145/
https://doi.org/10.1145/3176349.3176398 1378773.1378800
[4] Victoria Bellotti, Nicolas Ducheneaut, Mark Howard, and Ian Smith. [18] Mozilla Foundation. 2004. Mozilla Thunderbird. https://www.
2003. Taking email to task: the design and evaluation of a task man- thunderbird.net/.
agement centered email tool. In Proceedings of the SIGCHI Conference [19] Google. 2014. Google Inbox. https://inbox.google.com/.
on Human Factors in Computing Systems (CHI ’03). ACM, New York, [20] Sukeshini A. Grandhi and Lyndsey K. Lanagan-Leitzel. 2016. To
NY, USA, 345–352. https://doi.org/10.1145/642611.642672 Reply or To Reply All: Understanding Replying Behavior in Group
[5] Frank Bentley, Nediyana Daskalova, and Nazanin Andalibi. 2017. If a Email Communication. In Proceedings of the 2016 ACM conference on
person is emailing you, it just doesn’t make sense: Exploring Changing Computer-supported cooperative work. (CSCW ’16). ACM, New York,
Consumer Behaviors in Email. In Proceedings of the SIGCHI Conference NY, USA, 560–569. https://doi.org/10.1145/2818048.2819981
on Human Factors in Computing Systems (CHI ’17). ACM, New York, [21] Catherine Grevet, David Choi, Debra Kumar, and Eric Gilbert. 2014.
NY, USA, 85–95. https://doi.org/10.1145/3025453.3025613 Overload is overloaded: email in the age of Gmail. In Proceedings of
[6] Christian Bird, Alex Gourley, Prem Devanbu, Michael Gertz, and the SIGCHI Conference on Human Factors in Computing Systems (CHI
Anand Swaminathan. 2006. Mining email social networks. In Proceed- ’14). 793–802. https://doi.org/10.1145/2556288.2557013
ings of the 2006 international workshop on Mining software repositories [22] Daniel Gruen, Steven L. Rohall, Suzanne Minassian, Bernard Kerr,
(MSR ’06). ACM, New York, NY, USA, 137–143. https://doi.org/10. Paul Moody, Bob Stachel, Martin Wattenberg, and Eric Wilcox. 2004.
1145/1137983.1138016 Lessons from the reMail prototypes. In Proceedings of the 2004 ACM
[7] Michael Bolin, Matthew Webber, Philip Rha, Tom Wilson, and Robert C. conference on Computer supported cooperative work (CSCW ’04). ACM,
Miller. 2005. Automation and customization of rendered web pages. New York, NY, USA, 152–161. http://doi.acm.org/10.1145/1031607.
In Proceedings of the 13th international conference on Intelligent user 1031634
interfaces (IUI ’05). ACM, New York, NY, USA, 163–172. http://doi. [23] Philip A. Guenther. 1990. procmail. https://linux.die.net/man/1/
acm.org/10.1145/1095034.1095062 procmail.
[8] boomerang. 2016. boomerang. http://www.boomeranggmail.com. [24] William C. Hill, James D. Hollan, Dave Wroblewski, and Tim McCan-
[9] Nathanial S. Borenstein. 1992. Computational mail as network in- dless. 1992. Edit wear and read wear. In Proceedings of the SIGCHI
frastructure for computer-supported cooperative work. In Proceed- Conference on Human Factors in Computing Systems (CHI ’92). ACM,
ings of the 1992 ACM conference on Computer-supported coopera- New York, NY, USA, 3–9. https://doi.org/10.1145/142750.142751
tive work. (CSCW ’92). ACM, New York, NY, USA, 67–74. https: [25] Edward Hung. 2001. Deduction of Procmail Recipes from Classified
//doi.org/10.1145/143457.143463 Emails. CMSC724 Database Management Systems, individual research
[10] Horatiu Bota, Paul N. Bennett, Ahmed Hassan Awadallah, and Susan T. project report (2001).
Dumais. 2017. Self-Es: the role of emails-to-self in personal informa- [26] IFTTT. 2010. IFTTT Gmail. https://ifttt.com/gmail.
tion management. In Proceedings of the 2017 Conference on Human [27] GrexIt Inc. 2011. hiver. https://hiverhq.com.
Information Interaction&Retrieval (CHIIR ’17). ACM, New York, NY, [28] Anjuli Kannan, Karol Kurach, Sujith Ravi, Tobias Kaufmann, Andrew
USA, 205–214. https://doi.org/10.1145/3020165.3020189 Tomkins, Balint Miklos, Greg Corrado, Laszlo Lukacs, Marina Ganea,
[11] Mary Czerwinski, Eric Horvitz, and Susan Wilhite. 2004. A diary Peter Young, et al. 2016. Smart reply: Automated response sugges-
study of task switching and interruptions. In Proceedings of the SIGCHI tion for email. In Proceedings of the 22nd ACM SIGKDD International
conference on Human factors in computing systems (CHI ’04). ACM, New Conference on Knowledge Discovery and Data Mining (KDD ’16). ACM,
York, NY, USA, 175–182. http://doi.acm.org/10.1145/985692.985715 New York, NY, USA, 955–964.
[12] Laura A. Dabbish, Robert E. Kraut, Susan Fussell, and Sara Kiesler. [29] Shih-Wen Ke, Chris Bowerman, and Michael Oakes. 2006. Perc: A
2005. Understanding email use: predicting action on a message. In personal email classifier. European Conference on Information Retrieval
Proceedings of the SIGCHI Conference on Human Factors in Computing (2006), 460–463. https://doi.org/10.1007/11735106_41
Systems (CHI ’05). ACM, New York, NY, USA, 691–700. http://doi.acm. [30] Nicolas Kokkalis, Johannes Roith Chengdiao Fan, Michael S. Bernstein,
org/10.1145/1054972.1055068 and Scott Klemmer. 2017. MyriadHub: Efficiently Scaling Personalized
[13] Senad Dizdar. 2011. CloudHQ. https://linux.die.net/man/1/procmail. Email Conversations with Valet Crowdsourcing. In Proceedings of the
[14] Marian Dork, Daniel Gruen, Carey Williamson, and Sheelagh Carpen- SIGCHI Conference on Human Factors in Computing Systems (CHI ’17).
dale. 2010. A visual backchannel for large-scale events. In IEEE trans- ACM, New York, NY, USA, 73–84. https://doi.org/10.1145/3025453.
actions on visualization and computer graphics (Vis ’10), Vol. 16. IEEE, 3025954
1129–1138. [31] Gilly Leshed, Eben M. Haber, Tara Matthews, and Tessa Lau. 2008.
[15] Mark Dredze, Tessa Lau, and Nicholas Kushmerick. 2006. Automati- CoScripter: automating & sharing how-to knowledge in the enterprise.
cally classifying emails into activities. In Proceedings of the 11th inter- In Proceedings of the SIGCHI Conference on Human Factors in Computing
national conference on Intelligent user interfaces (IUI ’06). ACM, New Systems (CHI ’08). ACM, New York, NY, USA, 1719–1728. http://doi.
York, NY, USA, 70–77. http://doi.acm.org/10.1145/1111449.1111471 acm.org/10.1145/1357054.1357323
[32] Wendy E Mackay. 1998. More than just a communication system:
diversity in the use of electronic mail. In Proceedings of the 1998 ACM
conference on Computer supported cooperative work (CSCW ’98). ACM,
CHI 2019, May 4–9, 2019, Glasgow, Scotland UK S. Park et al.

New York, NY, USA, 344–353. http://doi.acm.org/10.1145/62266.62293 Proceedings of the 30th Annual ACM Symposium on User Interface Soft-
[33] Kaitlin Mahar, Amy X Zhang, and David Karger. 2018. Squadbox: A ware and Technology (UIST ’17). ACM, New York, NY, USA, 807–815.
Tool to Combat Email Harassment Using Friendsourced Moderation. In https://doi.org/10.1145/3126594.3126603
Proceedings of the 2018 CHI Conference on Human Factors in Computing [50] Agnieszka Matysiak Szóstek. 2011. ’Dealing with My Emails’: Latent
Systems. ACM, 586–599. user needs in email management. Computers in Human Behavior 27, 2
[34] Mailbird. 2013. Mailbird. https://www.getmailbird.com. (2011), 723–729. https://doi.org/10.1016/j.chb.2010.09.019
[35] Gloria Mark, Shamsi T. Iqbal, Mary Czerwinski, Paul Johns, Akane [51] Jaime Teevan, Christine Alvarado, Mark S. Ackerman, and David R.
Sano, and Yuliya Lutchyn. 2016. Email duration, batching and self- Karger. 2004. The perfect search engine is not enough: a study of
interruption: Patterns of email use on productivity and stress. In Pro- orienteering behavior in directed search. In Proceedings of the SIGCHI
ceedings of the SIGCHI Conference on Human Factors in Computing Conference on Human Factors in Computing Systems (CHI ’04). ACM,
Systems (CHI ’16). ACM, New York, NY, USA, 1717–1728. https: New York, NY, USA, 415–422. https://doi.org/10.1145/985692.985745
//doi.org/10.1145/2858036.2858262 [52] Joshua R Tyler and John C Tang. 2003. When can I expect an email
[36] Luke McDowell, Oren Etzioni, Alon Halevy, and Henry Levy. 2004. response? A study of rhythms in email usage. In ECSCW 2003. Springer,
Semantic email. In Proceedings of the 13th international conference on 239–258.
World Wide Web (WWW ’04). ACM, New York, NY, USA, 244–254. [53] Stephen Voida, Elizabeth D. Mynatt, Blair MacIntyre, and Gregory M.
https://doi.org/10.1145/988672.988706 Corso. 2002. Integrating virtual and physical context to support knowl-
[37] Microsoft. 2018. Microsoft Flow. https://flow.microsoft.com/en-us/. edge workers. IEEE Pervasive Computing 1 (2002), 73–79.
[38] Michael Muller and Daniel Gruen. 2002. Collaborating within not [54] Martin Wattenberg, Steven L. Rohall, Daniel Gruen, and Bernard
through email: Users reinvent a familiar technology. Kerr. 2005. E-mail research: Targeting the enterprise. Human-
[39] Michael J. Muller and Daniel M. Gruen. 2005. Working together in- Computer Interaction 20, 2 (2005), 139–162. https://doi.org/10.1207/
side an emailbox. In Proceedings ECSCW 2005 (ECSCW ’05). Springer, s15327051hci2001&2_5
Dordrecht, 103–122. https://doi.org/10.1007/1-4020-4023-7_6 [55] Steve Whittaker, Victoria Bellotti, and Jacek Gwizdka. 2006. Email in
[40] Kanika Narang, Susan T. Dumais, Nick Craswell, Dan Liebling, and personal information management. Commun. ACM 49, 1 (2006), 68–73.
Qingyao Ai. 2017. Large-scale analysis of email search and organi- https://doi.org/10.1145/1107458.1107494
zational strategies. In Proceedings of the 2017 Conference on Human [56] Steve Whittaker and Candace Sidner. 1996. Email overload: explor-
Information Interaction&Retrieval (CHIIR ’17). ACM, New York, NY, ing personal information management of email. In Proceedings of the
USA, 215–223. https://doi.org/10.1145/3020165.3020175 SIGCHI Conference on Human Factors in Computing Systems. 793–802.
[41] Bonnie A. Nardi, Steve Whittaker, and Erin Bradner. 2000. Interaction https://doi.org/10.1145/238386.238530
and Outeraction: Instant Messaging in Action. In Proceedings of the [57] Shinjae Yoo, Yiming Yang, and Jaime Carbonell. 2011. Modeling person-
2000 ACM conference on Computer supported cooperative work (CSCW alized email prioritization: classification-based and regression-based
’00). ACM, New York, NY, USA, 79–88. http://doi.acm.org/10.1145/ approaches. In Proceedings of the 20th ACM international conference on
358916.358975 Information and knowledge management (CIKM ’11). ACM, New York,
[42] Carman Neustaedter, A J. Bernheim Brush, Marc Smith, and Danyel NY, USA, 729–738. https://doi.org/10.1145/2063576.2063683
Fisher. 2005. The Social Network and Relationship Finder: Social [58] Amy X. Zhang, Mark S. Ackerman, and David R. Karger. 2015. Mailing
Sorting for Email Triage. Proceedings of the 2005 Conference on Email Lists: Why Are They Still Here, What’s Wrong With Them, and How
and Anti-Spam (CEAS). Can We Fix Them?. In Proceedings of the SIGCHI Conference on Human
[43] Stephen Oney, Brad Myers, and Joel Brandt. 2014. InterState: a lan- Factors in Computing Systems (CHI ’15). ACM, New York, NY, USA,
guage and environment for expressing interface behavior. In Pro- 4009–4018. https://doi.org/10.1145/2702123.2702194
ceedings of the 30th Annual ACM Symposium on User Interface Soft- [59] Amy X. Zhang and Justin Cranshaw. 2018. Making Sense of Group Chat
ware and Technology (UIST ’14). ACM, New York, NY, USA, 263–272. Through Collaborative Tagging and Summarization. In Proceedings
https://doi.org/10.1145/2642918.2647358 of the 2018 ACM conference on Computer supported cooperative work
[44] CMU Cyrus Project. 2008. sieve. http://sieve.info. (CSCW ’18). ACM, New York, NY, USA, 196–223. http://doi.acm.org/
[45] Steven L. Rohall, Daniel Gruen, Paul Moody, and Seymour Kellerman. 10.1145/3274465
2001. Email visualizations to aid communications. In Proceedings of [60] Qian Zhao, Paul Bennett, Adam Fourney, Anne Loomis Thompson,
InfoVis 2001 The IEEE Symposium on Information Visualization (InfoVis Shane Williams, Adam D. Troy, and Susan Dumais. 2018. Calendar-
’01). IEEE, 15. Aware Proactive Email Recommendation. In Proceedings of the 41st
[46] Abigail J Sellen, Rachel Murphy, and Kate L Shaw. 2002. How knowl- Annual International ACM SIGIR Conference on Research and Develop-
edge workers use the web. In Proceedings of the SIGCHI Conference on ment in Information Retrieval (SIGIR ’18). ACM, New York, NY, USA,
Human Factors in Computing System (CHI ’02). ACM, New York, NY, 655–664. http://doi.acm.org/10.1145/3209978.3210001
USA, 227–234. http://doi.acm.org/10.1145/503376.503418
[47] Nikash Singh, Martin Tomitsch, and Mary Lou Maher. 2006. Un-
derstanding the management and need for awareness of temporal
information in email. In Proceedings of the 2006 international workshop
on Mining software repositories (MSR ’06). ACM, New York, NY, USA,
137–143. https://doi.org/10.1145/1137983.1138016
[48] Anselm Strauss and Juliet M Corbin. 1990. Basics of qualitative research:
Grounded theory procedures and techniques. Sage Publications, Inc.
[49] Saiganesh Swaminathan, Raymond Fok, Fanglin Chen, Ting-Hao Ken-
neth Huang, Irene Lin, Rohan Jadvani, Walter S. Lasecki, and Jeffrey P.
Bigham. 2017. WearMail: On-the-Go Access to Information in Your
Email with a Privacy-Preserving Human Computation Workflow. In