Just like in a building, you need solid foundations: today we’re going to look at the steps for laying the foundations for your campaigns, ensuring correct display on the various email clients.
An introduction to responsive HTML
In this series of posts we will briefly show you the necessary steps for constructing an email in HTML that is responsive and can uphold its layout on most clients and devices, from desktop to mobile.
This is not a two-step process: a series of techniques and workarounds must be adopted to create a concrete email that would be completely unthinkable for normal web development.
this is the exact element for which email is distinguished from web
development: since there is no single
standard, it is often necessary to rely on workarounds that fill in the
gaps created by the various email clients.
We know that the various versions of Outlook, from 2003 to 2016, not to mention Lotus Notes, have given developers endless headaches. These two examples are enough to understand that the clients are extremely different and that a solid code must also take these aspects into account.
In the end you may not have an email that’s precise down to the last pixel for all clients, but the essential point of email marketing is not the delta of two or five pixels of padding, but that the message is readable by the user and that ultimately, you convey the message you want to communicate.
Approaches and philosophy
The second consideration that can be made in light of what has been said is that the perfect email does not exist. It simply does not exist.
The variables to be taken into account and the differences in how the various clients manage HTML code are so vast that it is actually impossible to satisfy them all.
It becomes essential to make choices when you are creatively and technically developing an email. Whether you like it or not, you will have to compromise.
One approach to the problem is to know your audience and choose your development strategy based on the same: whether to adopt a more aggressive solution, a riskier one from the point of view of customer returns, or lean towards a more conservative code in favor of a more solid email.
Whatever the choice, it will have both advantages and penalties, and in the end you will have to weigh the scales to decide whether it makes more sense to adopt one technical solution rather than another.
I personally believe that a message, being such, must in any case be readable by the recipient. Keep in mind that an email seeks to capture the attention of our audience, and like all messages must be read and understood.
Borrowing the motto of the Robustness principle, “Be conservative in what you send, be liberal in what you accept”, I believe – except for the due exceptions – that a robust code able to pass the test of the most difficult clients in the long run is much more profitable than fashionable or pure-effect solutions that operate on only a group of devices.
Where to start?
Given all the above, where should we begin? What is the starting point of an email?
You might be surprised, but the development of an email does not start from its code. The first step is the creativity analysis, to identify the block structure with which it is composed.
say blocks because the modular approach,
in a responsive perspective, is certainly one of the best to adopt.
The concept of modularity introduces the independence of the single element with respect to the context in which it is inserted. This means that once created, it is possible to move, modify, and re-elaborate the module within the communication without affecting the entire structure, or worse, without totally disrupting the entire layout (Picasso effect).
The same concept can also be extended to the individual elements of the module.
For example, once the structure of a button for a call-to-action is set, it can be re-inserted in another part of the email without affecting the communication.
The best tool for identifying blocks is a wireframe, especially in the graphic design phase.
With a wireframe you can identify each block that forms the communication, defining its main elements (e.g. the headline, images, CTA, etc.)
If possible, it is very useful to create a wireframe for the mobile version as well. Let’s not forget that one of the fundamental mantras of email marketing is mobile first.
According to this concept, the starting point of graphic design should firstly be the display from a smartphone.
The example we’ll consider is a small model with the following structure:
- Header (web display, logo, payoff);
- Main block (visual, headline, text, CTA);
- Secondary block (secondary images, main title, abstract, CTA);
- Footer (trust part, contacts, etc.);
- Legal (disclaimer, unsubscribe).
The supporting structure, the <table>
Once the blocks have been defined, you can begin to write the code, where the lintel of a solid communication is the tag<table>.
It might seem a little dated to talk about tables in 2019, but if the web has undergone great technical evolution and a series of remarkable innovations (think of the introduction of semantics, graphic tags, or multimedia elements), the same thing cannot be said for emails.
As we will see in other cases, this is not the only example in which the lack of a standard forces developers to choose solutions that may seem technically outdated. The table structure is the most concrete solution for maintaining optimal control over the final output on most email clients.
The first step is therefore to build a general table, containing the module in which we will insert the elements (text, images, CTA, etc.) that are of interest. This technique not only gives us good control over the placement of the module, but also lets us insert many other properties such as color or background image, padding spacing, etc.
We created a table with 100% width, defining the borders, padding, and cell spacing at zero.
The 100% width ensures the adaptation of the table regardless of the screen on which it will be displayed. Defining the padding, border, and spacing properties at zero instead imposes a zero starting point that lets us avoid unpleasant and unwanted spacing introduced by some clients, not least Outlook.
Finally, using an inline style, we define the table-layout: fixed;.
On mail clients like Yahoo!, this forces the correct table width at 100%.
Since we want to center the entire email, we set align = “center” at the cell level and not the table level: having the latter at 100% width centers it by definition.
So you can already see some workarounds that have to be applied if you want to correctly display your emails on the various email clients. We will see other similar points during the analysis.
Now that the main container has been constructed, we can insert the content which, needless to say, will in turn be put in a table.
The structure is very similar to the previous one: the basic system is the same.
What changes is the width: no longer 100%, but 600px.
This second table is the other cornerstone of the email: the 600px sets the desktop width of the communication. And we must modify this parameter to set the overall width of the email.
At this point it may be tempting to insert your actual content here: texts, images, CTA.
It is feasible, but not advisable. The reason is simple: the table we just implemented only serves to set – that is, control – the width of the communication. We’ll see how it will then affect the width for mobile devices too, in a responsive perspective.
For simple content such as the text view online, it’s rather simple to directly add it, however more complex structures such as a logo and payoff (block 2) would be better if encapsulated in a further table.
The nesting techniquesaves us for two reasons: because it serves modularity and because it gives us greater control over the single element we are defining.
So for block 2 you can see how a new table was created, this time with two cells.
The style of the code is similar to what we have already seen: after setting zero for the borders, padding, and spacing, we set a width of 100%.
Then two cells are declared: both with a percentage width of 47%.
We work with dimensions in percentages to get a fluid structure which adapts to the screen where the communication will be displayed. In doing so, when the width of the parent table is changed, the one with the width = “600”, we can be sure that all the other child tables will adapt accordingly.
We didn’t set a width of 50% for the two tables, as logic would suggest, for the same basic problem: the different interpretation of the code by the various clients.
If we set it at 50%, there is an incredibly high risk of ruining the layout due to unwanted spacing or due to the insertion of styles by the clients. So high, in fact, that it is worthwhile to maintain a certain safety margin.
Moreover, the two elements (the logo and text) are respectively aligned to the right and to the left, therefore the distribution of the content helps us make a conservative choice that should not be a source of problems.
At this point we can summarize the basic structure of the example as follows:
- Main container table or main module, with 100% width; Secondary table, which determines the form of the email, with 600px width;
- Contents table, with 100% width where texts, images, CTA, etc. are inserted
The front-end yield, currently via browser, is not very encouraging, and the processing status is obviously very crude, with many other details and fundamental points missing. We will eventually have the opportunity to examine them individually.
However, just like in a building, the most solid foundations have been laid for correct display on the various email clients. See you next post!