The third type of email: external things

Hey all,

There seems to be a lot of great posts around the forums about ideas for improving experiences so I thought I'd share mine about how I feel email needs to go beyond text. It's really an extension of the .Mail idea by Tobias van Schneider.

I've been thinking about how emails contain references to external objects such as e-tickets or courier information but sadly we have to dive through emails when we actually need them. There isn't a good way for emails to automatically bump to the top or notify a user when the external object state such as a courier delivery or a flight becomes relevant or changes.

It's in a blog post but I'd rather not subject you guys to having to click through just to view the content so I've pasted the post below.


I was reminded to revisit the [.Mail concept by Tobias van Schneider]( and it got me thinking about the third category of emails where they don't quite fit into actionable tasks and they aren't really things you want to revisit later.

References to external things

Flight e-tickets, courier tracking numbers; these are the sorts of things I don't particularly want an action for but rather have them become useful at their declared date.

An email is now more than just a collection of text, it's used as a referenced to external objects (hyperlinks) but why should we jump from an email client into a website to extract information that could have been embedded in the email. What if that email was live, those external objects behind the email were being updated inside our email client and we didn't have to click through?

And why should something that may not be needed now but needed later be buried underneath newer emails?


In the case of an e-ticket I want it to setup a reminder for me to leave for the airport and I want it to become useful when I'm in the airport. This sounds like Passbook but unlike Passbook it doesn't require any action or handling of special .pkpass files; the client recognises an e-ticket and organises it appropriately without you having to manually invoke a workflow.

Passbook currently extracts that e-ticket and stores it in a segregated data store (iCloud), meaning you're out of luck if you're roaming and have access to a internet cafe but no WiFi for your iOS device. The e-ticket (metadata in the email) should be stored with your email so when you visit Gmail/iCloud/Outlook online in a cafe you should be able to see a richer email with details about your flight, changes etc

Courier tracking

But I'm more interested in the courier tracking numbers, these only become useful after a few days but after a few days you have to hunt through your emails to find that tracking link. A mail client should be capable of subscribing to this courier tracking number and polling for updates, when the package is in your city you should be subtlety notified but when the package is out for delivery your mail client should delivery a notification to you.


Maybe it shouldn't be polling that the mail client has to do, maybe email providers should be pushed updated meta-data for a specific message? To establish the push link

* The mail provider sees an email with external objects

* Communicates with the external objects provider, declaring this how you can reach me

* The external objects provider can then push updates/events to the related mail message

By using the email provider we don't have the issue of OS X doing its own thing with the provider, my iOS device doing its own thing etc. They are just receiving the information from the middleman email provider.

From there a company like Emirates could push a generic event that contains a date & time (okay awesome let's create a calendar event) or they could push an important notification (okay we may need to update the calendar event and flag the mail to the top regarding a flight change).

A company like UPS could push a notification (a casual bump for that message that the package is in my city) and another important notification (flag the email and send out a push notification).

There does come the problem of spammers having an essentially having a richer way to spam you, so we might have to look into human verification where we have an established list of services that are trusted for pushing to email providers. Again the email provider can chose to blacklist bad push providers.

What are we achieving here?

* We aren't diving through emails to find things when we need them. Those emails are presenting themselves when circumstances change and becoming useful when we need them.

* We aren't locking the richness of an email to something like passbook on an iPad or iPhone, we are letting an external or web mail client be just as useful. And we are letting people move between Android, WP8, iOS without locking away important rich content

* We are turning email into an important organisation tool