Subscribe to the Newsletter Click Here

Join the LinkedIn Group Click Here

Issue 1 - May 13, 2009

The Innovation of Mail Markup Language

by Austin Cheney

It was the third day on the job with Travelocity that I received my first task.  I was to write the HTML/CSS code for the CEO’s newsletter, which was intended for company wide distribution.  This really should have been a simple task since the design was already mocked-up, content was provided, and I came from a background in email marketing.  I wrote the code, and the email was sent out.  Unfortunately, the result was not as it should have appeared.  The method of distribution a consideration I did not associate with the design of the email.

It became immediately clear that there was a fault somewhere and the fault was not in HTML or in the transmission of the email, the SMTP protocol.  I knew HTML was not created for use in email, and may often become corrupt when processed by email client software.  I did everything correctly, and the email software transmitted and processed the data correctly in accordance with email standards.  The fault was a lack of standards or methods for describing content in email.

My solution to the problem was to create a method of describing content, which is what markup languages are generally used for.  I wrote into the design of this language features for improving accessibility, semantic descriptions, simplified structures, and some security conventions.  I generally began with the assumption that if I could start over with the web what problems would I fix.  From the perspective of describing content my little language seemed to solve my original problem and provide some enhancements for problems that I had learned to live with as a web developer.

It was several months after I had begun working on the language that I had a rough and largely immature, but functional product.  At this point I had no idea what to do with it.  I had not shown it to anybody except two coworkers and did not know where to go next.  Fortunately, it was about this time the company’s newly hired intellectual property lawyer dropped by my department for a briefing about ethics, proper use of company assets, conflicts of interest, and so forth.  Directly after this meeting I set up a follow up meeting with the lawyer to help me with my questions.

The first thing this lawyer said is that working on unapproved projects using company equipment is a perceived ethical violation, however, the company is all about innovation.  He became rather delighted once I told him that I had not shown it to anybody outside the company and immediately suggested that the company file a provisional patent protection.  A provisional patent does not make any specific claims of novelty and is only valid for a year.  Provisional patents are only good for exposing an idea to the market without damaging the novelty necessary for filing a standard patent later in the year.  For many companies provisional patents are considered an inexpensive tax write-off.

I had signed up to participate in a company-wide innovation event called Hack Day.  Hack Day is a competition to produce the best new tool or concept starting with no prior effort, ending in 24 hours, and having only 90 seconds to demo.  I wanted to use this event to promote my little language within the company.  Thankfully, I received verification of provisional patent the day of the event, otherwise I would have likely had to forfeit or work on something I am far less invested in.

I went into Hack Day wanting to create a demo of the capabilities of the language, and instead discovered something I had not realized before.  While I was working on hashing out a representation of what my language may look like a friend suggested I examine the Twitter API.  This had absolutely nothing to do with email, but I thought it would certainly look impressive if I could produce a demo that looked exactly like a functional email client receiving live Twitter feeds in the body of an email.

My demo was actually a screen shot of Microsoft Outlook maximized to fit an entire screen, and used as the background of a webpage.  When some web browsers, such as Opera 9, are in full size mode all their borders, toolbars, and menus disappear leaving the page to stretch across the entire screen.  Since I would be working in HTML and in a web browser I could make it look like I was in an email client without having to build a new email client.  As a result getting the Twitter API to work was not actually innovative.  I also was able to produce a shopping experience, which was also more HTML pretending to look like transactions in email.

I walked away from the Hack Day event questioning how I would actually accomplish performing things like AJAX, shopping, and dynamic content services.  I knew my language would allow for these to become possible, but email works much differently than the web.  It would not be until nearly seven months later that I was able to figure out how to make AJAX type experiences possible in email without the use of client side scripting.  I believe this was my moment of innovation, because now I had a security model for the execution of code necessary for the dynamic distribution of content in a way that is far more secure that what is possible on the web.

It is my hope that my little language, my Mail Markup Language, will not only solve my original problem of uniformly describing content, but will also allow possibilities of innovation that can extend commerce, usability, and security.  There are many methods and processes that my language may allow, which I have not even imagined, and hopefully will spark innovation in other developers.

Austin Cheney
Creator of Mail Markup Language
http://www.mailmarkup.org 

(Find Austin on LinkedIn)  

Return to Issue 1 Table of Contents