I just read the introduction to .Mail, a new email concept, and came up with some thoughts of my own on how email clients should evolve.

What email clients lack is that they don’t meet the needs of the information being communicated within messages. For as long as I’ve been using email the information objects in email clients have been: Message, attachments, & calendar invite.

Email clients haven’t grown past distinguishing these three core objects, and Instead of getting smarter about our messages clients have built out functionality and complexity sets around them. They’ve have made working with email and the job of understanding what each message means more difficult by giving users the additional tasks of managing their emails and their system.

The key to a better email system is to respect the richness of the data within the message. .Mail follows in Sparrow’s footprints with a very clean interface, and integrates with Facebook to let users see their contacts images. .Mail takes Sparrow’s approach one step further by showing brand icons for messages you receive companies like Twitter and Amazon. Many of the emails I get come from newsletters or notification emails, and having a clear brand icon next to each message would be as useful as seeing the faces of my personal friends. It’s a nice way to connect with the sender, to get some context for the message, and to quickly filter out what’s important or not.

Calendar Invitations and Attachments

Have you ever had someone invite you to an event via email, but didn’t include a calendar invitation? When friends invite me to events over email and ask me to reply with my attendance, if there isn’t something I can click “Accept” or “Decline” I usually just ignore the invitation altogether.

Attachments are the only other kind of data email clients handle. What Sparrow introduced to email clients was an integrated system of including multiple ways to attach files. With Sparrow you could include a link to a file hosted on the cloud (using Dropbox or CloudApp), or as an embedded attachment all through drag and drop. Attachments get lost over time though, and most clients don’t have a good way of managing that problem. Maybe .Mail’s solution could help here too.

Action Items

There’s so much more information encoded in email messages than just calendar events and attachments though, especially at work.

Think about the emails you get at work that are asking you to do something. It’s common for requests to be hidden within multiple paragraphs of text. While the person who’s writing the email knows exactly what he wants the you to do, you have to read over the entire message and piece together what the requested action item actually is. What you come up with my not be what the sender wanted either. The action item you create from the message might misinterpret the request, or you may misread a deadline of “Tuesday” as “Thursday”. Also, if you don’t write that action item down or enter it into another system, there’s a good chance you’ll just leave it in your email and forget about it.

It would be much more effective if that action item could be defined as its own entity. Imagine attaching an action item to an email. It’s associated with an email, and the action items included are explicit, clear, and ready to be sent to a dedicated system like OmniFocus. The result of a system like this could include faster email processing, less confusion about commitments and having a better state of control.

Still, the .Mail Action Steps system is a big improvement over no system at all. It looks like a very nice way to integrate into people’s email workflow, and it makes it easy to identify priority items.

The Way We Work

Today’s email clients don’t reflect the way we work. They don’t do a good enough job of recognizing the world outside of their own systems, calendar invitations, and file attachments. email clients all bias towards complexity in managing multiple accounts, mailboxes, spam, contacts, folders and labels. It doesn’t reflect the way we communicate, or what we communicate.

Building off of current email clients can only lead to more complexity. The need to start from scratch is clear if we want to be able to use beautiful, simple and functional email clients.