Friday, February 05, 2010

reMAP Meetup at SXSW?

Joshua Baer (founder of email startup OtherInbox) and me are thinking about putting together a meetup for people interested in replacing IMAP.

We would meet sometime around the SXSW Interactive festival in Austin, Texas (March 12-16). Exact time is still unclear, but Joshua has kindly offered up his company's offices, which are just a few blocks from the event.

Who's interested?

Labels: ,

The IMAP Compatibility Matrix

There's a great discussion going on in the comments of my post about replacing IMAP, and also on YCombinator's Hacker News.

One frequent point made about my proposal is that IMAP already has a number of extensions that do things I suggested, such as the THREADS, SEARCH, and IDLE commands for conversations, search, and long polling ("push").

Commenter Bron (who works on a popular IMAP server) writes:

Also, IMAP plus a random mix of extentions becomes a HUGE compatibility matrix, and you have to offer fallback from all the nice stuff to really shitty workarounds just in case the server doesn't support a feature that makes your life bearable.

So - I'd love to see a decent competitor to IMAP as a protocol. If nothing else because it would reduce the compatibility matrix. Alternatively, I'd be happy for an IMAP5 to be defined which included all the good extentions - so anything which advertised support for IMAP5 had to support them.

Defining an IMAP5 standard might be a good alternative than something like reMAP, and adoption might be much faster. However, a potential IMAP5 would still remain a protocol inaccessible to many developers so it might not unleash the storm of creativity I'm hoping for.

Keep those comments coming.

Labels: ,

Wednesday, February 03, 2010

How to Replace IMAP

IMAP is a complex and difficult protocol. Its original design, RFC 1730, dates back to 1994. Here's a sample IMAP session that shows you all of IMAP's quirks: It's a stateful protocol where you login and select a mailbox to operate on, it has an unconventional parenthesis-heavy representation for structured data, and fetching messages is a multi-step operation.

Design Outline

One of these days, I'll write up a spec for the mail access protocol of my dreams. I'm planning to call it the "reimagined Mail Access Protocol" (short: reMAP) which is handy because reMail already owns the domain name :-)

I would aim for a RESTful design with the following properties:
  1. All communication over HTTP / HTTPS: Pure TCP connections are great, but for transferring large amounts of email, HTTP is the way to go. Problems like security, parallel downloads, persistent connections, caching, compression, download continuation via ranges, and so on have already been solved. There is no reason to solve them again.

  2. Stateless: There's no reason to introduce state like IMAP does with its selected mailboxes. All you need is a HTTP session cookie used for authentication purposes. Session cookie also allow for things like OAuth. OAuth would let third parties get your permission to access your email without having to give them your username and password.

  3. JSON and UTF-8: All data that's ever sent to or received from the server would be in JSON format. JSON is much more human-readable than XML. UTF-8 would be the only encoding allowed, since it is able to represent any character in the Unicode standard.

  4. Conversations as first-order objects: Gmail, the iPhone SMS app, and Facebook's messaging system have shown the value of viewing messages not individually but in the context of conversations. In reMAP, the server would be responsible for grouping together messages. While you could still access individual emails, the first-order unit of data would be a conversation.

  5. Labels, not folders: Labels are much for flexible than folders. Each conversation should have multiple labels, and the labels would be included when you request the message, rather than having to scan all folders for the message via IMAP.
  6. Stable and unique IDs: IMAP has a UID for each message, but it changes the moment you move the message into a different folder. An IMAP server can also declare all UIDs to be invalid at any moment throughout the session. No more! reMAP would have stable and unique IDs for all conversations, emails, and attachments.

  7. The beginning of the end for MIME: Yes, you could still get the MIME representation of each message that is sent. But MIME is a messy and complex beast. Instead of requesting the MIME-encoded message parts, you could just ask the server to give you the message as represented in plain text or HTML. Attachments can be downloaded in separate HTTP calls.

  8. Push built in: The two prevailing methods for implementing push email are the IMAP IDLE command (not widely available in IMAP servers) and Microsoft's ActiveSync, which requires developers to purchase a license from Microsoft. In reMap, clients could just call an HTTP endpoint on the server which returns as soon as new messages are arrive.

  9. Full-text index on the server: reMAP servers would need to maintain a full-text index of the contents of all messages. There's no reason clients should be required to download and index everything in order to do an exhaustive full-text search of your email.

Enormous Potential


I believe that one of the reasons for the lack of innovation in the email space is the lack of a simple yet powerful email access protocol. Every developer that wants to try something with email needs to first jump through the hoops of IMAP and MIME, or worse, the Outlook Object Model and MAPI. A new protocol like reMAP would lift this burden off their shoulders. We've seen what open, simple standards can do for innovation with Twitter's and Flickr's API. Now imagine unleashing the same sort of creativity to the vast ocean of data that is email.

Let me know what you think. My goal with this post was to encourage a discussion about this topic, and your comments are much appreciated.

If you liked this, consider following me on Twitter where I often tweet about email-related topics!

Labels: , ,

Tuesday, February 02, 2010

"A good email client, please."

My friend Patrick Collison writes on Facebook:

"Gmail proved that, despite the apparently high switching costs, a new webmail client can quickly get a lot of traction. There’s room now to do to Gmail what Gmail did to everything else. The replacement should have some concept of workflow (”archive, but remind me to respond tomorrow”, “send, and alert me if I don’t get a response within a few days”), some concept of teams and colleagues (allow threads to be shared as a first-class object, rather than flailing around with forwards and CC lines), be some way smart about mining the semi-structured mails going through the system (flight booking emails should be automatically annotated with .ics files), know something about prioritization (I like Twitter DMs because of the assumption that they’ll go to a mobile device. If I’ve sent more than 20 emails to someone, they should have the option of copying their mail to me as an SMS).

Potentially most powerfully of all, developers should be able create their own plug-ins that run on the server. There should be an agreement between plug-in developers and the webmail provider that creating a plug-in automatically grants a royalty-free perpetual irrevocable worldwide (etc.) license to the provider, and that the source code to any plug-in may be merged into the main product. Though plug-ins have niche appeal, this could be a good source of new features, and a strong competitive advantage. I’d just fix Gmail if I could.

I’d happily pay for any service that got this stuff right."


Some good ideas in here. Server plug-ins could work in a manner similar to Google App Engine. A lot has been tried around better triage and data mining, with no clear winners yet. Also, there's a danger of feature overload somewhere in here. I'm not sure if we should replace one variant of feature overload (Microsoft Outlook) with another (integrated SMS / Twitter / Facebook / email). Maybe SMS, Twitter, Facebook, and email should instead all just be replaced with one thing that is the combination of all lessons learned with those protocols.

Labels:

Tuesday, December 15, 2009

Mobile Email Usage to Grow from 131M to 434M in 2 Years

I just found this great report [pdf] by email research group Radicati. It comes with bucketloads of stats and predictions on email usage.

In particular, this one table is a gem. According to Radicati, mobile email usage is poised to grow from 131 million users today to 434 million in 2011.



That's pretty substantial growth - almost 100% growth year-on-year! I'm happy that's the space that reMail is in.

Labels: ,

Monday, December 07, 2009

Shocker: A Drop in Email Overload!?

The Radicati Group is a research organization owned by HP that surveys email and messaging usage patterns. Here's a shocking new blog post:
Our newly released Business User Survey, 2009 shows that for the first time since we started monitoring email traffic patterns, the amount of email that reaches business user inboxes is actually decreasing. Survey respondents indicated that they sent and received an average of 108 email messages per day in 2009, which is noticeably lower than the average of 140 email messages sent and received in 2008. This is a fairly significant decrease of 23%!

Their explanation for this data is that users are shifting to other means of communication such as IM for certain type of messages: "Wanna grab lunch?"

This data does not fit my observations. For me, 2009 was the year of notification emails, as illustrated here and here.

My alternative explanation: This is a survey-based report. People generally overreport on how busy they are. They've recently become more realistic.

Now if only I had $2500 to buy that research report.

Labels:

Monday, November 16, 2009

"Outlook? Hey, the nineties just called, and they want their email back."

Tuesday, October 20, 2009

7 Points on “The End of the Email Era”

"The End of the Email Era", a Wall Street Journal article by Jessica Vascellaro ignited, somewhat ironically, a flurry of "have you read this?" emails in my inbox. I'm a bit late to the party of dissecting Vascellaro's piece. All of last week, I was cranking on a new version of reMail. Yet I felt I'd write about it, since I feel pretty qualified to comment on email-related topics.

WSJ's 4 Points

In case you haven't read it, here are the points that the WSJ article makes:
  1. IM is better than email because it gets you faster responses.

  2. Twitter and Facebook updates are better than email because they're informal and fun.

  3. All these updates will cause even more overload and filtering needs to improve.

  4. Facebook gives you context about people's location, mood, and current activity. You need to coordinate less than if you were using only email.

Gabor's 7 Points

Most people misread the WSJ piece as "email is dying". But email isn't dying, it's being complemented by new modes of communication. And despite Paul Graham's warning about "lists of N things", here's my list of 7 things to contribute to the social network updates vs. email debate.
  1. Twitter and Facebook updates are orthogonal to email. Looking through the last 200 tweets on my Twitter feed, I didn't find a single update that I would have sent as an email had Twitter not existed. The use cases are too different. Thus, Twitter is a parallel world to email.

    This HuffPo article puts it best:
    If you're like us, you still send text messages on the weekends, check voicemail at work, post photos to Facebook, watch viral videos on YouTube, and Tweet your favorite news.

    In other words, we haven't "killed off" our previous tools: we're actually adding, not abandoning, platforms. And when we do ditch, it's because of forces more complex than seasonal trends (or the news cycle).

  2. Email is private, Twitter is public. Twitter and Facebook can't replace email because they're public or semi-public communications channels. Direct messages in Twitter and Facebook messages are bad, low-fidelity clones of email functionality. You shouldn't use them.

  3. Your work email belongs to your employer. You can't use Facebook for work. The messages and the intellectual property you create while at work belong to your employer. If you leave the company, you shouldn't be able to take them with you.

  4. Email is about task management. The reason why your inbox is a source of stress and your Twitter feed is not is because email is a task manager. Twitter and Facebook are entertainment. Your boss wouldn't assign a task to you via a Facebook update. But if your boss sends you an email, you better read it and get that work item done.

  5. The unread messages counter. Unlike Twitter, email has an unread message counter. If it didn't have that counter, email would make you far less anxious. But it would lose its work value as a task manager.

  6. The future of email is not to become IM. Part of the value of email is that it's asynchronous: While you're getting actual work done, new messages pile up. You don't want to give everyone the chance to interrupt your work flow. You wouldn't get things done. And that's exactly the problem with turning email into IM, whether it's with push notifications or Google Wave: Yes it will get you answers instantly, but it would make everyone less productive.

  7. The lack of innovation in email is because the underlying protocols suck. If you have a great idea about how to use or display the data in Twitter, all you need to read is the Twitter API docs. If you have a great idea in email, you need to know MIME (the encoder), SMTP (the message protocol), IMAP or Exchange (the access layer), and your email client (the viewer). The email technology stack is huge, wobbly, and antiquated.

    Take IMAP: a hugely inefficient, stateful protocol with an ugly message format. State-of-the art in the late 1990s, yes, but if you were to reinvent it today, you could do a much better job.

    We need to make it easier to innovate around the mail client. We could rip out everything (maybe save for SMTP) and build a great new stack that allows fast iteration. Make it easier to move the needle in email, and the needle will move.

Labels: , , ,

Friday, October 16, 2009

"A Never-Ending Spiral of Needless Messages"

From the Telegraph's 50 most annoying things about the Internet:

3) Messages alerting you to messages
Email inboxes are becoming clogged with non-urgent alerts from Facebook, Twitter and other social media websites. How long before someone invents an app to alert Twitter and Facebook users when they receive an email, creating a never-ending spiral of needless messages?

Reminds me of my post on Facebook's dream vs. reality.

Labels:

Sunday, October 04, 2009

What Makes an Email Important?

In my last post, I said it would be good if email clients only notified you of important emails, rather than popping up a toast for each email that arrives. One of the commenters asked me to point to some research about this topic.

What makes an email important? In this Microsoft Research report [1], the authors have conducted surveys of email usage inside Microsoft. One of the questions they asked was "When is an email particularly important?". Here are the responses:


Note that 5 out of the 10 factors are directly related to who sent the email. (This would indicate that filtering or auto-classifying emails by sender could be very effective.)

I have a bunch of other interesting research results to point to when I have a little more time. If you've read anything interesting recently, please point me to it in the comments.

[1] Gina Danielle Venolia, Laura Dabbish, JJ Cadiz, and Anoop Gupta. Supporting email workflow. Technical report, Microsoft Research - Collaboration and Multimedia Group, September 2001.

If you find this interesting, you should also read HappyMail.

Labels: ,

Wednesday, September 30, 2009

Do You Keep Gmail Open in Your Browser?

Everyone who uses Gmail knows this: You keep Gmail open in your browser all day so you can check your email, send off messages, and search your email archives.



Why This is Unacceptable

Yes, I believe that Gmail is the future of email (I'm a little biased).

But this is far from the optimum. Keeping Gmail and Google Calendar open in your browser should not be how we'll do email in 10 years.

Why?
  1. It gets lost: Gmail being just an open tab in your browser means that it will get lost among many other tabs and browser windows that are open. As I'm writing this blog entry, I have 11 tabs open in Firefox.

  2. No notifications: Unless you install separate tools, Gmail can't notify you of new important messages that come in. I'm not a fan of push email as it increases hyperactivity, but some level of notification, especially for meetings approaching in Google Calendar would be useful.

  3. No integration into your workflow. Clicking mailto links doesn't work. There's no spot on your screen that says "email". There's no right-click send for documents.

Should Gmail Become Outlook?

Should the Gmail become a desktop client Outlook? No. I think that would be a step back, not forward. I imagine the ideal setup to be like Tweetie's desktop client. An icon sits in your desktop bar and gently lights up when new things arrive. (Update: Mailplane and Fluid have similar functionality, but only for the Mac).

Here's how I imagine the optimal desktop webmail experience:
  1. Always on: It's not a tab you launch in your browser. It starts when your computer starts and it's on while you're working.

  2. Smart notifications: Rather than showing a toast notification or playing a chime sound for each email that arrives, it would know about the relative importance of messages and infer from your behavior if it's OK to interrupt you. There's plenty of research about both importance and notifications that still needs to make it into the real world.

  3. Keeps a copy of all your messages: I think reMail demonstrates how powerful it is to have all your mail on your phone. If you have your mail on your phone, why can't you have it on your desktop? Offline Gmail is headed the right way. In my ideal client, its features would become standard.

Making real progress in email clients is hard. It's easy to add new widgets, helper utilities, notifiers, and spam bots. But it's hard to move the needle on the fundamental paradigms - how do we read, check, search, and organize. Moving Gmail away from the browser into an always-on background app seems comparatively easy. The things I mentioned could probably be done by a third party - it doesn't need to be Google. Please, let's get this done.

Labels: , , ,

Tuesday, September 29, 2009

Email and Webmail Statistics

I just found this page which compiles some usage stats for webmail providers. Roughly:
  • Hotmail: 256.2 million
  • Yahoo: 254.6 million
  • Gmail: 91.6 million
  • AOL: 48.9 million
These number seem a bit off (Gmail is probably too low, Hotmail too high). The article goes into more detail on sources and estimates - I suggest you check it out.

Labels: ,

Thursday, August 13, 2009

Introducing the New reMail

Today, we're launching the new reMail for the iPhone! It's a completely new product.

reMail downloads all your email to your phone and lets you search full-text at light speed.

All My Email On My Phone? Really?

Yes, reMail downloads all your email to your phone. It will let you read and search all your email when you're offline. Just let reMail run overnight to complete the download. reMail needs less space than you think: 100,000 emails take only 500 MB on your phone - only 6% of the capacity of an 8 GB iPhone (the smallest iPhone you can buy).

This Will Save You Money

My family lives in Switzerland and I live in San Francisco. One thing I've found very frustrating whenever I travel to see my parents are the insane fees that AT&T charges for data roaming: For Switzerland, AT&T charges $19.97 per Megabyte. Check out this SMS I get the moment I turn my phone on the tarmac in Switzerland.

Now, with reMail, I don't have to think twice about searching for meeting times or flight reservations. When I'm abroad, I just download all my email over Wifi and have data roaming turned off.

We put together this page that contrasts data roaming prices with AT&T and T-Mobile Germany with the cost of reMail.

reMail Searches Full-Text

Another crucial difference between iPhone 3.0 Mail and reMail is that reMail searches full-text.

The built-in header-only search is frustrating, because so many times, the words I'm searching for don't appear in the To, From, and Subject lines. If the words you search for aren't in the headers, reMail will find the email, iPhone Mail will not. reMail is email search you can trust.

What happened to reMail Search Beta?

We launched reMail Search a few months back, it was a server-based product. Searches were being done on the server, and you had to give us your email password. It turns out people are very opposed to sharing their email and password with third parties, especially a small startup.

So we built the new reMail. Now, everything happens on the phone. reMail downloads your emails directly via IMAP. No more reMail server.

What reMail Users Are Saying

We have beta tested the app with a lot of users, and they are loving it:
  • “This app is awesome! I use reMail constantly all day. It's so fast!”
    — Sachin Agarwal, Co-Founder, Posterous
  • “I am loving reMail!”
    — Richard Price, CEO, Academia.edu
  • “Complete Berlin trip organized via emails found by reMail. No printed reservations and tickets needed!”
    — Bernhard Heinzel, Beta User
  • “reMail is a super useful app and search speed is incredible.”
    — Dan Veltri, Co-Founder, Weebly

Get it Now

We hope you'll love it too. Get it now. It's $4.99 on the App Store until Sep 1, and $9.99 thereafter.

Update: Coverage here and here.

Labels: , , , , , ,

10 Levels of Communication Intimacy



Via Buzzfeed and @marissac.

Email seems to be exactly at the intersection of private and public.

Labels:

Tuesday, August 11, 2009

Dear Facebook, Please Let Me Reply to Your Message Notifications

Do you know this problem? Someone sends you a Facebook message. You want to reply, but instead of being able to just hit reply on the message, you have to perform a multi-step choreographed dance:
  1. Click on the link in the email
  2. Log into Facebook
  3. Navigate Facebook's messaging interface to reply
  4. Repeat this procedure when new messages roll in




This is hugely annoying. Instead of sending emails with a nonsensical address such as notification+pd=edfz@facebookmail.com and a Reply-To of noreply@facebookmail.com, can't Facebook just implement an email-reply-to-Facebook-message bridge? This is pretty simple to do - many Support systems (e.g. Kayako) already do this.

I've written (well, sketched) about Facebook vs. email before. When I have some time, I need to sit down and write my rant about how closed (Facebook, Twitter, Skype) and proprietary (Google Wave) systems are replacing email when they shouldn't. I think the underlying reason is that email's systems and protocols (SMTP, IMAP, MIME/RFC822, MS Exchange) are so hugely sucky, outdated, insecure, spammy, bug-prone, and stupidly designed. We need to engineer ourselves out of this mess.

Update: Wow, this post was just in time for Facebook's Message API, which makes the whole problem worse, not better: From the TC article: "The biggest addition — the Mailbox API — is also disappointing because it only lets users receive messages, not send them."

Labels: , , , ,

Friday, May 22, 2009

I need your IMAP Settings!

I'm planning to build an "IMAP Settings Directory" for an upcoming version of reMail Search, and I need your help!

Right now when you sign up for reMail Search, you need to manually enter your server settings. That means not only looking them up on your computer. You also need to type it in on the iPhone's small keyboard. That's painful.

In the next version of reMail Search, I want to take a different approach: You tell me who your email provider is, and reMail will pre-fill IMAP settings for you. I want to have this for the top 20 hosted email providers at a minimum.

If you're using a third-party provider to host your email, please leave a comment on this post with a link to their IMAP configuration page. This crowdsourced approach worked well for an Outlook-related request I had last year, so I'm going to try it again.

Here are two examples for what I want:
  1. Mailtrust IMAP configuration page
  2. Gmail IMAP configuration page

Labels: , ,

Monday, May 11, 2009

Launching reMail Search

Quick, what's the most annoying thing about the iPhone's email client? Yup, it's the lack of email search. That's why we built reMail Search for the iPhone. And we're launching a first version today.

reMail Search doesn't just search the subject, to, and from - it's full-text search of your email, on your device.

Even better, reMail Search works offline! You can search your email when you're driving through a tunnel or when you're in a plane. Our server syncs emails you're likely to search for on the device, and you can search them even when you're offline. When you're offline, you can search your entire email archives - with older search results coming from reMail's server.


We've built a lot of smart search features into reMail Search. The feature I use the most is initials search. Typing on the little screen is hard, and the most common type of search query is for people's names. Let's say I need to find an email from Jessica Livingston at YCombinator - I type in "JL", and reMail will suggest a search for "Jessica Livingston".

Sometimes you'll want to do advanced searches from your phone. Stuff like "Only search for everything from Paul that I got last week". If you type in "paul inbox last week", reMail will detect that "paul" is a person restriction, "inbox" is a folder, and "last week" is a time restriction. No advanced search dialogs or typing search operators.

For more, check out our product website at www.remail.com.

Labels: , , , ,

Friday, May 01, 2009

Facebook's Dream vs. Reality

Friday, April 24, 2009

Email Reply Behaviors

I found a great paper by Thomas Karagiannis and Milan Vojnovic at Microsoft Research Cambridge in my email this morning and thought I'd share some of the highlights with you.

In the paper, they surveyed email behavior in a large company, and analyzed how likely it was that emails will be replied to, and how long the replies would take. They looked at all the various factors - length of the email, number of recipients, time of day, and so on. I thought I'd paste in a couple of the highlights.

First of all, let's look at the relationship between the size of an email and average reply time. Anecdotally, I reply to short emails quickly, but if you send me a long email, you're going to have to wait for a reply. This is true in general:

Let's look at queue size vs. reply time. When I get lots of emails, some of them get pushed further and further down my inbox, and it will probably take me a while to get to them. This is a beautiful visualization of that effect:

Do replies get sent at particular times of the day? Heck yeah! The graph below shows time of day vs. replies sent, and you can see how they follow a clear awake / asleep pattern:


But a main takeaway for me is the following graph. I've always assumed that you'd reply faster to people above you in the company hierarchy - your manager would get replies faster than people at your level or below. You'd think you reply to Steve Ballmer faster than to Joe Intern. This does not hold true. On the graph below, dots to the left are "replies higher-ups", dots to the right are "replies to lower-downs". As you can see, more important people do not receive faster replies.


Here's the paper for people interested in more detail:

Behavioral Profiles for Advanced Email Features, Thomas Karagiannis and Milan Vojnovic, Microsoft Research, WWW-2009, Madrid, Spain [PDF]

Labels:

Wednesday, April 15, 2009

reBoxed is up!

reBoxedTry it now at:

reboxed.remail.com

reBoxed sorts unread emails in your Gmail Inbox by the importance of the sender. You start by voting on pairs of contacts - "whose emails are more important?". Your votes are then combined with your friends' votes. reBoxed's algorithm then sorts your inbox based on this input.

reBoxed is your inbox, sorted by your friends.

And we built all of it in just 75 hours. (Well, more like 77 - I needed an extra 2 hours to iron out some kinks at the end).

Labels: , ,

Friday, March 13, 2009

The Three Startup Email Modes

I'm very interested in how people deal with email, and have been watching my own behavior.

Since starting this new company, I've shifted into switching between three disjoint types of behavior:

1. Batch Mode Surrender

I love hearing from readers of this blog, or users, interesting people, potential investors, and the like. Strangely, even though I've been laying low in the past months, the volumes of all of the above have increased to the point where I just can't deal with all of it a timely manner anymore, which I feel really bad about. Because I keep these emails unread in Gmail, there is tremendous pressure I try to answer them. Thus once or twice a week I just surrender and try to process as many of them as possible in batch mode.

2. Constant Vague Anxiety

I spend most of my breathing hours coding, but every once in a while an email appears out of the blue that seems so important that in needs to be dealt with immediately. Sometimes it can be feedback from early users of our product, something work-related (like an exception stacktrace) that I know is holding up other members of the team. They have to be Answered Now, and just knowing that these types of emails will unquestionably keep showing up at random times of the day, I feel the need to check my Gmail about once every 30 minutes. Really, I shouldn't be doing that because it exposes you to emails that should be dealt with in Batch Mode, and creates that vague feeling of anxiety: I can't just LeechBlock my Gmail, but I can't keep it open all the time either.

3. Mobile Panic

When I wake up, or on the way to a meeting, or sitting in a so-so presentation, I pull out my iPhone and check my email. I should know not to do that. The mobile email experience is just so incredibly low fidelity: The emails have no context, priority, or structure. All those emails from (1.) are sitting there unread. It's easy to get overwhelmed and panic. The one thing that I absolutely need to stop doing is reading my email in bed in the morning. I can just feel how the clean fresh state of mind gets wiped and replaced with the noise du jour.

I guess that doing the hard, focused work that a startup requires really makes those email emotions come to light.

Labels: ,

Monday, January 12, 2009

Emails that make you Happy

Here's a random idea: What if you email client could show only emails that will make you happy? Email is a huge source of stress: All these emails from your boss, payment reminders, and project assignments – sometimes it's best just to ignore them. I propose adding a view that shows you only happy emails.


So how do you find these emails? Unless there is some magic natural language processing trick that I haven't heard of, I'd doubt that a content-based happiness filter would work. Let's just do it by sender.

People remember how you make them feel. The best way might be to just show the user a list of her top contacts, and rate her contacts. Like rating songs in iTunes, but more fun.


The inbox will now only contain emails from people that make you happy. The stress-free workplace is born.

Labels:

Tuesday, November 18, 2008

A Model of Your Inbox

I've been thinking a lot about how users view and manage their inbox. This post is about the model I came up with. I'm basing this on my own experience and on having talked to dozens of people about their email habits. But since this blog also is read by lots of email enthusiasts, I'd love to hear your feedback: Does this make sense? What am I missing?

Four Quadrants

Every single email message youreceive can be classified into one of the four quadrants below. Important emails are the ones you need to take action on. Urgent emails are time-sensitive. Urgency does not necessarily imply importance: Your coworker's cake will be gone in a few minutes, but it's not necessary to take action on that, especially if you're on a diet.


The key insight here is that the stuff you care about are the emails on the left. These are the emails that make it worth checking your Crackberry every few minutes. They emails that keep you awake at night.

Filtering the Important

How can you filter out what's important? My theory is that for humans, that's actually the easy part: You often easily determine importance by just looking at the sender of the message. Roughly, senders fall into three categories:
  1. Crap: these are easy to remove: iTunes Receipts, Amazon notifications, LinkedIn emails, frequent flier statements, and the like. Not important.

  2. VIPs: You know who they are! Major customers, your manager, and your girlfriend belong in this category. Important.

  3. People you know: These are the non-VIPs that you still want to deal with. I like to think of this category as the intersection of your Facebook and LinkedIn connections. Mostly Important.

  4. Everyone else: Recruiters and salespeople, senders you don't recognize. Mostly not important.

Research indicates that people use senders as their main importance indicator [1, 2]. The task of filtering out important email is easy, and you could probably train a classifier to very high degrees of accuracy.

Managing Later vs. Now

I believe that this is the heart of email overload. Remember how I said that the left side is what matters. I like to label the two subcategories as "Later" and "Now" [3].


The workflow should be that you decide whether you want to deal with an email now or later. You respond to the "now" emails and they disappear into the archive. The "later" emails haunt you until you're done with them.

This is the point where today's email clients fail. Users try various mechanisms to manage now/later and to do/done: Keeping emails unread, starring them in Gmail, and filing away stuff that is done into an intricate foldering system. The number of email management strategies that users come up with impressive [4].

But none of this works. Emails that are unread and starred disappear from your main view. Out of view, out of mind. Poof. There is no pressure to act upon them. In contrast, filing away emails that are done requires an amount of discipline that few users have. I think that the inability of managing now/later and to do/done is one of the main reasons for email overload.

Wrapping Up

Let's review. I've outlined three theories here:
  1. Your incoming all fall into one of the four quadrants of urgency and importance. What really matters is the important stuff, which breaks into "Later" vs. "Now".

  2. It's easy to filter important vs. not important.

  3. It's hard to manage Later vs. Now because the current tools are broken.


I'd love to hear your views on my theories. Drop me a line or leave a comment.

References


[1] Gina Danielle Venolia, Laura Dabbish, JJ Cadiz, and Anoop Gupta. Supporting email workflow. Technical report, Microsoft Research - Collaboration and Multimedia Group, September 2001.

[2] Olle Baelter and Candace Sidner. Bifrost inbox organizer: giving users control over the inbox. In NordiCHI '02: Proceedings of the second Nordic Conference on Human-computer interaction, pages 111-118, Aarhus, Denmark, 2002.

[3] The "Getting Things Done" school of thought has a more intricate system than this, but I think that Later / Now is the essence of it.

[4] Steve Whittaker and Candace Sidner. Email overload: exploring personal information management of email. In CHI '96: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 276-283, Vancouver, British Columbia, Canada, 1996.

Labels: , , , ,

Wednesday, November 05, 2008

Making up Emails for Mockups

When mocking up communications software, you have to make stuff up: You want to show a realistic inbox, messages that seem real, and clearly illustrate the use case you’re trying to support. Mockups help others grasp what you're building, and they help get you rolling on the prototype.



Photoshop and Corel Draw are my friends, and it's easy to find design inspiration on the web.

But how do you come up with the data? Some ideas:
  1. Use your own email. Duh. Sounds reasonable. But you don't want your confidential emails in your business plan. The girlfriend might not appreciate the shoutout. And startup founders’ emails do not represent a common use case.

  2. Enron Corpus. This is good for business scenarios, with some small problems: No attachments, no sender names (although you can make them up), and the depressing emails towards the end of the company: "Dear top management, please don't fire us now!". Use the Trampoline Enron Explorer to get to the data.

  3. Celebrities. Great for consumer email scenarios. My friends at Google used to mock me for including Natalie Portman in most mocks, but People Magazine is your friend: Just use your personal email and add celebrity names. Added benefit: If you choose the right celebrities, that will trigger positive emotions with people looking at the mocks.

If you have a more ideas, let me know.

Labels: , ,

Friday, October 17, 2008

"The Future of Email" Talk in Sydney

Yesterday, I gave a talk about my views on the future of email at CSIRO / Macquarie university in Sydney. Thanks to Andrew Lampert for the arranging and promoting the talk. Here's what it was about:

Mail clients haven't moved forward since the mid-1990s. Most applications have added superficial features, but the basics remained unchanged: Folders, lists of disconnected emails sorted by arrival time. Clients have no sense of priority, urgency, workflows, or connectedness. Their search features are simple and are sometimes painfully slow. Users today are bombarded with email and find popular email clients hard to use and inefficient.

How did we get here? How do we get out of it? This talk presents new ideas of improving the email experience for overloaded users.
I promised to put the slides online. Here they are (also on SlideShare).



I'd also like to thank the audience for the great discussion that ensued after the talk - I might post some of the best questions here at a later date.

A video of the talk is available on the CSIRO website here.

Labels: , , ,

Sunday, September 07, 2008

Upcoming Talks: Geneva, Sydney

I've been invited to give two talks while I'm traveling around the world:

  • University of Geneva, Switzerland
    Tuesday, September 16th 2008, 5 pm (Unitec Seminars)
    Auditoire du Rez, Bat A, Battelle, 7 rte de Drize, 1227 Carouge (map)

  • Macquarie University / CSIRO, Sydney, Australia
    Wednesday, October 15th 2008, 11 am (HAIL Seminars)
    Building E6B, Eastern Road, Macquarie University (map)

In both places, I'll be talking about the Future of Email and how we can improve email clients far beyond where they are today. I'll also chat about my experience with startups in Silicon Valley and what lessons can be learned from here. The talk in Sydney will focus on the former, the one in Geneva will focus on the latter.

I'd love to see you there! I hope both talks will lead to inspiring discussions.

Thanks to Andrew Lampert and Matthias Kuhn for organizing these talks.

Labels: , , ,

Tuesday, August 12, 2008

Delayed Sending of Email

Every once in a while, people pitch me a new feature for Outlook: "This is something I'd use every day!" For a large percentage of these, Outlook already does what they want, and it's just hard to find it.

A good example of this is delayed sending of email. Instead of sending the email when you hit "Send", you want to automatically send the email at a later time. Maybe you don't want to give someone the impression that you respond to their emails instantly. Or your press release goes out at midnight but you don't want to be awake at such a late hour.

This feature already exists. In Outlook 2007, it's called "Delay Delivery". When you're composing a message, click the icon in the menu bar, then check "Do not deliver before". In Outlook 2003, click "Options", then "Do not deliver before".



This is a great illustration of both Outlook's greatest strength and greatest weakness. I can easily imagine the corporate IT meetings in the mid-1990s where admins compared the feature matrix of Outlook to that of Lotus Notes, and decided to go with Outlook. Microsoft got everyone to use Outlook partly because it had a complete product with every feature box checked. On the other hand, it created a client with a lot of complexity, where every new release needs to carry the weight of the last one to assure backwards compatibility. Complexity leads to long cycles, and slow products. However, it can also lead to market dominance.

Labels: , , ,

Saturday, July 12, 2008

Enhanced Messaging Workshop at AAAI

I'm in Chicago for the AAAI 2008 Conference's Enhanced Messaging Workshop. Greg and I will be talking about some of the driving ideas behind Xobni, the hardships of building commercial email software. We'll also demo some products from our skunkworks.

I'm hoping that this workshop will hopefully fill an important gap: There are some conferences about spam fighting on one end, and general machine learning / data mining / user interfaces on the other end, but no forum for academic discussions of fighting email overload. See you there!

Labels: , ,

Monday, June 23, 2008

Book Review: Send

Send is a refreshing book. In email research and email software startups, we spend our time coming up with better ways of displaying and organizing email. In this book, David Shipley, Op-Ed page editor of the New York Times and Will Schwalbe, a journalist and editor, discuss the other part of the equation: The humans behind those messages.

Send shines the light on emotions and motives: The emails that are sent to create the impression of progress. The passive-aggressive messages you send when you feel like you’ve been wronged and, more importantly, how to avoid them.

At parts, the book reads like "Email for Dummies", but there are some highlights: I shiver when people send me subject lines like "Quick question" and "Great News", when they should have written "Release date for next version?" and "Expenses approved". This is the book you want to hand out to the guilty.

I'm already wondering about how to put this into a product: Could we make software that orders people to rewrite the email in a more effective manner? It could pop up "Your subject line sucks" and make you rewrite it before you send. Could we find out the mood someone was in when sending a message and display it alongside the email? Food for thought.

Disclosure: I didn't buy this book - I found it in my snail mail one day, and I can only guess that the authors sent it to me. Keep'em coming - this is a good way to get your ideas read by the email community.

Labels: , ,

Monday, June 16, 2008

"Email Sins" on NPR

NPRThis morning, National Public Radio ran a story about how people are feeling crushed by the volume of email they receive. In the story, NPR's Yuki Noguchi interviews Joel Cherkis of Microsoft, John Kremer of Yahoo, and me. I chat about how new ways of looking at email, such as Xobni's people-centric view, can help us tame the email flood.

NPR: E-Mail Sins, Horror Stories and Strategies - "Make It Stop! Crushed by Too Many E-Mails"

Labels: ,

Monday, May 05, 2008

Hello, World: Meet Xobni

This is the first of a three-part series on the Xobni launch. Come back on Thursday to check out Part II of the story. This series was co-written with Marie Baca.

Every day, millions of people are forced to deal with the inefficiencies of Outlook. Almost 50,000 people have tried the early versions of Xobni's private beta. Today, we are opening the floodgates and allowing anyone to download a beta version of Xobni's eponymous product for free.

You can read our official announcement here. The New York Times details our launch in this article.

I've devoted this post to explaining why we built Xobni's software the way we did. The other posts in this series will document the journey up to the launch.

Email Overload

Experts say that there are two types of email users: Cleaners and Keepers. Cleaners receive only a few emails a day, and they meticulously file each email into a specific folder. Keepers, on the other hand, receive copious amounts of email, and although they may start out with a good organizational system, it is quickly abandoned. We designed Xobni for the Keepers — the everyday people who need a product that will help navigate their flooded inbox.

The average Xobni user deals with a whopping 30,000 stored emails and communicate with some 1,900 people. For many, this means sifting through several hundred messages every day. It’s only going to get worse: the Radicati Group estimates that by 2009, people will spend up to 41% of their workday dealing with emails. We are experiencing bona fide email overload, and the challenge for us "power users" is to find a way to process and organize large volumes of information over a short period of time.

A People-Focused System

One of the key insights the Xobni team had early on is that users think about email in terms of people and relationships, not abstract tasks. For example, think about the last time you went hunting through your inbox for an attachment. What was the subject line of that email? Can’t remember? Well, what about the name of the person who sent it to you? I bet that you were able to recall that bit of information far more easily. Indeed, the majority of searches inside email clients are for names of people, and it’s those same names that help us identify the relative importance of a particular message. It’s this idea of a people-centered email system that drove nearly every aspect of our development process.

A Smarter System

Let’s take a look at a few of Xobni's features and discuss the rationale behind them.

  1. Super-fast email search. Other than acting as a holding pen for messages, one of the most important functions an email client can perform is allowing the user to quickly search through your emails to find the information they’re looking for. It's such a fundamental need, and yet Outlook’s search is often painfully slow. That’s why we designed Xobni with as-you-type search, so that as soon as you’ve typed "Jan," Xobni has already pulled up all the emails from Jane Smith, as well as all the emails where she is mentioned.
  2. Threaded Conversations. Research indicates that one of the biggest problems people experience with their email systems is being unable to put their messages into context. In a standard inbox, messages are sorted by arrival time, which adds very little meaning to what is being said in the body text. Gmail has an effective method for grouping emails, and with the advent of Xobni, Outlook will also have this ability.
  3. A Built-In Social Network. Just as it is easier to remember who sent you a message than it is to remember the subject line of a particular email, it's much easier to recall relationships between people than it is to remember a name. For example, one of our investor's names is Rob. I can never remember the name of Rob's assistant (sorry, Carly!). For this reason, we designed Xobni to analyze emails and automatically create a network of relationships around each contact. Now when I pull up Rob's name, Carly's name appears on his list of related people, and I can call or email her with the click of a button.

Research vs. Reality

If you take a look at the research that has been done to improve the usability and usefulness of email clients, you'll find that a lot of the work was performed at Microsoft Research. But these ideas haven’t yet made it into Outlook. It's difficult to change Outlook because the improvements have to be compatible with all of the previous versions of the software. Meanwhile, rebels like us are free to build the next generation of email clients, making them faster, smarter, and easier to use.

Be sure to check back next Monday for Part II of this series, where I’ll tell you about a big mistake we made early on: building the wrong product.

Further Reading

  • In my thesis, I review significant research into improving the UI and smartness of email. Chapter 2 gives you more insight into email overload, and Chapter 3 lists a lot of work done in this area.

  • For more background on interesting email-related research ideas, read my earlier blog entry, "How Researchers are Reinventing the Mail Client".

Labels: ,

Monday, March 24, 2008

Arrington on Email Overload

Michael Arrington has a post about email overload on TechCrunch today. A lot of people feel overwhelmed with email: Too many emails, from too many sources, coming in at a faster pace than what you can deal with.

I stumbled on this problem in 2004, while working on Gmail. It is a fascinating space, in which we're stuck in a dilemma of email clients that haven't changed in 15 years and weren't designed to do what they're dealing with today. On the other hand, there is an abundance of academic work trying to address the problem: Just read "How Researchers are Reinventing the Email Client" or my thesis on organizing email.

Even with Xobni, we're only scratching the just the surface of this problem, and there is still so much opportunity out there to improve the email experience for users. It's a huge market with big, established players, ripe for a revolution. Thanks, Arrington, for keeping this on everyone's minds.

Update: An interesting comment from the man himself (#74): "I didn’t quite write this post the way I intended to. There are lots of startups addressing the email problem, one of my favorites is Xobni. I’m thinking of something significantly more revolutionary than fixing email. Like a new way of communicating entirely."

Labels:

Wednesday, March 12, 2008

Does your Outlook speak a Foreign Language?

If you have a non-English edition of Microsoft Outlook, I need your help!

Here at Xobni, some of our algorithms and heuristics rely on Outlook speaking English. Unfortunately for our software, but fortunately for us, a very significant percentage of our users work with non-English versions of Outlook.

Since our Pirate Testing Lab and our impressive farm of happy virtual machines contains only English-language Outlook installs, I need your help.

If you have a non-English edition of Outlook, please leave a comment with the following:
  • Your country, the language, and version (2003/2007) of your Microsoft Outlook
  • The names that your edition of Outlook uses for:
    1. Inbox
    2. Outbox
    3. Sent Items
    4. Deleted Items
    5. Drafts
    6. Junk E-Mail
    7. RSS Feeds
    8. Search Folders
    9. Calendar
  • The prefix that your Outlook adds to the subject on an email you reply to. For example, in English this is "Re:". In German this is "Aw:". In Italian, this is "R:"
  • The prefix for "Reply All". In English this is "RE:"
  • The prefix for "Forward". In English this is "FW:"
  • (Extra credit): The prefixes Outlook uses when someone accepts or declines your appointment, or sets attendance to tentative. In English, this is "Accepted:", "Declined:" and "Tentative:"

Thanks so much – your help is greatly appreciated!

Labels: , ,

Monday, December 17, 2007

Faster chips? Or better software?

Craig Mundie, Microsoft's Chief Research and Strategy Officer in today's New York Times article "Faster Chips are Leaving Programmers in their Dust":

In the future, Mr. Mundie said, parallel software will take on tasks that make the computer increasingly act as an intelligent personal assistant.

“My machine overnight could process my in-box, analyze which ones were probably the most important, but it could go a step further,” he said. “It could interpret some of them, it could look at whether I’ve ever corresponded with these people, it could determine the semantic context, it could draft three possible replies. And when I came in in the morning, it would say, hey, I looked at these messages, these are the ones you probably care about, you probably want to do this for these guys, and just click yes and I’ll finish the appointment.”

We have the processing power to do this today, and do it on-the-fly, not overnight. What we need is better email software, not faster chips.

Processing power will clearly remain a problem for some time to come, but Mundie's example is one where the problem lies with building those "smart assistants", not adding chip horsepower.

Labels: ,

Tuesday, December 04, 2007

The Definition of Inbox 2.0

A friend recently asked me to explain the buzzword "Inbox 2.0" he'd heard about. Here's the definition:

Inbox 2.0 == Using data in email archives to infer people's profiles, behaviors, social graph, and importance, and making this information visible in your email client.

Let's pick this definition apart:
  1. "Using data in your email archives": There are mountains of hidden data in your email archives, whether locally on your machine or on the server. Inbox 2.0 takes your gigabytes of past email, generates statistics, and applies machine learning and natural language processing techniques to find useful conclusions.

  2. "people's profiles": The information in your email paints an accurate picture of your contacts. You can extract their address, phone numbers, their job title, and interests.

  3. "behaviors": Your contacts' email stream allows Inbox 2.0 software to infer what time of day they're usually online, when it's best to send them email, and how soon to expect a reply.

  4. "social graph": It's easy to extract your social network and social graph by looking at who's Cc'ed on emails, who's mentioned, and how often they're included in conversations.

  5. "importance": More important contacts get more of their emails answered faster, and are mentioned in emails to other more often. Their social graph includes other important people.

  6. "and making this information visible in your email client": Users want this information as they're triaging and writing email, not as a standalone application. While the data can come from anywhere – local email archives or your trusty Exchange server - integration into the email client is key, whether it's a desktop client like Outlook, Entourage, Apple Mail, or Thunderbird, or a webmail client like Hotmail, Yahoo Mail, or Gmail.
The term Inbox 2.0 was originally defined in a New York Times article by Yahoo SVP Brad Garlinghouse, and has been discussed by Om Malik, Don Dodge, Deva Hazarika, and Kevin Delaney at the Wall Street Journal.

--

More posts on email:Also, academic email research is discussed in my thesis: Organizing Email. Happy emailing!

Labels:

Friday, August 03, 2007

Facebook: Email me Instead

Does this look familiar?



AN-NOYING! Why should you need to go to Facebook to read Matt's message?

Matt and Bryan (and to a smaller extent, yours truly) spent a weekend hacking up "Email me Instead", a Facebook application that lets people, well, email you instead.



Get it here.

Obviously, this isn't Xobni's long-awaited killer product. You'll have to wait just a little bit longer.

Labels: ,

Wednesday, January 31, 2007

Hawaii

I'm in Honululu for the 2007 International Conference on Intelligent User Interfaces. It's been very interesting so far and I've seen some great presentations. Also, this conference sure is in a good location!



My talk tomorrow will be about the upcoming BuzzTrack, a system for topic-based email. You'll find more information on it here, and (hopefully soon) here. I'll also spend some time reviewing work on improving the email interface, which I've written about before.

Labels: ,

Friday, July 07, 2006

How Researchers are Reinventing the Mail Client

For the last 10 years, the three-pane has been the standard view of looking at email. A pane for folders, a pane for folder contents, and one showing the selected email. Even though mail clients are highly configurable, this has been the standard view of many users. It isn't likely to change soon: The beta of Microsoft Outlook 2007 – pictured below – sticks with conventions.


Email today has many annoyances. Even though we now seem to have a grip on the spam problem, many users are suffering from email overload: There are just too many emails flooding the inbox. Many are drowning in heaps of emails that aren't even important – it's just a colleague at work Cc-ing everyone evenly remotely connected to his project.

There are plenty of ideas on how to improve the current state of mail clients, and I'll present some of them here. None of this is my work: I'll give references to publications of others. There are literally hundreds of papers on this subject, so I've chosen to present my selection of personal favorites.

Here are the three ideas I'll present:I'll present one example from each category.

Task-Driven E-Mail Organization

People's lives today are organized in their mail client. It's not just communication that takes place here: Meetings are organized, lists of todos and deadlines are exchanged, documents are sent around.

In effect, what you're keeping track of in your email client are tasks. Most emails you get are part of some project, belong to an event you're attending or organizing, or are part of a greater plan, e.g. keeping in touch with a girl.

That's the idea behind TaskMaster [2], a tool developed at PARC in 2003. All your emails, drafts, attachments, and bookmarks are mapped to "thrasks". Emails in the same thread are grouped automatically, but the user still has to assign other mails, links, and deadlines manually.

Thrasks can have associated actions, such as "call this person", and "review this". You can also add deadlines to each task: they are shown as green and red bars as they approach. Documents can be previewed right inside TaskMaster's UI, as seen with the Word document on the bottom.



I think the great advantage of this approach is that items that belong together are displayed together. Instead of using email folders to hold related messages, the central element is the task, with all the associated deadlines, todo items, and documents.

Here's a quip from the paper's usability interviews:

"It's just nice to be able to have the control over mixing [...] related things together, even though they might not be [...] the identical kind of thing."

What if we went a step further and looked at workflow patterns? For example, at a company where you interview candidates in a formal hiring process, you get automatically generated messages reminding you of the interview, requesting feedback after the interview, and a notification of the final decision. In the future, we might be able to automatically identify the structure of such processes [4] and classify email into these activities [5] – both of which goes beyond Taskmaster's model, which requires some manual effort.

Creating Smart Organization Structures

Almost everyone I know keeps incoming email entirely in the Inbox. Newly arriving messages join the 500 messages already marked as unread and are displayed at the top of the pile. Is there a better way to organize this view? Can we sensibly restructure incoming mail?

Bifrost [6], a plug-in originally conceived at Lotus Research, that takes this approach. The idea here is that the people are the main indicators of whether an email is important. After installing Bifrost, you're asked to sort your contacts into five groups: Your own email addresses, "VIP Platinum" (extremely important people, e.g. your manager), "VIP Gold" (important people: friends and family), as well as small and large distribution mailing lists.

Bifrost then reorganizes your inbox and displays your email in a number of predefined categories:
  • Timely: Emails that contain today's or tomorrow's date in the subject line. They'll likely be important today, but not next week.
  • VIP Platinum: emails from your manager.
  • VIP Gold: emails from friends and family.
  • Personal: replies to emails you've sent out, emails sent directly and only to you, and any unclassified emails you receive.
  • Small distribution: Intended for group messages.
  • Large distribution: Large-distribution mailing lists.
Below is a mock up of what this looks like in practice. (I had to draw this up myself as the screenshots in the paper were too small).


This structure is helpful in identifying important messages and weeding out the less interesting ones. A quote from their user interviews:

"If I am running through an inbox, I might be tempted to read a title and get sucked in because it is interesting. Whereas if it is in a pile of listserv stuff, I just ignore it altogether. That was a nice thing when I was busy, to not get distracted by unimportant mail."

It's interesting to note that except for differentiating small and large distribution messages, this approach can already be replicated in today's email clients. You can simply create search folders or message filtering rules which simulate the Bifrost behavior. However, this would put emails into folders and wouldn't offer the one-page overview that Bifrost has.

Cool New Features

ReMail [7] was a project at IBM Research that ran from 2001 through 2004. It was basically a reimplementation of an email client from the ground up and had several cool new features. I'll describe two of my favorites below.


Thread Arcs visualize relationships between email messages. Instead of wasting lots of space with a tree view that Thunderbird has, it displays the thread structure in a little image. This feature helps you see where you are in a long conversation. For example, in the picture below, emails B, C, D, E, F, and H are all direct replies to A, while email G is a reply to E.



The advantage of thread arcs is that you can see the position of the email you're viewing in the larger conversation, without having to switch to a tree view: your main inbox pane remains sorted by arrival time.

Contact Maps offer a different view of the address book: Senders from which you have received email are grouped by domain. Each person's name is shown with a different background color, depending on the time of the last email exchange. This offers a better view of your contacts than the traditional non-grouped lists where your least important contact looks just like your most important one.



Many of ReMail's other ideas can be found in today's popular clients: Instant messaging is now integrated with Gmail, which also groups emails by thread. The collection mechanism in ReMail is semantically equivalent to Gmail's labels. Outlook integrates emails and calendaring and has list separators ('today', 'yesterday', 'last month'), just like the ReMail prototype.

Conclusions

It seems like the ideal email organization tool would be like your personal, smart secretary: It knows what's important or interesting, and deals with stuff you don't want to be bothered with. That would be perfect.

Today, we seem to be at a point where it seems like we might be able to solve the spam problem. But the problem of figuring out which of the non-spam emails is important, and what it relates to, still exists.

One solution – the one I presented here – is to add nifty features to the mail client. But would all these features really be understood and used? Users today seem to be using a very basic set of mail client functionality. Anything we add should not only solve a painful problem, but also be easy to use. I'm not even sure this applies to the applications I've shown here: You don't know until you've tried.

What do you think? Are these good ideas? Would normal people who are drowning in email use these features? What features can't you live without? Post a comment and let me know.

--

Thanks to Keno Albrecht, Bálint Miklós , Markus Egli, and Fabian Siegel for reviewing drafts of this.

--

References

A more thorough and academic overview of the subject:
[1] Steve Whittaker, Victoria Bellotti, Jacek Gwizdka: Email in personal information management, Communications of the ACM, 2006

Examples of task- and activity-based systems:
[2] Victoria Bellotti, Nicolas Ducheneaut, Mark Howard, Ian Smith: Taking email to task., CHI, 2003
[3] Michael J. Muller, Werner Geyer, Beth Brownholtz, Eric Wilcox, David R. Millen: One-hundred days in an activity-centric collaboration environment based on shared objects, CHI, 2004
[4] Nicholas Kushmerick, Tessa Lau: Automated email activity management: an unsupervised learning approach, IUI 2005
[5] Mark Dredze, Tessa Lau, Nicholas Kushmerick: Automatically classifying emails into activities, IUI 2006

Bifrost:
[6] Olle Bälter, L Sidner: Bifrost inbox organizer: giving users control over the inbox, NordiCHI, 2002

ReMail:
[7] ReMail: Reinventing Email Website, Collaborative User Experience, IBM Research, 2003

Labels: , ,