Basic Notions for Developing Responsive HTML Emails

Inthis 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 onmost 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 an HTML email that would be completely unthinkable for normal web development.

Andthis is the exact element for which email is distinguished from webdevelopment: since there is no singlestandard, it is often necessary to rely on workarounds that fill in thegaps created by the various email clients.

We know that the various versions of Outlook,from 2003 to 2016, not to mention LotusNotes, have given developers endless headaches. These two examples areenough to understand that theclients are extremely different and that a solid code must also take these aspects into account.

Inthe end you may not have an email that’s precise down to the last pixel for allclients, but the essential point ofemail marketing is not the delta of two or five pixels of padding, but that the message is readable by the user andthat ultimately, you convey the message you want to communicate.

Thesecond consideration that can be made in light of what has been said is thatthe perfect email does not exist. Itsimply does not exist.

Thevariables to be taken into accountand the differences in how the various clients manage HTML code are so vastthat it is actually impossible tosatisfy them all.

Itbecomes essential to make choices whenyou are creatively and technically developing an email. Whether you like it ornot, you will have to compromise.

Oneapproach to the problem is to know youraudience and choose your development strategy based on the same:whether to adopt a more aggressive solution, a riskier one from the point ofview of customer returns, or lean towards a more conservative code in favor ofa more solid email.

Whateverthe choice, it will have both advantages and penalties, and in the end you willhave to weigh the scales to decidewhether it makes more sense to adopt one technical solution ratherthan another.

Ipersonally believe that a message, being such, must in any case be readable by the recipient. Keep inmind that an email seeks to capture the attention of our audience, and like allmessages must be read and understood.

Borrowingthe motto of the Robustness principle,“Be conservative in what you send, be liberal in what you accept”, Ibelieve – except for the due exceptions – that a robust code able to pass the test of the most difficult clients inthe long run is much more profitable than fashionable or pure-effect solutionsthat operate on only a group of devices.

Givenall the above, where should we begin? What is the starting point of an email?

Youmight be surprised, but the development of an email does not start from itscode. The first step is the creativityanalysis, to identify the blockstructure with which it is composed.

Wesay blocks because the modular approach,in a responsive perspective, is certainly one of the best to adopt.

The concept of modularity introduces theindependence of the single element with respect to the context inwhich it is inserted. This means that once created, it is possible to move, modify, and re-elaborate themodule within the communication without affecting the entire structure, orworse, without totally disrupting the entire layout (Picasso effect).

Thesame concept can also be extended to the individual elements of the module.

Forexample, once the structure of a button for a call-to-action is set, it can be re-inserted in another part of theemail 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.)

Ifpossible, it is very useful to create a wireframe for the mobile versionas well. Let’s not forget that one of the fundamental mantras of email marketing is mobilefirst.

Accordingto this concept, the starting point of graphic design should firstly be thedisplay from a smartphone.

Theexample we’ll consider is a small model with the following structure:

• Header(webdisplay, logo, payoff);
• Mainblock (visual, headline, text, CTA);
• Secondaryblock (secondary images, main title, abstract, CTA);
• Footer(trustpart, contacts, etc.);
• Legal (disclaimer, unsubscribe).

Oncethe blocks have been defined, you can begin to write the code, where the lintel of a solid communication is the tag<table>.

Itmight seem a little dated to talk about tables in 2019, but if the web hasundergone great technical evolution anda series of remarkable innovations (thinkof the introduction of semantics, graphic tags, or multimedia elements), thesame thing cannot be said for emails.

Aswe will see in other cases, this is not the only example in which the lack of a standard forces developers tochoose solutions that may seem technically outdated. The table structure isthe most concrete solution for maintaining optimal control over the finaloutput 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.

Wecreated a table with 100% width,defining the borders, padding, and cell spacing at zero.

The100% width ensures the adaptation ofthe table regardless of the screen on which it will be displayed. Defining thepadding, border, and spacing properties at zero instead imposes a zero startingpoint that lets us avoid unpleasant and unwanted spacing introduced by someclients, not least Outlook.

Finally,using an inline style, we define thetable-layout: fixed;.

On mail clients like Yahoo!,  this forces the correct table width at 100%.

Sincewe want to center the entire email, we set align= “center” at the cell level and not the table level: havingthe latter at 100% width centers it by definition.

Soyou can already see some workarounds that have to be applied if you want tocorrectly display your emails on the various email clients. We will see othersimilar points during the analysis.

Nowthat the main container has been constructed, we can insert the content which, needless to say, will in turn be put in atable.

Thestructure is very similar to the previous one: the basic system is the same.

Whatchanges is the width: no longer100%, but 600px.

Thissecond table is the other cornerstone of the email: the 600px sets the desktopwidth of the communication. And we must modify this parameter to set theoverall width of the email.

Atthis point it may be tempting to insert your actual content here: texts, images, CTA.

Itis feasible, but not advisable. The reason is simple: the table we justimplemented only serves to set – that is, control – the width of thecommunication. We’ll see how it will then affect the width for mobile devicestoo, in a responsive perspective.

Forsimple content such as the text view online, it’s rather simple todirectly add it, however morecomplex structures such as a logo and payoff (block 2) would be better ifencapsulated in a further table.

Thenesting techniquesaves us for two reasons: becauseit serves modularity and because it gives us greater control over the singleelement we are defining.

Sofor block 2 you can see how a new table was created, this time with two cells.

Thestyle of the code is similar to what we have already seen: after setting zerofor the borders, padding, and spacing, we set a width of 100%.

Thentwo cells are declared: both with a percentage width of 47%.

Wework with dimensions in percentages to get a fluid structure which adapts to the screen where the communicationwill 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 otherchild 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 interpretationof the code by the various clients.

Ifwe set it at 50%, there is an incredibly high risk of ruining the layout due to unwanted spacing or due to theinsertion of styles by the clients. So high, in fact, that it is worthwhile tomaintain a certain safety margin.

Moreover,the two elements (the logo and text) are respectively aligned to the right andto the left, therefore the distribution of the content helps us make a conservative choice that shouldnot be a source of problems.

Atthis point we can summarize thebasic structure of the example as follows:

1. Maincontainer table or main module, with 100%width; Secondary table, whichdetermines the form of the email, with 600pxwidth;
2. Contentstable, with 100% width wheretexts, images, CTA, etc. are inserted

Thefront-end yield, currently via browser, is not very encouraging, and theprocessing status is obviously very crude, with many other details andfundamental points missing. We will eventually have the opportunity to examine themindividually.

However,just like in a building, the most solidfoundations have been laid for correct display on the various emailclients. See you next post!