Opportunities for Automating Email Processing: A Need-Finding Study

Approach. In this work, we sought to explore the breadth of needs that users have regarding automating their email experience, with the eventual goal of designing a useful, general purpose email automation system. We conducted this work through a series of three distinct need-finding probes as shown in Table 1. First, we aimed to gather from a broad audience of users wishful thinking ideas for automating email in their own inboxes. From a formative design workshop with 13 email users who were asked to brainstorm commands in natural language that they would like to execute, we developed a series of common categories of needs, including attention management and prioritization, filing and labeling, automated content processing, and rules based on contextual modes. These categories informed the design of a survey that we distributed to 77 additional people. The survey contained sections dedicated to each category with open-ended prompts asking for more ideas for automations users would like to perform.

Moving from users’ ideas regarding automation, we next sought to identify the ways in which users were already automating aspects of their email to see which needs have been addressed. As automation capabilities available to end users in many email clients are limited, we instead examined automations implemented by programmers, who have greater ability to carry out their desires for personalized automation. We conducted this probe by mining public repositories on Github that make use of the IMAP (Internet Message Access Protocol) API. From around 500 scripts, we developed a taxonomy of 8 types of automated email processing tools.

Even for programmers, writing a standalone mail automation program is a substantial task. This could deter many automations from ever being created. Therefore, informed by these two probes, we developed a platform called YouPS that makes it possible for users to write, test, debug, save, and continually execute simple Python scripts that can manipulate emails arriving in their inbox. YouPS exposes a small set of Python functions for basic actions such as accessing an email field or moving an email to a particular folder, hiding all the complexity of turning these function calls into invocations of the IMAP API to manipulate the users’ email on their server. This platform served as a probe into what kinds of scripts email users would write given the opportunity to easily test and run them over their own email. We invited 12 subjects to write and execute scripts on YouPS for a week; we then examined their scripts and interviewed them about their experiences.

Results. Our design workshop identified several common categories of needs in email automation, which were elucidated through our later studies. The first was a richer data model for an email to capture latent structured information such as priority, topic, deadline, and need for a reply. The next was automation leveraging the context of an email, both within and beyond the email inbox. Some examples include the time of day, characteristics of the email thread (e.g., previous replies by a recipient, number or rate of responses by others), and the state of the recipient (e.g., busy, sleeping, in the office, on vacation). These attributes and contextual information are needed to drive automations that help recipients with attention management of email through the configuration of different forms of notifications and presentations of messages. In an interesting inversion, we also found that senders wanted to leverage rich data and context to reduce load on recipients, for example by automatically delaying an email from being sent until the recipient is in a not-busy context or at a suitable location. Finally, users sought automated content processing, for example to aggregate replies to an invitation or to extract attached photos into a relevant storage location.

From these findings, we consider how email systems could better allow users to automate and customize email handling. We found that many users’ needs required information and affordances that are not currently available in email systems. From our three studies, 47%, 90%, and 40% respectively could not be expressed using common email clients today, for instance with Gmail and Outlook tools for writing filter rules. Thus, meeting those needs requires new features within email systems, such as expanding email's data model to add latent structure, as well as incorporating more context. In addition, systems need new mechanisms for users to be able to express how they want emails to be presented and processed.

On the other hand, we also found that over half of the automation examples from the survey and the deployment of YouPS could already be implemented in today's email systems, as shown in Table 1. However, some implementations are not straightforward, involving hacks that repurpose existing email features like the read/unread signal. This lack of usage coupled with workarounds using existing features suggest that email users are not satisfied with existing tools for automation in current email interfaces. We touch on future work towards designing interfaces for general purpose email automation authoring.

Organizing Email. While there has been substantial research on email users, much of it has focused on organization and retrieval needs rather than automation needs. Email users view email as a repository for personal information management (PIM) [55], where they have different strategies for retrieving information [3, 40, 47, 49, 51]. For instance, users frequently send emails to themselves as a way to store information [10]. Szóstek et al. [50] identified six needs for information organization: email annotation, reliable structure, prioritizing emails, informative overview, flexible sorting, and efficient search. Finally, others study usage beyond PIM, including shared inboxes jointly accessed by a team [39]. Our research builds upon this work by identifying additional needs as well as considering how systems could address such needs, given that current email clients do not fully address them.

Systems for Triaging Messages. When it comes to existing automations, automatic classification is one that is widely offered in email clients. Many email clients automatically classify and prioritize emails using machine learning techniques [25, 29, 57]. Beyond spam classification, clients like Gmail offer additional classifications by default such as “Social” or “Promotions”. However, users may wish to classify their emails in a different or more fine-grained manner than the default classes email clients provide. So many clients provide simple explicit rule-authoring interfaces for end-users and programmers [23, 44]; for example, users can specify rules for placing messages in folders.

While most existing filter interfaces are focused on explicit metadata within messages, other ways of classification and sorting of messages have been proposed [15, 42, 50]. For instance, research has found that email users tend to see messages as tasks and have a desire to conceptualize email as a task management tool [4, 13, 27]. In this work, we provide empirical examples of the kinds of alternative classifications, prioritizations, and actions following from these that email users would like, in order to guide the design of future systems. We also demonstrate how desired classifications and priorities can be time-varying based on the user's state.

Automation for Recipients & Senders. Email users are both senders and recipients, and systems provide automation capabilities addressing both roles. For instance, email clients provide two types of reminders. Email users can set a reminder for messages to get back to it later (reminder as a recipient) and remind their recipients to solicit responses (reminder as a sender) [1, 8, 18, 19, 34]. There are also platforms that allow users to write simple triggers and actions to integrate with different applications [26, 37].

As recipients, users want to easily draft responses [28], automatically adjust views for different email data [16], and organize cluttered messages [17]. Email users also want to aggregate replies to manage bulk emails [30] and automatically process responses using pre-defined queries [36]. Senders on the other hand would like to hint to their recipients how to respond [20]. Borenstein et al. [9] suggested Tcl language-enabled email to deliver executable contents (e.g., a prompt window) to recipients. In this work, we draw from and build upon this prior work to explore the general space of email automation for both email recipients and senders.

Formative Design Workshop. We conducted a design workshop with 13 participants (10 females, 3 males). Subjects were all computer science students with knowledge of programming. We asked them to use natural language or pseudocode to write email rules that they would like to execute on their inbox as either senders or receivers of email, invoking any methods or objects that they could imagine existing. Over the course of 45 minutes, participants came up with 42 different rules. Afterwards, the authors as a group analyzed the rules that participants generated and identified five major categories of needs.

Survey. Based on the needs identified from the design workshop, we designed a survey to explore each category of needs in more depth. We asked open-ended questions about how the user would like to automate their email. To prompt users to think outside the realm of what is currently possible but also be explicit in their descriptions, we told participants to imagine using a smart robot that can organize their email and change how it is presented to them. The questions offered rules drawn from the workshop as examples. The survey was structured into eight randomly ordered sections based on the needs identified in the workshop:

• Triaging and prioritizing incoming emails
  
• Moving incoming emails to different locations
  
• Labeling emails with richer data as sender or receiver
  
• Sending email only at a particular time or context
  
• Sending email to only the right people
  
• Different email modes that can be toggled (vacation, etc.)
  
• Altering the presentation of emails in the inbox
  
• Aggregating or processing multiple emails or email replies
  

The survey was distributed through various mailing lists within a private university and by word of mouth. It was taken by 77 people (31 females, 41 males, 1 other, rest unanswered). The median age range was 20–29. While most of our respondents were affiliated with the university, 34.5% of our respondents were not students or faculty. In addition, 48% of respondents did not have technical backgrounds, instead working as administrative staff or as students in non-technical majors. All of our participants fall into the general category of “knowledge workers”, an important category that has been the focus of much study [11, 46].

We used a grounded theory approach [48] to identify themes in the survey answers. Two authors individually open-coded the responses, then discussed them after the fact, merging similar codes and grouping codes into distinct themes. To validate the merged codes, we selected 10 survey participants at random, and the two authors independently re-labeled each of their survey responses using the merged codes. From the 90 responses that were coded, we found an inter-rater reliability (IRR) of 79% using Cohen's κ.

Richer Data Models. Many of the email rules that participants devised required access to latent information about the message that was not explicitly given in the email headers or in attributes of each message like sender or date. From the survey, we identified the following desired latent data: progress (e.g., pending, done), deadline, topic, priority, task. Users desired automatic annotation of messages with these latent attributes that could be used to drive rules. For example, there were rules such as: “If the content of the message seems like it requires an action, label it as ‘pending’” and “If the email has a deadline, tag the deadline”.

Because prioritization was a commonly articulated need in the workshop, in the survey we asked users to describe attributes that signal priority specifically. Respondents used information about the sender, assigning high priority for messages from important contacts and lowering the priority of automated or blast emails. Respondents also wanted to prioritize by the number of follow-up tasks, so a message requiring no action (e.g., an FYI) would have a lower priority. Finally, 14% of users wanted to take into account their previous interactions with a person or organization when prioritizing an email. For example, some respondents wanted to have emails marked as high priority if they had sent responses to the last several emails from the same sender and low priority if they had not opened or sent a response.

Using Internal/External Context. While some attributes of an email such as deadline can be determined by examining the message in question, others require access to a broader context [2, 53] around the message. This includes both internal context involving other messages within the inbox of the sender or receiver generally, as well as external context [60] regarding the state of the user and the world (which is often time-varying). For example, the rule “Send a message if I haven't touched base for a month” requires interaction history with the recipient of the message (internal context), as mentioned in the prior category. Another state that was often referenced was whether a recipient had replied to the original message: “If the recipient hasn't replied for n days, send them a reminder”.

In contrast, “Don't notify emails from these campus mailing lists during my summer vacation” requires external context that involves determining whether the arrival time of an email is during a user's summer vacation. The external context may also change more frequently, for instance when one respondent said: “I don't think priority is a consistent definition. For 30-40 hours per week, my research, colleagues, advisors are high on my priorities. However, outside of that time, my priorities shift around a little: my side project becomes my focus...one idea is to have these incoming messages reflect this ebb and flow of priorities.” Motivated by several rules during the workshop referencing different external contexts, we asked survey participants to come up with email modes that could trigger different behavior in their inbox. Respondents thought of many types of modes:

conference, work, vacation, home/family, busy, study, distraction, class, important, person, block/harassment, waiting, application, sleep, weekend, evening, summer, semester, daytime, emotion, recreation, meeting, ignore

Each of these modes came with distinct rules for behavior. For example, a user's conference mode had a rule that highlighted only conference-related emails (e.g., meet-ups, announcements). The emotion mode came from a user who proposed having different modes that would kick in depending on their mood, such as when they felt anxious or tired.

Attention Management. Many users’ needs for richer data models and context related to the end goal of managing attention as a recipient of email. Users described many ways to leverage these priorities to change the notification behavior or presentation of emails, including (automatically) marking them as read or unread, moving them to other less or more attended folders, hiding emails until a particular time, and bringing them to the top of the inbox or pushing them farther down. The way users repurposed interface affordances for attention management—for example, marking a read message as unread in order to make it stand out—raises the question of whether there might be other attention-getting techniques that would be a better fit.

How to configure push notifications also arose frequently, reflecting that email (once an asynchronous communication medium) has taken on some attributes of more synchronous communications such as instant messaging. Users overall did not want to be notified about every email, but did want to be immediately notified about certain prioritized emails [35]. Users considered a variety of push notification channels such as buzzing the phone and sending SMS messages. Other users came up with automatic rules to mark-as-read emails that should not trigger such notifications. Still others wanted to mute notifications entirely or receive digest notifications after they had accumulated for a while instead of for every email. Examples of notification rules users wrote include:

• Don't notify me about emails from these campus mailing lists during my summer vacation
  
• If this sender sends me too many emails within a short period, mute emails from the sender
  

Sender Affordances. While email research generally focuses on users reducing their own email workload, evidence shows that users care significantly about the impact their email sending has on others’ workloads, and seek ways to reduce that impact [58]. Some subjects asked for a reaction or upvote feature to signal that they saw a message without burdening the recipient with another response. As another example, senders wanted to be able to set emails to expire at a certain time or when other conditions were met: “For event announcement emails, self-destruct the emails from recipients’ inbox after the event”. Context regarding a recipient's availability or responsiveness [52] could also be used by a sender to decide when or how to send a message. Unfortunately, today, such context is often delivered to senders in a catchall fashion using auto-replies (e.g., out-of-office replies), which forces an extra message. For instance, one person wanted to send an automatic response to incoming emails if their inbox had surpassed a certain number of unread emails.

As an additional way to reduce load on recipients, senders wanted a way to target only the right recipient subset of a mailing list. In particular, in the workshop there was a high demand for querying particular groups of recipients (e.g., people I have exchanged email with more than three times, people who reside in a particular city, people in my address book). These queries typically required metadata from previous emails (internal context) or even from 3rd party applications such as a calendar (external context):

• If I reply to an email thread, send my reply only to those who expressed interest
  
• Send only to people in lab right now because I need a stapler
  

Recognizing that recipients may not always be paying attention to the group thread or mailing list, several users also wanted the tagging feature common in social media to signal importance to certain recipients.

Altering Inbox Presentation. In addition to the existing capabilities in email clients for managing presentation, such as moving, hiding, or sorting emails, we asked survey participants to consider potential new presentations of their inbox [14, 22, 54]. We found many interested in alternative views for email threading. Participants suggested different presentations such as a tree-like network visualization of replies per email thread, echoing prior work [45]. Participants also wanted to break up long messages, group together short messages, or group by different attributes like sender. One participant said: “In Slack, you can send individual sentences/thoughts one-by-one as you're typing a larger message, so it's easier to divide big thoughts into bite-sized chunks. I mean, who wants to send a one-line email?” Connected to message segmentation, another participant said she'd like to be able to reference or quote from prior emails so that recipients could follow the source.

Content Processing and Aggregation. Finally, we found many rules regarding complex processing of content within emails in order to make decisions about forwarding emails to other people [33] or extracting information to send to other platforms or store in other formats. For instance, several subjects said that they wanted to extract event information to store within a calendar application. Other examples include:

• If I forward this email to a certain email address, parse the content and add it as a note
  
• If a message contains attachments, add them to one of my cloud folders
  

Survey respondents additionally came up with ideas for response aggregation [30]. For example, when scheduling a meeting, attendees can either respond to everyone, or to the sender, but a sender cannot collectively aggregate responses into a poll. Respondents said they would like to see a summary of a group of responses rather than a series of different emails containing all of the original responses. Also, others mentioned interest in some sort of chart, calendar, or other aggregate visualization of responses. Besides the novel presentation required, this demands a richer data model for email to represent the data to be aggregated.

Method. On Github, we searched for code that made use of IMAP (Internet Message Access Protocol), the standard protocol for connecting to a user's mail-server account and accessing and manipulating email on it. We focused our search to code written in Python, which has a built in library called imaplib. We also included searches for two particularly popular wrapper libraries for imaplib called imappy and imapclient. To exclude the many artifacts that used IMAP simply to send application notifications, we also limited the search to repositories that included the term “email” in their README documentation.

From an initial 524 scripts, we excluded 25 that were code-example skeletons that had not been filled in, resulting in 499 scripts. The first author went through each script using an open-coding approach as in the survey to identify the main functions performed. Eight codes emerged, with each script labeled with one or more codes. To validate our codes, a second author used the identified categories to independently re-label a random sample of 30 scripts, achieving an inter-rater reliability of 64.9% using Cohen's κ.

Processing, organizing, and archiving content. Over a fifth of the scripts triggered some sort of action (e.g., send auto-responses, mark read, move to a folder) based on information parsed from an email. The most popular example was extracting part of an email and then replying with or sending the processed content to another user. Almost equally popular were scripts that exported content from the email system. Some scripts attempted to download message contents, particularly attachments (e.g. receipts, contact info), to places such as their desktop or the cloud.

Many of these scripts echoed the need for content processing and aggregation in Probe 1 to automate repetitive tasks. Many scripts also extracted latent structure from emails, reflecting the desire for richer data models. Overall, we found complex processing needs were prevalent, comprising around 50% of scripts. This may be because people who process large amounts of information via email were compelled 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. Echoing survey results on altering inbox presentation, a number of scripts focused on displaying email threads in a different way, mimicking applications like Slack or Facebook. We also found scripts with more minor tweaks to current email client presentations. For instance, there were scripts that displayed one's inbox not by email subject lines but rather by some metadata of the email content. Several scripts also aimed to personalize push notifications for new emails, similar to rules in Probe 1 regarding attention management. For example, one script interfaced with a Raspberry PI and displayed visual effects when an email arrived in the user's inbox.

Email as middleware. In a divergence from the survey, we found scripts that attempted to use the inbox as middleware, towards performing actions outside of a user's inbox. Given the accessible and ubiquitous nature of email, some scripts enable users to use email as a form of cloud storage. Others enable users to trigger defined actions via email, such as uploading pictures to an online library, or controlling software remotely through the use of keywords. This technique is relatively technical, so it is understandable that it didn't occur to our survey respondents as a possibility. Previous studies [38] have found similar uses, such as users using a folder to label emails that have to be printed.

Inbox cleaning and spam removal. We saw a number of scripts focused on inbox cleanup to remove unimportant or spam emails. Some scripts attempted to delete unimportant messages regularly so that users could focus their attention on important messages. For instance, we encountered scripts concerned with the “Inbox Zero” approach to email management. The goal of this approach is to achieve as close to zero messages in a user's inbox at any given time. These scripts offer similar functionality to the sweep rule feature in Outlook, which runs at regular intervals to delete emails based on a user's rules.

Some scripts were also focused on auto-removing spam emails. Unlike the survey respondents, programmers incorporated engineering techniques to automatically extract spam-related attributes of emails at a fine-grained level. Some of these scripts used machine learning libraries to train spam filters. It was unclear based on the scripts alone whether the programmers were attempting to replace current spam filter functionality in common email clients, or whether they were simply trying to implement basic machine learning models. Spam was not mentioned as frequently in Probe 1, possibly because users were satisfied with their existing spam filters.

Email analytics and productivity tools. Finally, we observed instances of the reflective conversation [24] when it came to tasks within emails, such as scripts that collected 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 measure of productivity week-to-week. This category was not mentioned as often in Probe 1, again possibly due to an over-representation of users in Probe 2 who have more intense workloads within email, or due to a correlation between programming skills and an interest in visualizing data about or optimizing one's own activities (i.e., the “quantified self”).

Design of YouPS. YouPS provides an editor for writing so-called filter rules for incoming emails. Each rule is triggered only when there is a new email at the user's inbox. Users can add multiple editor tabs, each corresponding to a separate email mode. Users can write different rules for each mode so that their inbox behaves differently depending on the current mode. User can set their active email mode using a dropdown menu on the YouPS web interface or by calling methods to change the mode programmatically. Users can view execution logs and rule output in a console window below the editor as seen in Figure 2.

Figure 1: The YouPS interface. Users can program and debug their email rules with interactive editors and a console.

Figure 2: YouPS accesses each user's inbox through IMAP and generates a sandbox environment to execute their rule.

Each YouPS method prints logs when it is executed, and users can also choose to print logs using Python's native print methods. Before actually running their rules over their inbox, users can test out their rules by telling YouPS to print out all logs from a user's rules but not actually execute the action. Users can also enable and disable different email rules. If an error occurs while processing a user's rules, YouPS notifies users by sending them email and logging the error to the interface.

Deployment. We recruited 12 email users (3 females, 9 males, mean age=23.5) through a university lab mailing list and word-of-mouth. Participants were undergraduate or graduate students studying fields in engineering who could program in Python. We introduced participants to YouPS and had them link their email to the system and author scripts for their inbox. Over the course of the week, they could return to the interface to edit, debug, or create new scripts. After the deployment, we had a one-on-one interview with each participant. Participants were compensated $35 for their time.

Email modes. During the deployment, 24 unique modes were created by the participants. One user said that he didn't use standard filters in email clients because he couldn't activate them only for particular periods. In comparison, he found YouPS email modes useful for temporarily activating rules. Another user described the modes they created in YouPS as: “I have a research mode (active from 9am-5pm) and sleep mode (active from 11pm to 8am). In my research mode, I mark all emails as read and move them to the TODO label. I do this so that I don't notice my new emails right away...and I can go through the new emails in my TODO folder periodically.” One participant wrote a script to programmatically change their mode to “concentration mode” after the arrival of an important email:

Another user described how they could configure fine-grained filters using email modes: “This [is] a way to write auto-replies that will be sent to co-workers, but not to family members, when going on vacation...Or, to snooze work-related email during the evening, but still allow family-related email...”

Leveraging interaction history. Echoing our survey results, users incorporated interaction history to triage emails. Prior interactions implied that the email they were receiving from a person was likely to be important. One user said: “If I've talked to someone via email, then their later messages are important to me”, while another said: “You have different interaction periods with a person and those lead to different priorities.”. Conversely, users could automatically disregard messages from certain senders if there were too many messages within a short time period:

(Non-)use of existing email client features. From interviews, we found that many users still manually process emails, even repetitive ones, despite the fact that current features within email clients can automate some of this activity. Similarly, during the deployment, more than half the rules written by participants could have been done already in their current client. We asked users why they didn't use features in their current interface. Some participants said that it was difficult to write proper rules: “I'd select the option to take emails from a certain address & marking them as read, but it didn't always work.” This suggests that we need better ways to debug and test automations.

One surprise from YouPS was that many of our subjects (10 out of 12) preferred writing rules in Python to using their mail clients’ rule-authoring interfaces. One said the reason they didn't like email interfaces for rule authoring is that they are cumbersome: “Adding a new one often takes a lot of clicks and typing, even when there is an obvious pattern.” In contrast, a second said “(YouPS is) so much lower friction. I can copy-paste rules or even produce similar rules in a loop, and use familiar programming concepts to combine their logic or make exceptions.”

Clearly, a programming language offers more flexibility than typical interfaces, but YouPS hides the complexity of talking to an IMAP server, so it may offer an attractive sweet-spot on the simplicity versus power tradeoff; this requires further investigation.

Hacks that overload existing email features. As a way to manage attention, we noticed users coming up with hacks that repurpose existing email functionalities. For instance, several probes saw users marking emails unread as a way to remind themselves to revisit those emails. Several scripts from Probe 2 and 3 also tried to develop customized notifications by marking incoming emails as read and moving them to different folders to suppress the default notification.

This kind of overloading of existing features suggests that email systems could provide a richer data model for email users to manage attention. Is binary marking (e.g. marking as read/unread or starred) enough to imply different intensities of attention? Is labeling messages with priority effective given the eventual need for updates? One survey respondent said she often forgot to update her ‘todo’ labels, ending up with too many labels after a while. This suggests we need more dynamic or automated ways to mark emails, including ways to signal different and intersecting forms of priority.

Linking inboxes to other applications. We repeatedly encountered a desire to leverage internal and external context. Breaking with current email clients, this requires understanding users’ inboxes beyond a single message and even further, beyond information stored within the inbox. Some of this context could be inferred rather than explicit, such as using number of unresponded emails or average response time to estimate a user's current load. However, context could also be determined explicitly, given the ability to link to other applications like calendars. As another example, some participants wanted to incorporate context such as current geolocation from their phone. This suggests that email systems should make it easier for users to leverage data from other applications when generating rules.

We also saw a need for complex content processing and interfacing with other applications, including use of email as middleware for other activities or to archive information to other places. Existing tools for task automation [26, 37] demonstrate one way to make it easier for email systems to interface with other systems, though some of these features may have greater adoption if integrated into email clients themselves.

Features from other social platforms. We found that email users wanted to incorporate features that are common on other social platforms. Indeed, prior work has pointed to ways that email usage, for instance within mailing lists, and social media usage, for instance on Facebook Groups, have become more similar [58]. This suggests additional ways that email systems could be adapted to suit how people conduct online discussion today. For instance, senders said they wanted to be more aware of their recipients, such as whether they were online or busy [41]. Users wanted more lightweight and casual ways of interacting as well as push notifications for certain content, blurring the lines between chat systems like Slack and email [59]. Users also wanted richer data models for their contacts in order to target messages, much like the user profiles that social media sites keep today. Finally, participants mentioned wanting community Q&A features like designating contacts to respond to a query, following or unfollowing threads, and the “average time to respond” metric available in tools like Piazza. They said seeing information about their own responsiveness would help increase productivity; we saw examples of this in Probe 2.

Customizing inbox presentation. Email has a broad spectrum of users from various backgrounds and contexts. A fixed interface for an email client cannot meet the diverse needs of email users. We noticed a desire to customize email interfaces in all three probes. This ranged from sorting emails in other than chronological order, highlighting important emails, and hiding some emails depending on time. Probes 1 and 2 also identified more structural changes to email clients, permitting alternative ways of viewing threads or messages. Since changing the interface requires manipulating users’ email client, we need to further investigate ways to allow email users to customize their interface.