HTML emails in Tractis

Have you seen the new HTML emails sent by Tractis? It’s the new cherry on the top of the application! We uploaded the change 4 days ago and the truth is that I’m happy with it. If your mail reader supports HTML you can see the mails in that format, otherwise you can view them in plain text.

The design

In design terms, creating a template HTML email is definitely not easy. If designing a web application is complex, due to the number of variants and versions, imagine doing the same for an e-mail program.

When designing the HTML emails I kept the following in mind:

1. Simplicity
2. Lowest number of images possible
3. Personalisation
4. Information

For sure, many of us have seen more than one HTML email. Personally I don’t like them. Primarily because 99% of HTML emails aren’t displayed quite right in the reader program and, in addition, because people read email from many different sources that don’t even respect proper HTML. So it is an arduous trial-and-error task (you can’t even imagine) to develop something universal. I tried to give the design the same characteristics as Tractis: Simplicity, bright colours, contrasts and good proportions.

• Simplicity: The idea is that the mails are simple, both in design and construction. This allows flexibility to extend them or perform other operations.
• Lowest number of images possible: Given that mail readers always block images, you have to be able to see the mail without images.
• Personalisation: In the future, thanks to the code, you can insert the logo of the client and the colours of your theme.
• Information: Structure especially made to transmit levels of information as desired. The first part allows you to see everything, the second is for those that require more information or want to read related information.

The structure

The mail has specific zones and this model can be extended as required. For example, when you want to insert bills, there are mini modules for lists etc. In the image below I’ve named the specific zones:
We have:

1. A Logo. A bit smaller in size that the original on the site. The Tractis logo is too big for a mail reader window.
2. Identy line. It’s a design detail so that the design doesn’t ‘float’ and gives more emphasis to the subject. Ours has the Tractis green.
3. Subject. A phrase that indicates the topic of the email.
4. Summary. Serves to communicate the main message of the email. It is free to extend but the best proofs were those with little text. Less than 4 lines can be done but between 6 and 10 is best.
5. Main action box. Accompanying the summary is the box with the main actions. This means the user does not need to search or read between the normal links that appear or also to show key information, for example (as in the image above) how much credit is available after ‘topping up’.
6. Secondary information box. These are paragraphs to remind the user of the other options that are available in relation to the main action.
7. Details module. A module that extends and has a large amount of information. In some situations, it will not be required. Allows the insertion of any content in the zone whether it is paragraphs or lists of items.
8. Personalised list. A table in which you can personalise the information in a tabular form. In most cases it is used for payments, prices or perhaps to list versions or lists of concrete items.
9. Additional information module. More information on the topic, such as penalties or actions related to the theme. Also includes contact information.
10. Mail footer. Footer with contact information.

With this structure, we practically cover all the current needs for Tractis. I say practically because we never know what will come up in the future. Equally, the flexibility that it has demonstrated has been better then expected and has given few headaches.

What we hate about this

We wish that the code could be cleaner, shorter and standardised like in our web application. The problem originates with what the mail readers do and don’t do, impeding that possibility of standard HTML emails using separate style sheets. So, the code has to be an ‘alphabet soup’: everything included in the body of the document. When I look at is, there is too much superfluous code and even I can’t believe I’ve written it myself! But we’ve kept the abuse to a minimum to try and reduce the damage to our eyes.

In the future, when the major manufacturers understand this problem, we’ll change the emails to use less archaic technical standards.

By Diego Lafuente
Saved in: Announcements, Design | No comments » | 25 February 2008