Tag: mail

We get all kinds of email, and not just spam and everything else. Some email is just notifications, like a library book is now available for pickup, or one of your coworkers has switched  from ‘no’ to ‘maybe’ on a calendar invitation, or a task is now overdue in your team’s task management solution. Some mail is really subscriptions, like newsletters or emails telling you that the newest issue of Brooklyn Hipster Gazette is ready for downloading. Some mail has attachments, and a lot of mail can’t be responded to right away but you don’t want to forget to deal with it in a timely fashion.
The naked experience of Gmail, or other average email clients, does not really help to deal with these different sorts of email differentially: the average email client doesn’t distinguish. It’s all the same with them. Oh yes, they’ve provided ways to filter based on who the email comes from, or the like. But that only solves the smallest bit of the problem.
And since it looks like we are going to be using email for a long time (as I wrote about yesterday in Why we will be using email for at least another 50 years), it would be great if there were a bit more innovation in email.
For several years, I have been using task management tools that closely integrate with Gmail, providing at least one part of the puzzle. Todoist is such an app. It is a solo task manager — supporting no sharing of tasks — but works as an appliance (a Chrome plugin) on top of Gmail. When I am reading an email that I need to defer a response to I can click on ‘Add email as task’ and Todoist pulls the id of that email from Gmail, as shown below:

Note that the ‘@’ sign is used to indicate tags in Todoist, useful in searches. So, for example, I could search for all library tasks — like returning books — before heading over there.
After clicking on the ‘Add task’ button, the task looks like this:

The tags are shown in green (here just one) at the left hand side, then the email icon, the link based on the subject of the email, and then the text I added. Clicking the link leads to the email be reopened, even if it has been archived, which helps me keep my inbox cleared out.
There are many other features of Todoist worth reflecting on, but it is just this one feature that I am focused on. Indeed, it is that feature that makes it an invaluable tool for me. I formerly used Remember The Milk, which has a similar integration with Gmail, but for a variety of other reasons I switched to Todoist, despite the fact that it is single user and Remember The Milk supports task sharing.
At any rate, I can’t imagine going back to a naked email client which does not have this notion of some sort of task system integrated with emails.
.Mail
There is a new project in the works that seems to be headed in that direction, called .Mail. This development effort grew out of a conceptual design undertaken by Tobias Van Schneider, which is now accepting sign ups for the beta. Along with a clean reconsideration of the aesthetics of email — which includes pulling out emails that are just notifiers and making them notifications, and dealing with attachments in a smart way —  .Mail will be incorporating Action Steps:

Here you see Action Steps, a prioritization approach, based on clicking the left most region of the email header. As the small print says,

First thing in the morning, you organize and prioritize your unread emails. Sort out what’s important and what’s not. When you mouse over the email, those 3 red squares slide in fromt he left side and give you the option to add this email to your “Next Steps” list. Depending on which square you click, you give this email a [different] priority.

And What About Sharing?
In essence, .Mail is implementing a more integrated version of what I am doing today with Todoist and Gmail (leaving aside the notifications and clever management of attachments, for a moment). But what about coordinating with others in your workgroup? Imagine I get an email in .Mail with a cc to David Card, my colleague at GigaOM Research, who is also using .Mail. Perhaps I’d like to ask David a question before responding to the email. What I’d like to do is treat the email as an object and then have a private comment thread with David about the email.
Today the typical pattern is to create a second email exchange to discuss the first email, which has a number of problems: the first email is either out of context, or gets embedded in second by forwarding or by pasting as text. All these options are bad, really.
Besides, David and I talk all the time, and we share tasks frequently. So I don’t want to communicate with him in the email lowest common denominator form factor.
Or taking it a step farther, imagine that I want to punt on the email, and assign the response to David. In a naked email world, I’d indicate that through another email. But in a hypothetical next gen version of .Mail, I could simply assign the response to David, after attaching a comment, and perhaps an attachment for him to review. Note again that the comments and attachment in this scenario are meta data on the email thread, but not emails themselves.
Final Thoughts
I haven’t seen the .Mail beta yet, and I am spinning a great deal of wheat where it might wind up being chaff. However, I think that the key idea I am outlining — treating email as a social object, to be shared, commented on, and attached implicitly or implicitly to tasks — has real legs.
So, yes, we will still be using email for decades to come, and some people may continue to use naked email clients, but I am betting that social email will become the dominant approach in the near future, especially in the business context. It preserves the best of the naked email model: namely, anybody with an email account can email anyone else with an email account. And at the same time, social email opens the door for additional, side channel communication and coordination around the subjects embedded in the email text with your coworkers.