We can divide the mails we receive in our mail box into multiple categories. Some are personal messages. Some, however, are automatically generated notifications. It’s therefore amazing no one (Apple, Microsoft, Google) actually integrated mails to their notification systems.

If something is really annoying, these days, it’s when, after you actually receive a notification on your phone to say someone did something on twitter, you find in your mailbox an unread mail about the exact same event.

Wouldn’t it be possible for our mail system to be tied to our notification system or our service provider to automatically mark as read notifications we already saw?

Furthermore, wouldn’t it be possible to actually use mails as notification source on our phone? Most of us receive our mail in push so it wouldn’t be so much slower to use mail notifications than relying on a custom notification service.

Mail intents, a way to give context

My proposal? To add two headers to our notification mails and newsletters in order to give the mail client more context about them.

 

Intent: ( discuss | broadcast | notify | inform | check-mail | … )
Default value: discuss

Meaning of the values:
- discuss: mail sent from person to person, or not properly categorized
- broadcast: mail sent from person to people (mailing lists, groups…)
- notify: mail sent automatically in response to an event
- inform: mail sent automatically on schedule or in response to a sum of events
- check-mail: mail sent to verify user identity

 

As you can see, the ‘Intent’ header is very generic and only provide a clue about the intent of a mail. However, this simple categorization can already by useful.

Naturally, no mail client should suppose that the sent intent is the real one as mistakes can happen (and spammers may try to mess things up). However, this would be a good way to make Hotmail’s automatic categorization better by default.

A mail client can also decide to present different user interfaces for different kind of mails. For example, it could add a “confirm” button on the quick actions for check-mail emails, so that the user doesn’t have to actually open the mail to confirm its mail address.

An always up-to-date email

The second one is trying to give more information about the notification source:

 

Source: https://example.com/notifications?6d6a5f1afe8716a9ce12bb52eb
Default value: about:invalid

Meaning of the value: the specified value represents an unique identifier for the mail; in case this is a valid URL, it can be pinged to retrieve up-to-date information about the notification.

I propose that mail clients only send a HEAD request to the URL to get up-to-date information, while a GET request would allow real people to “open” the mail or notification online.

 

This header could be used to “refresh” an email just like you could “refresh” a webpage.

By default, mail clients would not follow those links but they could ask the user to “trust example.com” (or use a server-side white list), in which case all links pointing to “example.com” could be followed automatically.

The links could be followed for multiple reasons: when the email is received, when it’s opened or from time to time, as long as it’s unread. The exact timing of the update requests would be determined by the mail client.

Also, if the mail client is connected to the “example.com” social network, it can check if the notification whose ID is specified has been marked as unread or not and react accordingly. It can also choose to display the notifications in a special area of the user interface.

Multiple emails sharing the same “Source” could also be consolidated into one email, the mail client just marking the initial one as ‘unread’ when a new email come with the same source, while updating its content.

This could also be used when you notice a mistake in a mail (forget an attachment…), to allow compatible mail clients to consolidate the fix with the initial mail.

Real-world implementations

The idea of always up-to-date emails has already been scratched by Microsoft and Google in the past; with no standards on the matter, however, it’s very unlikely to succeed to gain large scale support and it will stay reserved to a small amount of websites.

I can’t deal with that as I want this for all my notifications and newsletter for yesterday :-)