vrijdag 3 juni 2011

5 richtlijnen voor het coderen van nieuwsbrieven in HTML

Voor wie graag zelf zijn sjabloon / template voor de nieuwsbrief bouwt, heb ik een vijftal uitgangspunten opgesteld. Voor ik daar inhoudelijk op in ga, geef ik eerst een stukje achtergrondinformatie over de wijze waarop verschillende e-mailprogramma’s met HTML omgaan: HTML rendering.

HTML rendering
HTML rendering is het proces waarin een HTML rendering engine de HTML die hem aangeboden wordt, omzet naar de tekstuele en grafische elementen die je in je webbrowser of e-mailprogramma ziet. Het feit dat de diverse rendering engines (Gecko, Trident, WebKit e.a.), van elkaar verschillen, is één van de redenen dat dezelfde HTML in verschillende e-mailclients (Outlook, Thunderbird, Apple Mail, Gmail, Hotmail, Yahoo!, et cetera) verschillend weergegeven kan worden.

Naast het gebruik van de verschillende rendering engines is er nóg een uitdaging die je het hoofd moet bieden. Zo moeten e-mailclients hun gebruikers beschermen tegen spammers en ander digitaal tuig. Dat betekent dat technieken die voor websites prima werken (zoals het meegeven van een achtergrondkleur aan de ) door sommige e-mailclients “gestript” worden, omdat spammers vergelijkbare constucties gebruiken om hun doelgroep te misleiden. De goeden lijden dus – zoals gebruikelijk – onder de kwaden.

Tot slot speelt ook het gebruikte besturingssysteem (Windows XP / Vista / 7, Apple OS, Linux, et cetera) een rol. Thunderbird kan zich binnen Windows 7 weer net iets anders gedragen dan binnen Ubuntu (een Linux-distributie), en Outlook 2007 kan in Windows Vista zorgen voor een iets andere weergave van e-mailberichten dan in Windows XP (en dan heeft óók de geïnstalleerde versie van Internet Explorer daar soms nog weer invloed op).

Ik zal niet ingaan op welke e-mailclient welke HTML rendering engine gebruikt, welke beperkingen hij verder oplegt aan het verwerken van HTML en hoe de verschillende besturingssystemen daar hun bijdrage aan leveren, (daar is een klein boek aan te wijden namelijk), maar ik volsta hier met:

E-mailclients beperken het gebruik van HTML en CSS, maken het gebruik van andere technieken (Flash, Javascript, PHP, e.d.) nagenoeg onmogelijk, en doen dit binnen verschillende omgevingen allemaal op een net iets andere manier.

De oplossing voor al deze E-mail Ellende is: drastisch ouderwets te werk gaan. Daarom hieronder een aantal richtlijnen.

Richtlijn 1: Gebruik tabellen in plaats van <div>-jes
Misschien is dit wel het meest elementaire uitgangspunt voor het coderen van nieuwsbriefsjablonen: gebruik tabellen, tabellen en tabellen!

Voor websites worden doorgaans <div>-jes gebruikt om verschillende elementen (zoals het hoofdmenu, de header, de footer, een kolom, et cetera) te omsluiten. Vervolgens worden in een extern stijlblad (een CSS-bestand) de stijl en positie van elke <div> bepaald.

E-mailclients kunnen daar niet mee omgaan. Daarom kun je beter tabellen gebruiken. Voor het positioneren van elementen gebruik je daarom ook geen float: left;, maar align=”left“ of style=”text-align: left;”.

Richtlijn 2: Gebruik één tabel van één cel als wrapper
Dit advies ligt in het verlengde van de eerste richtlijn, maar kan dusdanig veel invloed hebben dat ik het afzonderlijk vermeld. Om te voorkomen dat er elementen van je nieuwsbrief “uitsteken” (bijvoorbeeld dat de body van je nieuwsbrief net iets breder is dan de header en de footer), kun je het beste één tabel met één cel gebruiken als wrapper. Als volgt dus:

<table style=”width: 600px; margin: 0px; padding: 0px;”>
    <tr>
        <td style=”margin: 0px; padding: 0px;”>
                Hier de rest van je HTML
        </td>
    </tr>
</table>

Geef de tabel een vaste breedte (een aantal pixels dus, geen percentage), en plaats andere tabellen binnen die hoofdtabel. Reken goed uit hoeveel pixels je spendeert aan de breedte van subtabellen, cellen, paddings en margins, en zorg dat je daarmee de breedte van de wrappertabel niet passeert.

Bij voorkeur gebruik je voor elk element een nieuwe tabel. Daarom is het heel belangrijk dat je je HTML netjes opmaakt: gebruik inspringingen en witregels om de structuur duidelijk te maken, en geef in complexe sjablonen / templates eventueel met commentaar aan waar een element begint en eindigt.

Bonustip 1: Als je de achtergrond van je nieuwsbrief een andere kleur wilt meegeven dan wit (over de hele breedte van het scherm), dan kun je om de hierboven beschreven wrapper tabel nóg een wrapper tabel plaatsen. Die geef je dan een breedte van 100% en een achtergrondkleur naar keuze. Je kunt je nieuwsbrief binnen die tabel eenvoudig centreren met <center></center>. Hotmail accepteert dat niet, maar daar is óók weer een oplossing voor. De inhoud van de <head></head> wordt gelukkig niet door elke e-mailclient (volledig) gestript. Plaats daarom de volgende code in de <head></head> van je nieuwsbrief:

<style type="text/css">
            .ReadMsgBody { width: 100%; }
            .ExternalClass { width: 100%; }
</style>

Nu zal Hotmail je nieuwsbrief ook netjes gecentreerd weergeven!

Bonustip 2: Wen jezelf aan om alle tabellen en tabelcellen standaard van een margin en padding van 0px te voorzien. Als de padding daarvan af moet wijken, kun je dat altijd nog instellen (margins kun je beter niet gebruiken, die worden niet overal ondersteund). Door alle margins en paddings standaard op 0px te zetten, voorkom je dat e-mailclients creatief worden en ergens een paar pixels aan toevoegen of juist wegsnoepen. Geloof me, als een e-mailclient de kans krijgt om je met bloed, zweet en tranen geproduceerde HTML te vernaggelen, zal hij dat zeker doen!

Richtlijn 3: Gebruik inline CSS in plaats van interne CSS of een externe stylesheet
Sommige e-mailclients strippen de volledige inhoud van de <head></head> van een HTML-mailing. Dat betekent dat interne stijldeclaraties en verwijzingen naar externe stylesheets genegeerd worden. De oplossing: inline CSS. Oftewel, stijldeclaraties plaatsen waar ze nodig zijn, OVERAL dus!

Dat betekent dat je elke tabel en elke cel van opmaak moet voorzien. Daarom is het verstandig om eerst de structuur van je mailing op te zetten en als laatste de stijl toe te passen. Ook kun je, als je nieuwsbrief elementen heeft die qua structuur en stijl met elkaar overeen komen, eerst één element bouwen + stylen, en daarna gewoon kopiëren en plakken. Vroeg of laat zul je echter een keer iets willen wijzigen. Dan zit er inderdaad – zucht – niks anders op dan de wijziging overal toe te passen waar nodig.

Bonustip: Sommige e-mailmarketingapplicaties (bijvoorbeeld MailChimp) bieden tools om interne CSS (stijldeclaraties in de <head></head> van je HTML-document) automatisch om te zetten naar inline CSS.

Richtlijn 4: Beperk je tot HTML + CSS
Soms is de verleiding groot om in een nieuwsbrief bijvoorbeeld roterende banners en video te gebruiken. Hoewel ik de laatste zal zijn om te zeggen dat je geen dynamische elementen moet toevoegen aan je mailing, moet je toch rekening houden met de technische beperkingen van e-mailclients.

Gebruik je daarom een roterende banner, hou er dan rekening mee dat sommige e-mailprogramma’s de techniek die je gebruikt voor het roteren (bijvoorbeeld Flash of Javascript) niet ondersteunen, waardoor óf niks óf alleen de eerste afbeelding wordt getoond.

Video is een ander veelgebruikt communicatiemiddel. Het kan goed gebruikt worden in combinatie met een nieuwsbrief, maar verwacht niet dat een video in de inbox van een willekeurig e-mailprogramma afgespeeld kan worden. Je doet er daarom verstandig aan om – als je bijvoorbeeld een YouTube-filmpje wilt opnemen in je nieuwsbrief – een screenshot te maken van het begin van je video en deze als afbeelding in je nieuwsbrief te plaatsen. Zorg ervoor dat het herkenbare driehoekige afspeel-icoontje goed zichtbaar is, zodat het lijkt alsof de ontvanger rechtstreeks op de video klikt. Vervolgens link je de afbeelding naar de daadwerkelijke video op YouTube of op je eigen website / weblog, en klaar ben je!

Richtlijn 5: Werk met oog voor detail en: testen, testen, en nog eens testen!
Webbrowers willen nog wel vergevingsgezind zijn als je een HTML-tag niet netjes afsluit. E-mailclients zijn strenger, omdat het open laten van HTML-tags een truukje kan zijn waarmee spammers en andere digitale boeven hun doelgroep proberen te misleiden. Werk daarom heel nauwkeurig!

Eerder had ik al gesteld dat je elke tabel en elke cel apart moet opmaken. Let er daarom op dat je (zeker wanneer je in een later stadium wijzigingen aanbrengt) echt ALLE cellen opmaakt, zodat passages die dezelfde stijl moeten hebben, er ook daadwerkelijk hetzelfde uitzien (qua lettergrootte, lettertype en kleur). Zorg dat alle hyperlinks zich op dezelfde manier gedragen (ook die moeten individueel opgemaakt worden), en hanteer een consequente uitlijning van de elementen in je nieuwsbrief.

Tot slot: testen, testen en nog eens testen! Maak een account aan in Hotmail, Yahoo! en Gmail en test die in verschillende browsers. Installeer verschillende versies van Outlook op verschillende besturingssystemen. Installeer Thunderbird en test in Apple Mail en op verschillende Linuxdistributies. Bekijk de webversie van je mailing in verschillende browsers en op verschillende besturingssystemen.

Natuurlijk kun je het testproces zo uitgebreid maken als je wilt. Misschien is niet al het bovenstaande noodzakelijk voor jouw campagne, die inschatting kun je het beste zelf maken. De bottom line is in elk geval: testen, testen en nog eens testen!

Bonustip 1: Als je niet de mogelijkheid hebt om test uit te voeren binnen verschillende besturingssystemen / webbrowsers / e-mailclients, kun je gebruik maken van tools als Litmus of de Inbox Inspector van MailChimp. Dergelijke applicaties versturen je mailing naar allerlei verschillende clients. Op die manier kun je er óók achter komen hoe je HTML zich houdt in verschillende digitale omgevingen.

Bonustip 2: Campaign Monitor biedt op haar website een zeer gedetailleerd overzicht van stijldeclaraties en bijbehorende ondersteuning in een groot aantal e-mailclients. Staar je er niet blind op (er staan aardig wat zaken in die je waarschijnlijk toch nooit zult gebruiken), maar een aantal elementen is erg zinvol.

Slotwoord: E-mailclients are evil
Het coderen van HTML-nieuwsbrieven kan erg leuk en uitdagend zijn (echt!), maar het kan (zeker bij complexere sjablonen) ook veel frustratie opleveren. Je doet er verstandig aan om e-mailclients met een zekere mate van achterdocht en speelse minachting te benaderen. Doe je dat niet, dan geef je e-mailclients de kans om het bloed onder je nagels vandaan te trekken.

Wees daarom creatief, creëer af en toe je eigen regels en maak gebruik van oplossingen die anderen al hebben gevonden en op internet hebben gepubliceerd. Soms lijkt zo’n oplossing tegen elke vorm van officiële ondersteuning (van e-mailclients) in te druisen. Maar als het werkt, werkt het! Hanteer daarom het alom bekende credo “Als het niet kan zoals het moet, moet het maar zoals het kan!”.