Introduction
In case you wish to write your message directly in html, please refer to the guidelines below for a correct visualisation of the message on most webmail services and email programs (Outlook, Thunderbird, etc…). These guidelines are the fruit of ContactLab’s experience over the years and of millions of email messages sent by our clients.
Objective
Supply the technical guidelines for writing html for ContactLab.
General rule
The HTML of an email must be “simpler and cleaner” than that of a web page: webmails and email programmes find it difficult to manage certain elements (cascading style sheets, javascript, flash) which browsers can cope with perfectly well. The specifications will indicate the elements that should not be entered in your message in order to prevent visualisation problems for the final user.
Specifications
| 1. | Layout of content. The entire content of the message is inserted inside a table with a fixed width (specifying this in the width attribute of the table tag. |
| 2. | Recommended width. The external table mentioned in point 1 must have a fixed width. The recommended width is 550 pixels as this ensures horizontal scroll bars do not appear on the major email programmes and webmails. |
If, instead, you require a wider layout, the maximum recommended width is 600 pixels: many programmes and webmails will visualise the message correctly and if the horizontal scroll bar does appear, the scroll will be so small that it should not be annoying for the final user.
| 3. | Recommended lengths. For technical reasons, there is NO recommended length. To be effective, of course, the messages of a group or a commercial DEM must not be too long and refer users to web pages as much as possible by inserting links in the message. |
| 4. | <title> tag in <head>. Insert a text in the <title> tag. Do not leave any default text assigned by the html editor (e.g.: “Untitled1” or “New page 1”). |
| 5. | Images. Images should be loaded on a server (ContactLab’s or your server) and then inserted in the message in the src attribute of the img tag. The format must be jpg or gif (it may also be an animated gif). We strongly advise against inserting mapped images. Each image should be as small as possible in order to prevent the email from exceeding under the recommended total size limit (see point 5 below). |
| 6. | Recommended size. The size of the html+images should not exceed 60 KB. |
| 7. | Cascading style sheets. Cascading style sheets (CSS) must be used “sparingly” (see “General rule” above). Here’s how: |
– Do not use CSS’ to determine the position of an element (e.g.: the alignment of an image or table, etc…)
– Insert the style both as an internal CSS (between the style tags in the head) and as an external file (loaded to a server and then linked to the inside of the file).
– The internal CSS should be commented (that is, all the style sheet elements, apart from the style tags, must lie between <!– and –> )
– The external CSS must be linked inside the body (not in the head).
| 8. | Background images. If the body has a background, do not write in white (or in the same colour as the background). This is because the text will be illegible if the background image is not visualised for some reason. |
| 9. | Text-image balancing. Do not insert just images in the html as this would greatly increase the probability of the message finishing in the antispam. It is best to enter as much written text as possible. Very large images should be split into two or more sections and then composed using a table (table tag). |
10. Names of images. Assign a name to each image signifying what it represents.
Do not use names such as: 001.gif, 002.gif, or photo1.jpg, photo2.jpg etc..
This reduces the risk of the message being considered as spam
11. Characters. Do not use accented letters typed from the keyboard: replace them with plain vowels followed by an apostrophe, or with the relative html codes (e.g.: à). Beware of MS Word characters (e.g.: inverted commas, ellipses, hyphens and apostrophes in Word must be replaced with the relative symbols typed from the keyboard).
12. Elements to avoid.
– Mapped images. Do not insert images containing a map. Instead, split the image, compose it in a table and link the various pieces.
– Javascript. Do not insert javascript in the HTML of the message.
– Flash. Do not insert flash files (.swf) in the HTML. If you really have to insert moving elements, use animated gifs.
13. Linked text
Do not use the url of the link as text. For example, do not use links such as <a href=”http://www.tomato.it”>www.tomato.it</a>. This is because some popular mail programmes, including Thunderbird, carry out antiphishing checks that could mark a link of this kind as suspicious. Replace it with text such as: <a href=”http://www.tomato.it”>tomato website</a>
Fixed limits
The above specifications will allow your messages to be correctly visualised by the overwhelming majority of webmails and email programmes that are currently in use. Of course, there are some limits we have no control over (policies of individual providers or software manufacturers) and are unable to solve. At the moment, for example, we are aware that style sheet blocking policies have been implemented by GMail and Hotmail: on these webmails, therefore, messages may become untidy even though they observe our specifications. Visualisation problems are often reported with the Lotus suite email programme.
Test emails before deploying them
The best way of checking an email is visualised correctly and its elements work is to send a test campaign before deploying the campaign real and proper. ContactLab allows you to create a test filter for each database (cf. chap. 2.3) and send it a test campaign (cf. chap. 3.2).
It is always best to insert various addresses in the test in order to check them against various email programmes and webmails.