Email building, avagy vissza a kőkorszakba

Munkám során gyakran készítek email sablonokat hírlevél kampányokhoz, weboldalak kimenő leveleihez. Első ránézésre a feladat könnyűnek tűnik, hiszen rövid terjedelmű, kevés elemet tartalmaz, struktúrája lényegesen egyszerűbb mint egy weblapé. Mégis rengeteg kihívást rejt, ennek oka a modern webes megoldások kényszerű nélkülözése.

Sajnos a levelező kliensek primitívek a mai technológiákhoz viszonyítva. Ha csak az Outlook asztali kliensét nézzük, mely 2007/2010/2013-as verziói alatt a World HTML motorját használják megjelenítéshez máris a 90-es évek megoldásaira kell szorítkoznunk és még szót sem ejtettünk a megannyi webes kliensről és más asztali alkalmazásról.

Van, hogy nem lehet

A fentiekben leírtam, hogy lehetőségeink korlátozottak így vannak olyan esetek, amikor egy-egy designt nem lehet sablonként megvalósítani. Például egy reszponzív hírlevél kampányt nem lehet elkészíteni egy három oszlopos design alapján úgy, hogy az megfelelően jelenjen meg desktop és mobil levelező klienseken egyaránt. Röviden: harcsapaprikást ne akarj főzni, ha a spájzban csak paprikás krumplihoz való van. Ezért érdemes a fejlesztőt már a grafikai tervezés során bevonni a megvalósíthatóságot illetően.

„A szép rögtön kell.
Az igazra alszunk egyet.
Lelkünknek elég a kép.
A testnek keret is kell.”
– Márai Sándor

Email sablon felépítése

A „táblázatos design”-ról már biztos hallottál, letűnt korok megoldása, sokan csak úgy emlegetik, hogy az internet őskorában weboldalak elrendezésére használt módszer. Ez helytálló, viszont email sablon készítéshez a legjobb megoldás, ugyanis a levelező kliensek csak ezt a felépítést jelenítik meg helyesen. Ahhoz, hogy a táblázatod valóban csak a struktúra kialakítását szolgálja, érdemes néhány alapértelmezett értéket felülírni. Cellspacinget, cellpaddingot és bordert állítsd nullára, a border-collapse-nek pedig adj collapse értéket.

Olvasottak alapján a felépítés kialakítása során érdemes figyelned arra, hogy a táblázatokat négy szintnél mélyebben ne ágyazd egymásba. Tapasztalataim szerint ennél többre nincs is szükség. Tesztek alapján öt szintnél sem jelentkeznek problémák, ennek ellenére úgy gondolom, akkor is érdemes kerülni és törekedni az egyszerűbb felépítésre.

Egy szokványos sablon felépítésénél a keretedet egy meghatározott szélességgel fixálod, ami általában 620 és 500px közé esik. Reszponzív sablon esetén keretednek fluidnak kell lennie, ami a fent említettek tükrében sem egyszerű, és még hozzá jön a megannyi mobil eszköz és levelező alkalmazás.

Egyik módszer a kereted reszponzívvá tételéhez, ha a fixen meghatározott kereted szélességét egy töréspontnál felülírod 100%-ra. Akár csak a website-oknál, ebben az esetben is mediaquery segítségével. Sajnos a mediaquery-t a Campaignmonitor adatai alapján a Gmail mobil alkalmazás egyik platformon sem támogatja, ahogy a Windows Phone 7 és 8 natív alkalmazásai sem.

Egy másik módszer, ha keretednek szélességét már az elején 100%-kal határozod meg és max-width tulajdonsággal szabályozod a maximális szélességet. Ebben az esetben számolnod kell azokkal a platformokkal és kliensekkel, melyek nem támogatják a max-width-et. Ilyen az Apple mail illetve az Outlook is.

Ahhoz, hogy az Apple mail eme hiányosságát kiküszöböld, ismét a mediaquery-t kell használdod, és meghatározott eszköz szélességtől ráerőltetni a fix szélességet.

<style type="text/css"> 
@media only screen and (min-device-width: 601px) {
    .content { width: 600px !important; } 
} 
</style>

Az Outlook ennél kicsivel körülményesebb. Ebben az esetben ki kell egészítened a keretedet egy újabb kerettel, amelynek megjelenését HTML feltételhez kötöd és fix szélességet adsz neki. Így meg is oldottad azt a problémát, hogy sablonod Outlookban teljes szélességben jelenjen meg.

<!--[if (gte mso 9)]>
<table width="600" cellpadding="0" cellspacing="0" border="0">
    <tr>
        <td>
            <![endif]-->
            <table class="content" cellpadding="0" cellspacing="0" border="0">
                <tr>
                    <td>
                        [tartalom]
                    </td>
                </tr>
            </table>
            <!--[if (gte mso 9)]>
        </td>
    </tr>
</table>
<![endif]-->

Windows Phone-ról még nem tettem említést. Eddigi tapasztalataim szerint az egyetlen, amit tehetsz, elem nyitása után elhelyezett <!–[if (IE 7)|(IEMobile)]> feltételben <style> elemek között fixen meghatározod a táblázatok és elemeinek a szélességét. Ennek hátulütője, hogy álló/fekvő helyzettől, mobil eszköz méretétől függetlenül 320px szélességben jelenik meg.

Több lehetőség is van reszponzív levél sablonod keretének kialakításához, de talán utóbbi az, ami a legtöbb esetben megfelelő megjelenést fog biztosítani a legtöbb kliensben. Természetesen mit sem ér egy jó keret, ha a meta viewportról megfeledkezel, és a dokumentum szélességét nem az eszköz szélessége adja.

<meta name="viewport" content="width=device-width,
initial-scale=1">

Stíluslapok használata

Alapesetben egy weboldal CSS kódját különálló fájlokba írjuk, melyben szelektorokkal hivatkozunk a dokumentum egyes elemeire. Így választjuk külön a struktúrát a megjelenéstől. Email template esetében ez az irányelv nem követhető. Némelyik levelező kliens ugyanis kiszűri a <link> elemet, amellyel hivatkozni tudnánk CSS fájljainkra. Lehetőségünk van a <head>-ben <style> elem használatával stílus definiciókat meghatározni, de a szelektorok kezelése szintén eltérő kliensenként.

Egy RoundCube a <style> elemben megadott szelektorokat írja át, és az általa megadott azonosítón keresztül érvényesíti a kódunkat.

#messagebody div.rcmBody #csak-egy-id { } 

Outlook.com esetében az elem class és id tulajdonságai is átírásra kerülnek, és eléjük kerül egy ecx prefix.

.ExternalClass #ecxcsak-egy-id { }

A cél mind két esetben az, hogy az email template és a webes kliens ne nyúljon bele a másik megjelenésébe, ami az első esetben nem egészen teljesül – mivel, ha a RoundCube által meghatározott azonosítót használnánk, az érvényes lenne a mi elemünkre is.
A Gmail még egy érdekes eset. Nem szűri ki a <style> taget, a szelektorokat is átírja, hogy egy generált osztályon keresztül történjen a hivatkozás, de minden elemről leszedi a class és id tulajdonságot.

Mindezek tükrében csak az úgynevezett inline CSS (azaz elemenként a style tulajdonsággal megadni a rávonatkozó formázási szabályokat) tűnik jó megoldásnak. Mint ahogy említettem, a szelektorok kezelése eltérő, úgy a CSS tulajdonságok támogatottsága is. Sablon készítése közben kiváló útmutatást ad a már fentebb említett Campaign Monitor, ahol összeszedték elemek, szelektor típusok, CSS tulajdonságok támogatottságát kliensekre levetítve egy táblázatban.

Képek

Grafikai elemek megjelenítéséhez egy website-nál backgroundot használunk. A background tulajdonságot kivétel nélkül támogatják a kliensek, sajnos az Outlook asztali és webes kliensei csak részlegesen, mivel a background-images-t nem ismerik. Így minden képi elem megjelenítéséhez az <img> elemet kell használnod.

A képek közötti eltartások megoldására több lehetőséged is van, például: padding, margin, border, sortörés (a vertikális eltartáshoz). Az igazi megjelenítési probléma szintén az Outlooknál jelentkezik, mivel ezek közül egyiket sem veszi akadály nélkül, kivéve a paddingot tábla elemre és a sortörést. Két kép közötti eltartás megtartására a legjobb, amit tehetsz, ha a képeket már eltartással vágod méretre.

Amit fontosnak tartok górcső alá venni, az a méret. Mert igenis számít a méret. Kereted már fluid, de ha tartalmad közé egy 1020 pixel széles képet ágyazol be, nem lesz az. Ezért az <img> elemeid szélességét határozd meg százalékosan, és érdemes max-width-et használni.

Mindezek ellenére a max-width-et az Outlook nem ismeri és szélesség 100 százalékra állításánál nem a keret szélességéhez viszonyít, hanem a kép méretéhez, így végeredményül a kép kitolja keretét és szétesik minden, amivel órákig foglalkoztunk. Az egyetlen, amit tehetsz, hogy a képeket méretre vágod, pontosan akkora szélességűre, mint a tartalom.
Remélem azt nem kell megemlítenem, hogy a leírtak egy ikon megjelenítéséhez használt <img>-re nem vonatkoznak – ebben az esetben fix méreteket kell meghatároznod.

Ha már méretekről van szó, a fájlméretekre is érdemes figyelmet fordítani, hisz nem szeretnéd egy hírlevéllel lerágni az olvasó fél havi adatkeretét. A tinypng.com lehetőséget biztosít arra, hogy png és jpg képeid fájlméretét drasztikusan lecsökkentsd.

Végezetül, néhány gondolat

Mielőtt belekezdenél, a grafikai tervvel szemed előtt gondold végig a struktúrát, lásd az elemeket a design mögött – így elkerülheted, hogy később a részletekbe merülve próbálj újra fókuszálni az egészre.

Tesztelj, tesztelj, tesztelj.

Tapasztalataim alapján a folyamat legnagyobb része a tesztelés és a finomhangolás. Email building közben el kell vetned minden új technológiát és leporolnod az elavult megoldásokat, mindazontúl egy újszerű kihívás és kreativitást próbáló feladat.

Végezetül ne felejtsd el, hogy miért csinálod. Olvashatóbb és szerethetőbb formába öntöd a tartalmat, ami akár több ezer emberhez is eljuthat.
Remélem sikerült ebben most segítenem.

UPDATE
A Google végre 2016. szeptember végére megígérte, hogy Gmailben támogatni fogja a media query-k használatát! \o/