Paper: Soya Park, Amy X. Zhang, Luke S. Murray, and David R. Karger. 2019. Opportunities for Automating Email Processing: A Need-Finding Study. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (CHI ’19), 1–12

Summary: This paper is a need-finding study exploring the opportunities and challenges for automating email processing. The authors conducted a mixed-methods study to pinpoint users’ expectations and needs in terms of automating email handling, in addition to the informational and computational support required for it. This study was divided into three main parts: what types of automated emails users want, what types of information and computation is needed, and then a field deployment of a simple inbox scripting tool. They did so in two steps. First, they had a formative design workshop where 13 computer science students created email processing rules. Second, they had a survey where 77 people (as well as 35 people without a technical background) answered questions to better understand categories of email automation, and their needs. The results show that there is a need to strengthen richer data on email, better management features, use of internal and external context,, and affordances. Finally, the paper describes a platform for writing small scripts for users’ inboxes, called YouPS. They enlisted 12 email users and found that users wanted more automation in their email management, especially in terms of richer data models, and processing content automatically.

Reflection: I agree with the premise of the paper: the fact that we should and can help people better manage their email inboxes to reduce the amount of energy people spend making sense of it. I wonder why email itself has got so overwhelming in the first place, and how it has affected workplace productivity. 

I especially like the multi-pronged approach that the authors took in this paper, with a formative study, a survey, and building a system. I believe this multi-state approach is valuable and can provide multiple insights as well as opportunities for triangulating data. 

With respect to their findings, I think the need for richer data models and rules, as well as ways to leverage internal and external email contexts are very important. If we are able to understand, for example, the senders’ urgency level and the receivers’ commitments to that sender, then we could draft a rule prioritizing or deprioritizing said emails. I also think the use of email templates and autofill options are useful and Google does something but in a more intelligent way with Gmail’s autofill feature. 

However, I wonder how many users actually make use of intelligent filters, and/or would make use of any new tools that are introduced in the feature. It may be the case that only knowledge workers are bombarded with emails that require responses, while most other users simply receive spam (which, I think, is about 90-95% of emails that are sent in the entire world). It would also be interesting to see how this differs between people’s work and home emails. I myself maintain an email address for communications that I know will be spammy, such as insurance applications.

Questions:

1. How do you manage your email? Do you use filters?
2. Do you manage your different inboxes differently? How?
3. What do you think of YouPS? Would you use it? Why or why not?

Read More

Summary:

This article discusses the e-mail management system. It is well known that e-mail has very important position in our lives, so the authors have developed a platform to help manage e-mail in order to make e-mail severs better. The authors have implemented methods that need study to learn: (i) what kind of automatic e-mails do users want, and (ii)what kinds of information and computation are needed to support that automation. The authors conducted three surveys: designing a workshop to identify categories of needs, conducting surveys to better understand these categories, and classifying existing email automation software to determine the needs that have been resolved. The authors ’results highlight the need to strengthen the following aspects in order to better automate the management of mail: richer data, more management attention, use of internal and external email contexts, complex processing (such as response summarization) and affordance senders. Finally, the authors developed a platform for writing small scripts on user inboxes. In their research, we found that most of the popular mail services are not enough to support automated management, which also supports us to develop new mail services.

Reflection:

First of all, from my personal experience, I agree with that we need a system that can help people manage email to reduce the energy people spend in this regard. Usually during my studies or work. If there is a new e-mail, I usually go to deal with the mail first, which is seriously affected the work efficiency. So a system to help manage mail is very necessary. And I also agree that the authors use three probes to study the needs of the mail management system. Among them, I think there are several requirements that are really urgent, such as richer data model for rules and the leveraging of internal and external email contexts. The richer data model helps to study the content and format of the email. For example, we have another article this week. Marking the structure of the article through people can help the machine to understand the article. Similarly, more email formats and templates Can help the machine understand the mail. And studying the internal and external emails can also better understand the content of the email, and at the same time understand the relationship between the sender and the user. These can be greatly improved. But I have doubts about the system mentioned in the article and the future development direction. Because researching the content of emails and users, especially such in-depth research, I think that it will intrude the privacy of users, and at the same time, I think that the accuracy of management cannot be guaranteed, so the wider application may bring more problems. As an example, I often find that some of the mails that I think are important are considered as spam and enter the spam box and make me miss many things. But I think the author proposes to make people customize in the text is a good solution, however for those who are not familiar with computer applications, whether such customization is really beneficial to their use is also a question and worth thinking about.

Question:

1. What aspects of the current popular mail service system needs to be improved?
2. If we want to build an automating e-mail processing system, do you think we need a brand new framework, or change slowly based on the existing service system?
3. Will automating processing of e-mail cause other problems?

Read More

SUMMARY

In this paper, the authors conduct a mixed-methods investigation to identify the expectations of users in terms of automated email handling as well as the information and computation required to support the same. They divided their study into 3 probes – ‘Wishful Thinking’, ‘Existing Automation Software’, and ‘Field Deployment of Simple Inbox Scripting’.  The first probe was conducted in two stages. The first stage included a formative design workshop wherein the researchers enlisted 13 computer science students that were well-versed with programming to create rules. The second stage was a survey that enlisted 77 participants from a private university including 48% without technical backgrounds. The authors identified that there was a need for automated systems to have richer data models, use internal/external context, manage attention, alter the presentation of the inbox. In the second probe, the authors mined GitHub repositories to identify needs that programmers had implemented.  Some of the additional needs they identified included processing, organizing, and archiving content, altering the default presentation of email clients, email analytics and productivity tools. As part of the third probe, the authors deployed their ‘YouPS’ system that enables users to process email rules in Python. For this probe, they enlisted 12 email users (all of whom could code in Python). Common themes across the rules generated include the creation of email modes, leveraging interaction history, and a non-use of existing email client features. The authors found that users did indeed desire more automation in their email management especially in terms of richer data models, internal and time-varying external context, and automated content processing.

REFLECTION

I liked the overall motivation of the study and especially resonated with the need of automated content processing as I would definitely benefit from having mail attachments downloaded and stored appropriately. The subjects that mentioned a reaction to signal if a message was viewed reminded me about Slack’s interface that allows you to ‘Add reaction’. I also believe that having a tagging feature would be good to ensure that key respondents are alerted of tasks that must be performed by them (especially in case of longer emails).

I liked the setup of Probe 3 and found that this was an interesting study. However, I wonder about the adoptability of such a system and as mentioned by the authors in the future work, I would be very interested in knowing how non-programmers would make use of these rules via the use of a drag-and-drop GUI.

The authors found that the subjects (10 out of 12) preferred to write rules in Python rather than use the mail client’s interface. This reminded me of prior discussions in class for the paper ‘Agency plus automation: Designing artificial intelligence into interactive systems’ wherein we discussed how humans prefer to be in control of the system and the level of automation that users desire (in a broader context).

QUESTIONS

1. The studies conducted include participants that had an average age group that was less than 30 and most of whom were affiliated with a university. Would the needs of business professionals vary in anyway as compared to the ones identified in this study?
2. Would business organizations be welcoming of a platform such as the YouPS system? Would this raise any security concerns considering that the system is able to access the data stored in the emails?
3. How would to rate the design of the YouPS interface? Do you see yourself using such a system to develop rules for your email?
4. Are there any needs, in addition to the ones mentioned in this paper, that you feel should be added?
5. The authors state that even though 2/3 studies focused on programmers, the needs identified were similar between programmers and non-programmers. Do you agree with this justification? Was there any bias that could have crept in as part of this experimental setup?

Read More

Summary

Park et al.’s paper covers the thankless task of email management. They discuss how people spend too much time reading and responding to emails, and how it might be nice to get some sort of automation going for dealing with the deluge of electronic ascii flooding our days. In their process, they interviewed 13 people in a design workshop setting where they came up with 42 different rules for dealing with emails. From these rules, they identified five different overarching categories for these rules. Using this data, the authors then sent a survey out and received 77 responses on how they would use a “smart robot” to handle their emails. They identified 6 categories of possible automation from this survey. The authors then took to GitHub to find any existing automation that coders have come up with to deal with email through searching for codebases that messed with IMAP standards. This came up with 8 different categories. They then took all of the data thus far and created an email automation tool they called YouPS (cute), and identified how today’s email clients needed to adjust to fully handle the wanted automation.

Personal Reflection

               I have to admit, when I first saw that they specified they gathered 13 “email users,” I laughed. Isn’t that just “people?” Furthermore, a “smart robot” is just a machine learning algorithm. The entire premise of calling their mail handler “YouPS.” This paper was full of funny little expressions and puns that I aspire to create one day.

               While I liked that they found that senders wanted recipients to have an easier time dealing wither their email, I wasn’t terribly surprised about that. If I wanted a reply to an email, I’d rather they get the email and be able to deal with it immediately rather than risking them forgetting about my request altogether. That’s the best of both worlds, where all parties involved have the right amount of time to apply to pressing concerns.

               I also appreciated that they were able to get responses from non-university affiliated people, as it’s often the case that research is found too narrowly focused on college students.

               Lastly, I enjoyed the abstraction they created with their YouPS system. While it was essentially just an API that allowed users to use standard python with an email library, it seemed genuinely useful for many different tasks.

Questions

1. What is your biggest pet peeve about the way email is typically handled? How might automation solve that issue?
2. Grounded Theory is a method that pulls a ton of data out of written or verbal responses, but requires a significant effort. Did the team here effectively use grounded theory, and was it appropriate for this format? Why or why not?
3. How might you solve sender issues in email? Is it a worthwhile goal, or is dealing with those emails trivial?
4. What puns can you create based on your own research? Would you use them in your papers? Would you go so far as to include them in the titles of your works?

Read More

Authors: Soya Park, Amy X. Zhang, Luke S. Murray, David R. Karger

Summary

This paper addresses the problem of automating email processing. Through an elaborate need-finding exercise with different participants, the paper synthesizes the different aspect of email management that users would want to automate, and the type of information and computation needed to achieve that. The paper also conducts a survey of existing email automation software to understand what has already been achieved. The findings show the need for a richer data model for rules, more ways to manage attention, leveraging internal and external email context, complex processing such as response aggregation, and affordances for senders.

Reflection

This paper demonstrates why need-finding exercises are useful, particularly, when the scope of automation is endless and one needs to figure out what deserves attention. This approach also helps developers/companies avoid proposing one-size-fits-all solutions and when it comes to automation, avoid end-to-end automated solutions that often fall short (in case of emails, it’s certainly debatable what qualifies as end-to-end solution). Despite the limitations mentioned in the paper, I feel the paper took steps in the right direction by gathering multiple opinions to help scope down the email processing-related automation problem into meaningful categories. Probing for developers who have shared code on Github certainly provided great value to the search to understand how experts think about the problem.

One of the findings was that users re-purposed existing affordances in the email clients to fit their personal needs. Does that mean the original design did not factor in user needs? Or the fact that the email clients need to evolve as per these new user needs?

NLP can support building richer data models for emails by learning the latent structures over time. I am sure, there’s enough data out there for training models. Of course, there will be biases and inaccuracies, but that’s where design can help mitigate the consequences.

Most of the needs were filters/rules-based, and therefore, it made sense to deploy YouPS and see how participants used them. Going forward, it will be really interesting to see how non-computer scientists use a GUI+Natural Language-based version of YouPS to fit their needs. The findings, there, will make it clear about which automation aspects should be prioritized for developing first.

As an end-user of email client, some, if not most, of my actions are at a sub-conscious level. For e.g. there are certain types of emails I do not think for even one second before marking them as read. I wonder, if a need-finding exercise, as described in this paper, would be able to capture those thoughts . Or, in addition to all the categories proposed in this paper, there should also be one where an AI attempts to make sense of your actions, and shows you a summary of what it thinks. The user, can then, reflect and figure out, if the AI’s “sensemaking” holds up or needs tweaking, and eventually, be automated. This is a mixed-initiative solution, which can effectively, over a period of time adapt to the user’s needs. This certainly depends on the AI being good enough to interpret the patterns in the user’s actions.

Questions

1. Keeping the scope/deadlines of the semester class project aside, would you consider a need-finding exercise for your class project? How would you do it? Who would be the participants?
2. Did you find the different categories for automated email processing exhaustive? Or would you have added something else?
3. Do you employ any special rules/patterns in handling your email?

Read More

In this paper, the authors explore the kinds of automated functionalities or needs for E-mail interfaces users would want. The authors held workshops with technical and non-technical people to learn about these needs. The authors found the need for functionalities such as additional or richer E-mail data models involving latent information, internal or external context, using mark-as-read to control notifications, self-destructing event E-mails, different representation of E-mail threads, and content processing. Afterward, the authors mined Github repositories that actually held implementation of E-mail automation and labeled them. The authors found prevalent implementations were on automizing repetitive processing tasks. Outside the needs identified from their first probe, the authors also found needs such as using the E-mail inbox as middleware and analyzing E-mail statistics. The authors did a final study by providing users with their own programmable E-mail inbox interface called YouPS.

I really enjoyed reading the section about probes 2 and 3 where actual implementations were done using IMAP libraries. I especially like the one about notifying the respondent using flashing visuals on a Raspberry PI. It looks like a very creative and fun project. I also noticed that many of the automation were in processing repetitive tasks. This again confirms the machine affordance about being able to process many repetitive tasks.

I personally thought YouPS to be a very useful tool. I also frequently have trouble organizing my tens of thousands of unread E-mails comprising of main advertisements. I think YouPS could serve me nicely in fixing this. I found that YouPS is public and accessible online (https://youps.csail.mit.edu/editor). I will definitely return to this interface once time permits and start dealing with my monstrosity of an inbox. YouPS addresses nicely the complexity of developing a custom inbox management system. I am not familiar with the concept of IMAPs, which hinders me from implementing E-mail related functionalities in my personal projects. A library like YouPS that simplifies the protocol would be very valuable to me.

The followings are the questions that I had while reading this paper.

1. What kind of E-mail automation would you want to make given the ability to make any automation functionality?

2. The authors mentioned in their limitations that their study’s participants were mostly technical programmers. What difference would there be between programmers and non-programmers? If the study was able to be done with only non-programmers do you think the authors would have seen a different result? Is there something specifically relevant to programmers that resulted in the existing implementations of E-mail automation? For example, maybe programmers usually deal with more technical E-mails?

2. What interface is desirable for non-programmers to meet their needs? The paper mentions that one participant did not like that current interfaces required many clicks and typing to create an automation rule and they didn’t even work properly. What would be a good way for non-programmers to develop an automation rule? The creation of a rule requires a lot of logical thinking comprising of many if-statements. What would be a minimum requirement or qualification for non-programmers to create an automation rule?

Read More

This work aims to reduce the efforts of senders and receivers in the email management space by designing a useful, general-purpose automation system. This work is a need-finding study that aims to explore the potential scope for automation along with studying the information and computation required to support this automation. The study also explores existing email automation systems in an attempt to determine which needs have been addressed already. The study employes open-ended surveys to gather needs and categorize them. A need for a richer data model for rules, more ways to manage attention, leveraging internal and external email context, complex processing such as response aggregation, and affordances for senders emerged as common themes from the study. The study also developed a platform, YouPS, that enabled programmers to develop automation scripts using Python but abstracted the complexity of IMAP API integration. Participants were asked to program using the YouPS platform to write scripts that would automate tasks to make email management easier. The results showed that the usage of the platform was able to solve problems that were not straight-forward to solve in the existing email clients’ ecosystem. The study concluded by listing limitations and also highlighted prospective future work.

I found it really interesting that this study provided the platform, YouPS, to understand what automation scripts would have been developed if it was easy to integrate with the existing APIs. After scraping public Github repositories for potential automation solutions, the study found that there were limited solutions that were generally-accessible. I feel that providing a GUI that would enable programmers as well as non-programmers to furnish rules to structure their inbox, as well as schedule outgoing emails using context, would definitely be useful. This GUI would be an extension to YouPS that abstracts the API integration layer away so that the end-users can focus on fulfilling their needs to enhance productivity.

While it is intuitive that receivers of emails would want automation to help them organize the incoming emails, it was interesting that the senders also wanted to leverage context and reduce the load on recipients by scheduling their emails to be sent when the receiver is not busy. The study mentioned leveraging internal and external context to process the emails and I feel that this would definitely be helpful. Filtering emails based on past interactions and the creation of “modes” to handle incoming emails would be practical. Another need that I was able to relate to was the aggregation example the study talks about. When an invite is sent to a group of people, individual emails for each response is often unnecessary. Aggregating the responses and presenting a single email with all the details would definitely be convenient.

• The study covered areas where automation would help in the email management space. Which need did you identify with the most? 
• Apart from the needs identified in the study, what are some other scenarios that you would personally prefer to be automated?
• The study indicated that participants preferred to develop scripts using YouPS to help organize their emails as opposed to using the rule-authoring interfaces in their mail clients. Would you agree? Why or why not?

Read More

Summary

The primary goal of the paper is to provide automation support to users in terms of email handling. The authors first tried to determine what are the automatic features that users wanted in their email service and what are the informational and computational needs when it came to implementing such a system. They conducted three experiments, out of which, the first experiment was to gauge what kind of features the users wanted to be automated. In this particular study, there was no boundary as to what can or can’t be implemented. So this experiment effectively gave all the range of tasks and features users would “wish” their email interface provided. The second experiment aimed to find all the current automated implementations available on the market. This involved sifting through GitHub repositories to find projects aiming to solve the current gap regarding automation of email processing. Finally, the last experiment involved giving the users to code their “ideal” features using the YouPS interface. This study consisted mainly of students from engineering backgrounds familiar with Python programming.

Reflection

The paper provided an interesting perspective on how users want their email clients to perform. For this, it was important to understand the needs of the people. The authors’ do this by conducting the first experiment on finding the ideal features that users look for. I liked the way the task of customer discovery of needs was approached. However, I wanted to point out that the median age range of participants’ was 20-29, and all had a university affiliation. It would be interesting to see what older people from both university and industry background want in such email clients. Getting the perspective of a senior researcher or a senior manager is important. I feel that these people are the ones who receive far more number of emails and would want and need automated email processing. 

I resonated with most of the needs that users’ pointed out and recognized some of the existing features that my current email client provides. For example, google generally keeps an option of “follow up” if an email sent didn’t get a response or the “reply” option if the email received hasn’t been replied for n-days. I am particularly interested in the different modes that could be set up. This would prove to be useful where the user could focus on work and periodically check a particular label like “to-do” or “important.” Additionally, only getting an important notification is also a priceless feature, in my opinion. 

Having loved all the proposed features in this paper, I would also like to point out some of the flaws, in my opinion. First, some of the applied rules might cause disruptions in case of important emails. One of the features mentioned was to automatically mark an email “read” when the consecutive emails come from the same recipient. This would work in case of a “social” or “promotions” email. However, this might end up making the user do more tasks, i.e., find from the read emails the ones that he actually never read. Additionally, I was also curious to know how security was handled here. Emails are anyways not known to be a secure medium of communication, and using this tool on top of it might make it further unsecure. Especially when research-related topics are discussed in the emails, they might be prone to breach? 

Questions

1. What are the features you look for when it comes to email management? I would want to be only notified about emails that are important. 
2. What other systems could benefit from such studies other than email processing? Could this be used to improve recommender systems, other file organizing software? 
3. Would it be useful to take the input of senior researchers and managers? They are people who receive a lot of emails, and knowing their needs would be useful.
4. How was the security handled in the YouPS system? 

Read More

Summary:
“Opportunities for Automating Email Processing: A Need-Finding Study” by Park et. al. is an interesting paper as it talks about the need to manage emails. Managing emails is a time-consuming task that takes significant effort both from the consumer and the recipient. The authors find out that some of the work can be automated. The authors performed a mixed-methods need-finding study in order to essentially understand and answer two important questions: (i) What kind of automatic email handling do users want? (ii) What kind of information and computation is needed to support that automation? The authors conduct an investigation including a design workshop and a survey to identify the categories of needs and thoroughly understand these needs. The authors also surveyed the existing automated email classification systems to understand which needs have been addressed and where the gaps are in fulfilling these needs. The work done highlights the need for: “(i) a richer data model for rules, (ii) more ways to manage attention, (iii) leveraging internal and external email context, (iv) complex processing such as response aggregation, and affordances for senders.” The authors also ran a small authorized script over a user’s inbox which demonstrated that the above needs can not be fulfilled by existing email clients. This can be used as a motivation for new design interventions in email clients.

Reflections:
This is an interesting work that has the potential to pave the way for new design interventions in email processing and email management. However, there are certain limitations of this work. Out of the three studies that the authors conducted, two of them were explicitly focused on programmers. The third study focused on an engineer. This brings into question the generalizability of the experiments conducted. The needs of diverse users may wary and the results might not hold. Also, the questions the authors asked in the survey were influenced by the design workshop conducted by the authors which in turn influenced the analysis of the needs. The results might not hold true for all kinds of participants. The authors also could not quantify the percentage of need that is not being met. Also, asking programmers to be a part of the study did not help as they have the skills to write their own code and fulfill their own needs. The GUI needed by non-programmers might differ from those needed by the programmers. The authors should also seek insight from prior tools to build and improve upon their system.

Questions:
1. What are your thoughts on the paper? How do you plan to use the concepts present in the paper in your project?
2. Would you want an email client that manages your attention? Do you think that would be helpful?
3. How difficult is it for machine learning models to understand the internal and external context of an email?
4. Which email client do you use? What are the limitations of that email client?
5. Do you think writing simple rules for email management is too simplistic?

Read More

Despite many different innovations from many different directions to try and revolutionize text communication, the humble email has lived on. The use of emails and email clients has adapted to current demands. The authors of this paper conduct investigations of the current needs of email users through a workshop and a survey, and they analyze open source code repositories that were performing things on email, in order to identify what are the current users needs, what is not being solved by existing clients, and what tasks are people taking the initiative to solve programmatically that their email clients don’t solve. They identify several high level categories of needs: the need for additional metadata on the email, the ability to leverage internal and external context, managing attention, not overburdening the receiver, and automated content processing and aggregation. They create a python tool called YouPS that provides an API with which a user can write scripts to perform some email automation tasks. They study the users of their tool for a week and note the kind of work they automate with the tool. They found that about 40% of the rules the users created with YouPS could not be done within their ordinary email client.

It’s fascinating that there is so much efficiency that can be obtained by allowing people to manage their email programmatically. I feel like something like this should’ve been a solved problem but apparently there is still room for innovation. It’s also possible that what YouPS provides is something that couldn’t really be done in an existing client, either because an existing client is trying to be as user friendly as possible to the widest variety of people (how many people actually know what IMAP does?). Alternatively, it could be a result of email clients just having accumulated so much cruft that adding a programmable layer would be incredibly hard. I get the reason why their survey participants skew towards computer science students, and how their solution gravitates towards solving the email problem in a way that is better suited for people who are in computer science. But I also think that, in the long term, keeping YouPS the way it is is the right way to go. With every additional layer of abstraction you add, you lose flexibility. GUIs are not the way to go but rather that people will adapt to using the programming API as programming becomes more prevalent in daily life. I also find the idea of modes really interesting and useful and would definitely be something I would like to have in my email clients.

1. What kind of modes would you set up with different sets of rules e.g. a research mode, a weekend mode?
2. Do you think that changing YouPS to be more GUI based would be beneficial because it would reach a wider audience? Or should it keep its flexibility at the cost of maybe not having wide spread adoption?
3. How would you think about training an ML model that can capture internal and external context in your email?

Read More