One wish for 2008: innovative email
By Erik van Kempen | December 31, 2007
While preparing the night of the yearly countdown, we should not think about what happened during the past 365 days. In my opinion, we should think about what we are going to do during the coming days. The more time you spend thinking about history, the less time you have left for the future. So, I thought about what my wishes for 2008 are. One of them is a new e-mail message format or system.
The current email system
Nowadays, email messages consist of plain text. Every message is just an array of ASCII characters, mostly. Even embedded binary files, are encoded in such a way that it can be represented by an array of ASCII, using the BASE64 encoding. You can add a bit of formatting by using HTML in your message, because modern mail clients are able to parse HTML.
This system was first intended to be a simple way to communicate asynchronously via textual messages. In a way it was a simplified electronic alternative for our regular (snail) mail system, we still use today. Email has a lot of advantages: it's less costly to send a message, it's damn fast and has the same legal status as a regular letter (at least over here in The Netherlands). But this system didn't prove to be a decent alternative. I still receive a lot of snail mail, daily. Even invoices from my hosting companies are, besides being sent by email, also sent via regular mail.
Missing features
Two of the key advantages of the convential snail mail: the letters are deliverd physically as a stack of paper instead of digitally (for non-environmentalists, this is an advantage at least) and they can be designed to be nicely looking. The second advantage is also important to me. Companies spend a lot of money on design of there publications. Designers invented the word 'branding' for this, very 2.0-style.
Some of this style can be converted to HTML, to be used in our current email system, but not all. Imagine a company which uses a custom font for their publications. They are able to use to font in their snail mail letters, but are not able to use it in emails, because the readers on the other side of the screen doesn't have the font installed. There are a few options to solve this problem: sending the font to the user before he receives the email message or converting the text with the custom font to image files, which can be embedded via HTML in the message or attaching a PDF with the nice looking snail mail letter. The last is used mostly, but not a neat solution and the first two are not really an option, do you think?
Redesign proposal
I would propose a new system, wich resembles the way convential snail mail works. You sent the message as some sort of binary format, which contains all the formatting, fonts, images, page height, page width and a nice looking letter head. As format we could choose for PDF. PDF is a widely accepted open standard and resembles convential paper letters really well. Or if you like, we could introduce a new non-proprietary open standard to handle the task of new email message format.
Advantages
- You will be able to use your company style and brand on the email messages
- The messages will look the same everywhere (or something is wrong with the client software, which will not be the case when the standard specifications are followed)
- It will still arrive at the recipient as fast as email does now
- It can be a decent alternative for convential paper letters
Disadvantages
- The messages are larger in size, but that should not be a problem with the bandwith these days. On the other hand, it is a big problem, because corporate email servers need to handle more bytes. So, it's a capacity disadvantage, but not a real bandwith disadvantage.
- The messages are more difficult to scan by a spam filter.
- Every message has a different style. This was never a disadvantage for the paper letters, so it shouldn't be a problem for email. If it proves to be problematic, you can introduce style guides for memos, short notes etcetera.
So what should we do
First this idea should be researched further, because it's just a single brainwave of one single guy. Then the exact specification should be widely accepted, so mail client developers need to implement this new system. Developers of other mail affiliated software, should also publish new versions. Companies will need a decent mail composer for instance, or use a text processing application and a PDF exporting tool. That's all that needs to be done.
Just another wish
Every sender of mail should use a security certificate in this new system. This way, the spam filter isn't busy scanning all day. Maybe governments can issue these certificates via some sort of institution.
That's all for 2007
I wish all of you a very happy New Year and hope 2008 will be as innovative as 2007 was.