In his article, Jason has asked why our email software isn't smarter. He poses several scenerios, explaining how each message has context and meaning which could easily be embedded into the email itself.
While I personally prefer text-only, I'm guessing that the vast majority of email messages these days are in HTML. My question is, "Why not use Schema.org semantic markup vocabularies inside the email messages?"
Implementation would be almost seamless, as most email applications already incorporate HTML parsing engines. Not only could the application extract metadata about the email, but they could also use the semantic vocabularies to help us write our emails.
Most email clients already have usable filtering systems, which could be leveraged to give the individual user control over how their client treats messages containing any given vocabulary.
Allow me to pose a few examples:
Many of us geekier types are probably subscribed to dozens (if not hundreds) of development notification lists, etc. Most of the time, these messages do nothing more than keep us up to date on the project, new releases, etc.
When you look at these types of messages abstractly, you'll quickly realize they are nothing more than a blog which is being served to you via your email application instead of a standard website. The downside is that your email client doesn't know what a blog is, and can't give you the structure that a true weblog does.
Thus, these updates could be marked up using the BlogPosting vocabulary. If that message happens to include information about a new software release, the SoftwareApplication vocabulary can also be used.
As a hosting provider, I receive dozens of messages each week reminding me to renew this domain, or pay for that virtual server, etc.
Or, in the case some reminders I have been getting the past few weeks, the event coming up is a concert, which can be describe by the more specific MusicEvent.
Sometimes, I migrate domains to another registrar - a process I initiate with a transfer request from the new registrar to the old registar. Generally, both registrars will send me an email asking me to confirm my intention to migrate the domain. With a little bit of markup, these emails could trigger notifications, so that I can address them the moment the come in, instead of having to rifle through my inbox looking for the actionable links to click.
Being a geek, I purchase a number of things online, often based on pre-approved recurring billing agreements. For example, for one of my hosting servers, I get a reciept each month saying that I have successfully been billed $###.## for the month.
My biggest complaint about these emails are:
- Unpredictable format -- every company/vendor has their own format for the emails, so I spend more time than needed simply to figure how where to sort the email to. Some companies have different formats for different services -- which is downright evil.
- The upsell -- most vendors also include blurbs about other services, trying to upsell me. Not only does this waste some of my time every message, but it distracts from the reason for the email - their legal obligation to notify me they executed the payment agreement. Oh yeah, did I mention the bloating of the message?
The email comes to me because I am the admin for the service, but in reality, the email is only useful for the accountant. With the right metadata, I should be able to configure my filters to forward that email to my accountant, and her email client chould be able to extract the vendor, the product, and amount, and the date period the reciept applies to.
Even if the email client can't push that data into the accounting software, it could render the information in a predictable manner, saving the accountant much time when inputting into accounting software.
So far, I've only mentioned emails which are usually generated by software, making it very easy to embed markup by simply updating the email templates and/or the generator engine.
What about manually written emails?
In business, certain types of emails should always contain particular information. (I'm sure someone has published a guidebook on the matter somewhere.)
For example, when sending invoices to clients, I attach the invoice as a PDF. I also try to remember to put certain information in the email body itself:
- A short description of what the invoice is for, ie: "System backup services";
- The date the service was rendered or the span of time the invoice covers, ie: "Oct 17, 2012";
- The amount of the invoice, ie: "$99.00";
While all this information is in the PDF version of the invoice, this allows my client to better deal with the email, without having to open up the attachement, and gives the message searchability later on.
When writing this email in a semantically-enabled email client, I could select "Invoice" from a drop-down list of email types, and based on the vocabulary, the email client would be able to semi-automatically markup the body. Once it does that step, it should prompt me for any metadata it has not been able to identify. Thus, I can manually mark those parts, and verify that I haven't forgotten an important piece of information.
Web-based email clients are obviously in a better position to make use of such a solution in the shorter term.
Privacy implications notwithstanding, imagine if you got an invoice for "Product 1" from a vendor. A web-based client such as Gmail (which is tied to Google's Product Search already) could present a sidebar with other vendors which carry that product, possible for a better price.