Category Archives: Email Research

In some exciting news, the New York Times reports that work done by Microsoft Researcher may be working its way into Outlook, among other products. The work would use machine learning algorithms to examine a user’s behavior and the emails they receive “to suggest whether a user wants to read each message that comes in.” This could be a fascinating improvement to the most popular desktop client in the world.

Horvitz has produced an amazing body of work since starting at Microsoft in the 90s, and a good deal of it has dealt directly with information and email overload. For example, Iqbal and Horvitz’s 2007 article “Disruption and recovery of computing tasks: field study, analysis, and directions” is a great example of determining real-world costs to task switching.

Adding intelligence to email clients, especially in the form of identifying user behavior and trying to determine message value, would be a huge step forward. Also important is that this would be implemented in the client that many middle- and upper-managers are using—the people who experience the most overload.

Now of course we don’t have anything more specific yet, but this news is very exciting to those of us interested in email overload, and sounds very positive. Great to see Microsoft continuing to innovate in this sphere, and hopefully bringing some of the excellent ideas of the future into reality.

Share and Enjoy

  • Twitter
  • Google Plus
  • LinkedIn
  • Email
  • RSS
  • HackerNews
  • Instapaper
  • StumbleUpon
  • Facebook

Recently I have had a curious question nagging at me that would have profound impacts on the way that we work with and around information. How do we determine the value of information, or what heuristics do we use to evaluate the worth of some information to us? Whether it be valued in terms of time, money, health changes, etc., we certainly make subconscious decisions regarding the ROI to consume a bit of information. I am wondering what facets others use to make this judgement call.

If you have personal anecdotes, thoughts, or resources, I’d love to hear of them. In the meantime, I am going to be looking into what has been uncovered in this area, and pursue what we can discover going forward.

Share and Enjoy

  • Twitter
  • Google Plus
  • LinkedIn
  • Email
  • RSS
  • HackerNews
  • Instapaper
  • StumbleUpon
  • Facebook

Whew, graduating, moving, and starting a new job all take an incredibly large amount of time! There is a ton of material that I still want to get up regarding the information overload research that I did in my last semester, but I just haven’t had the chance. However, I can at least get my final presentation up so that others can at least peruse it.

Now this presentation is really meant to be accompanied by my narration, so it won’t be nearly as rich just reading through it as it currently exists. However, it should at least give a starting point to the conversation, and include some good resources to jump off from.

Please let me know what questions you may have, and if you need the narration along with it. I’m happy to discuss any and all of this material!

Share and Enjoy

  • Twitter
  • Google Plus
  • LinkedIn
  • Email
  • RSS
  • HackerNews
  • Instapaper
  • StumbleUpon
  • Facebook

Over the last several months I have been pouring over as many different research articles as I could in order to get a handle of what has already been done, discovered, and discussed in relation to information overload and email overload. Luckily, some fantastic researchers both in academia and industry have been busy studying out the problem to a great extent.

I want to share at least some of the best snippets I have found, and especially the particular papers that I have found helpful. I’m not exactly sure how I want to disseminate this information, other than I know that I want it out there, so I’m going to start with a very simple PDF file and text bibliography. I may expand it in the future if I can find a better way to communicate it. For now, I hope that others looking for good, solid research will be able to use this as a good resource for information and email overload. Oh, and for now it also includes my personal notes and thoughts, so you can just ignore that column if you want. :)

Email Overload Literature Review (PDF)

Bibliography:

Ayyagari, R., Grover, V., & Purvis, R. (2011). TECHNOSTRESS: TECHNOLOGICAL ANTECEDENTS AND IMPLICATIONS. MIS Quarterly, 35(4), 831-858. Retrieved from http://www.misq.org/skin/frontend/default/misq/pdf/appendices/2011/AyyagariGroverPurvisAppendices.pdf

Bellotti, V., Ducheneaut, N., & Howard, M. (2005). Quality versus quantity: E-mail-centric task management and its relation with overload. Human-Computer Interaction, 20, 89-138. Retrieved from http://portal.acm.org/citation.cfm?id=1466574

Dabbish, L. A., & Kraut, R. E. (2006). Email overload at work: An analysis of factors associated with email strain. CSCW ’06 Computer Supported Cooperative Work (pp. 431-440). Banff, Alberta, Canada. Retrieved from http://dl.acm.org/citation.cfm?id=1180941

Ducheneaut, N., & Watts, L. A. (2005). In search of coherence: a review of e-mail research. Human-Computer Interaction, 20, 11-48. Retrieved from http://portal.acm.org/citation.cfm?id=1466572

Fisher, D., Brush, A., Gleave, E., & Smith, M. A. (2006). Revisiting Whittaker & Sidner’s “Email Overload” ten years later. CSCW ’06 Computer Supported Cooperative Work (pp. 309-312). Banff, Alberta, Canada. Retrieved from http://dl.acm.org/citation.cfm?id=1180922

Gupta, A., Sharda, R., & Greve, R. a. (2010). You’ve got email! Does it really matter to process emails now or later? Information Systems Frontiers, 13(5), 637-653. doi:10.1007/s10796-010-9242-4

Gupta, A., Sharda, R., Ducheneaut, N., Zhao, J. L., & Weber, R. (2006). E-mail Management: A Techno-Managerial Research Perspective. Communications of the Association for Information Systems, 17, 941-961.

Hemp, P. (2009). Death by information overload. Harvard Business Review, 87(9), 83–89. Harvard Business School Publication Corp. Retrieved from http://ocvets4pets.com/archive21/Death_by_Information_Overload_-_HBR.org.pdf

Hogan, B., & Fisher, D. (2006). A scale for measuring email overload. Microsoft Research, 7-9. Retrieved from http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:A+Scale+for+Measuring+Email+Overload#0

Iqbal, S. T., & Horvitz, E. (2007). Disruption and recovery of computing tasks: field study, analysis, and directions. Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 677–686). ACM. Retrieved from http://dl.acm.org/citation.cfm?id=1240624.1240730

Paul, S., & Nazareth, D. L. (2010). Input information complexity, perceived time pressure, and information processing in GSS-based work groups: An experimental investigation using a decision schema to alleviate information overload conditions. Decision Support Systems, 49(1), 31-40. Elsevier B.V. doi:10.1016/j.dss.2009.12.007

Tyler, J. R., & Tang, J. C. (2003). When can I expect an email response? A study of rhythms in email usage. Proceedings of the eighth conference on European Conference on Computer Supported Cooperative Work (pp. 239–258). Kluwer Academic Publishers. Retrieved from http://dl.acm.org/citation.cfm?id=1241902

Wattenberg, M., Rohall, S. L., Gruen, D., & Kerr, B. (2005). E-mail research: targeting the enterprise. Human-Computer Interaction, 20(1), 139–162. L. Erlbaum Associates Inc. Retrieved from http://portal.acm.org/citation.cfm?id=1466575

Whittaker, S. (2005). Supporting collaborative task management in e-mail. Human-Computer Interaction, 20(1), 49–88. L. Erlbaum Associates Inc. Retrieved from http://portal.acm.org/citation.cfm?id=1466573

Share and Enjoy

  • Twitter
  • Google Plus
  • LinkedIn
  • Email
  • RSS
  • HackerNews
  • Instapaper
  • StumbleUpon
  • Facebook

There seems to be a constant flow of “email is/is not broken” articles on HN and various other places. Some of them are very business-oriented, and some of them are scathing rejections (language). But most of them miss the point. Email as a system is not broken, but we, through our email behaviors, are broken.

Nearly all of the articles written recently about fixing email have concentrated on technology and building a better client or implementing the specs more closely or bringing two systems together. These are all great ideas and have a ton of value, but they will not fix the inherent issue that people are experiencing with email, but which most articles fail to articulate: we think email is broken because we are overwhelmed by it and get less real work done because of it.

So instead of asking how we can make email better/faster/cooler, we need to ask ourselves how we can get more work done while still using email. Unfortunately, many experiences have shown over the past decade or so that this problem is not easily solved by new technology, as much as I would love that. It is solved by teaching people better email behaviors. This is certainly a less sexy solution, but guess what? It’s the attainable one. Here are some ideas that I’ve come across from others, and that warrant further investigation. They are all designed to help us get more real work done, which is the real problem with the email timesink.

  • Stop checking email continuously and turn off desktop alerts. It is absolutely ridiculous that we allow Outlook to check email every 5 minutes, allow our phone to get push messages, or keep a Gmail tab open all the time. This is absolutely killing us in terms of productivity. In 90% of all cases we don’t need to know immediately that there is a new message. Segmenting our email checking time into 2, 4, or 8 times a day has massive benefits. We greatly reduce task-switching penalties, and removing the alerts so we’re not tempted goes a huge way. See this post for more details.
  • Set up a social contract with your colleagues. Several posts have mentioned that email has moved beyond its original purpose, which is true. However, we can still use it. But we cannot continue to use it with everyone having different expectations for its reply rate. We have imbued in email the urgency and rapidity of a telephone call, and that is not good because we cannot handle it in the same way as a telephone call. At work or among your close colleagues, people need to understand and respect how others treat response times. If one person feels that email should be responded to within 2 hours and another within 8-24, there will be obvious pain points. Let those around you know your expectations and respect theirs. Deal with differences as a human being, meaning walking over to or calling someone if you know that their typical response time isn’t fast enough for your issue. This is an area where small new tech could be very beneficial: when composing a message to someone, have an indicator of how soon they are likely to respond, given their own “social contract” and typical patterns.
  • Productivity vs Acceleration. This idea comes from David Levy, who notes that in our society we have confused productivity with acceleration, or getting more things done faster. Productivity should actually be more like getting the right things done better. When using email, sending tons of short, not fully formed messages is killing us. We need to take the time to construct useful, productive messages, something most of us are not doing. Levy notes that “‘timeout’ is a punishment because of our focus on productivity in our society.” Ouch.

There’s a whole lot more that could be said on the matter, but I want to help reframe this discussion of “email is broken” by helping everyone realize that it is not the tech that is broken, but the fact that the tech is not helping us get our primary tasks and work done because of our behaviors using it. I am also very excited for the tech that is coming to help fix this, but I also firmly believe that the majority of the solution lies in helping people to better understand how to use the technology in a better way to help us as human beings communicate and get work done. This is certainly a big issue to me, and I hope we make a lot of progress on the matter.

Share and Enjoy

  • Twitter
  • Google Plus
  • LinkedIn
  • Email
  • RSS
  • HackerNews
  • Instapaper
  • StumbleUpon
  • Facebook