.png)
While email applications have quickly evolved,
email itself is still in 1.0
Ever notice how old email protocol is? In fact, email hasn't really been updated since the first public advent of the internet, only the browsers and applications we use to view, send, and store email have kept up with the rapidly changing demand for online communication.
Of course there have been a lot of significant advancements to these viewers. My client, gmail, was the first to offer perpetually increasing generous storage, and has perfected the use of filters, labels, and threading. But what could be done to upgrade the protocol itself?
A new email
Here are just a few ideas for email that could dramatically change the way we send messages.
Real-time emails
Ever been in an email discussion with someone only to find they're responding so quickly, they're likely using their email at the same time as you? The process is still slow. First, you send the message, close the email, wait for a reply, click on the reply, read the reply, repeat. Dynamic and real-time email could support the sending of conversations, not just messages.
Again, some services like Gmail have attempted to come close to this by grouping emails, but the world of web 2.0 is ready for messages to be as real-time as chatting on an instant messenger.
Multimedia support
Truthfully, e-mail should really have been called e-letters because the protocol only mimics the sending of letters rather than packages or "media mail." As email 1.0 can send attachments of files, email 2.0 could send the files themselves.
This could also be extended to specialized links. If you want to send a blip.tv, YouTube, or DailyMotion video, simply send the email to an address and the sendee receives the video as an actual flash media player. No longer would email users need to open an email to see photos, videos, or music within the email themselves or need to download attachments and drive themselves click-crazy.
Importibility
I've always wondered why Google reserved Reader and Talk to their own separate applications. Email should be the mother of all communication platforms.
In the same way that snail mail delivers news, catalogues, and magazine subscriptions, email should also be friendly to feeds.
The next email protocol should allow for importing other forms of messaging like Twitter and Facebook.
Live messaging
Currently, an email message itself is just a document. The funny thing is that there's no going back to change this document unless you want to simply delete and start over.
While there are plenty of awesome opportunities for collaboration from numerous web apps, a significant amount of collaboration is still done via email. Email 2.0's live messages would allow a message to be changed after being sent.
Imagine receiving an email from an employee. Let's say it's called "My idea". You open "my idea" and his/her idea looks okay but you tell your employee it needs some work. A few hours later, that same email moves up and becomes unread in your email inbox. The original message has been changed leaving a revision history behind it.
True threading/nesting
Some email clients have already attempted to show threads of emails but email currently tries to thread messages by actually copypasting the preceeding messages with those annoying ">" marks before each line.
Email 2.0 should show indented replies so multiple addressees in an email can respond to the latest comments or go back to earlier statements to reply in a visually intuitive way.
Subscription code
How many times have you just hit the "spam" button on a non-spam, requested email newsletter because you just didn't want to go to the trouble of figuring out that organization's particular way of unsubscribing?
Unsubscribing from email newsletters is the most notorious of email annoyances. Some companies make it easy by asking you to simply reply with anything at all. Others want you to click on a link where you must re-enter your address and wait to be subscribed. In any case, each way is different and it's frustrating.
Subscribing and unsubscribing should be as well implemented as forwarding and replying. Email threads should recognize an unsubscribe command and promptly unsubscribe the same was as one would with a feed.
Address subdomaining
Because so many sites already have their own internal messaging systems, email 2.0 could extend functionality by offering subdomains within emails. For instance, one could post to their Twitter account from their email client by emailing "abvegan@tweet.twitter.com" or send a direct message (e.g. @someuser) by emailing "someuser@reply.twitter.com". Really, this is only one way to implement subdomains. It's up to the receiving email client to determine how to handle subdomains.
Account theming
When email was first conceived, few email addresses existed starting with words like "no reply" or not actually belonging to any one single person.
Email 2.0 could support account theming, the ability for email identities to be one-way senders, businesses, bands, groups, or just individuals. This way, I could sort out my email as actual people emails, notifications from social communities, and organizations. Some days, I just want to read what my friends are saying to me. Other days, I want to read my newsletters. Email 2.0 should let me distinguish between email identities.
Comments