Unlimited Wordpress themes, plugins, graphics & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Web Design
  2. Email
Webdesign

Amit tudnod kell a HTML emailről

by
Difficulty:BeginnerLength:LongLanguages:

Hungarian (Magyar) translation by Szabó Péter (you can also view the original English article)

Az email egy elképesztő médium. Egyenesen a postaládádba érkezik és a ROIja nagyon magas, mivel közel 4000%. De gyakran félreértik és túl gyakran rosszul csinálják. Az okostelefonok utóbbi időben történt robbanásszerű megjelenésével sokkal gyakrabban olvassuk a mailjeinket az iPhonunkon vagy Galaxynkon, de sajnos sok email marketing ezt nem tudja követni. Óriási kihagyott lehetőségnek látom ezt, mivel egy jól előadott emailt élvezet megnyitni és hihetetlenül sikeres is lehet.

A HTML email kódolása kihívást jelent

Ha már próbálkoztál a HTML email dizájnnal és fejlesztéssel, akkor arra már biztosan rájöttél, hogy meglehetősen bonyolult. El se tudod képzelni, mennyire. Ezért:

Nincs olyan, hogy email szabvány

Továbbra is a Word-öt használjuk e-mail üzenetek létrehozására, mivel úgy hisszük, hogy ez a lehető legjobb e-mail írási módszer.

Amikor a webre kódolsz, akkor legalább arra a tényre számíthatsz, hogy a főbb böngészők (Chrome, Firefox, Internet Explorer, Safari és Opera) megpróbálják alkalmazni a webes szabványokat a HTML és CSS rendereléséhez.

Amikor az email kliensek kerülnek képbe, rengeteg régi és új programot kell letesztelned. Az új, Androidot és iOS-t futtató telefonoktól az IBM Lotus Notes-áig vagy a Microsoft Office 2007-ig terjed (ami hírhedt arról, hogy az imádattal létrehozott HTML-edet a Word HTML renderelő motorjával rendereli le. Az Outlook korábbi verziói egy böngészőt használtak a HTML-jük rendereléséhez – ami végülis logikus. Miért váltanál egy szövegszerkesztőre csak azért, hogy renderelj egy HTML-t? Nos, "biztonsági okokból", azt mondják). És ezen programok egyike sem engedelmeskedik egyik szabványnak sem. Alapvetően csak összetákolják a dolgokat. Megnézheted az Email Standards Projecten, hogy az egyes szabványok milyen támogatással bírnak a népszerű email klienseken.

És ha ez még nem lenne elég, számold hozzá a következő tényt: körülbelül egymillió különböző kombinációs módja van annak, hogy az email hogyan renderelődik asztali gépen és mobilon.

demystifying-email-rendering
A renderelési lehetőségek (szinte) végtelenek.

Íme egy lista a legelterjedtebb email kliensekről:

Mobil kliensek:

  • Android 2.3 & 4.0
  • iPhone 5 iOS 6
  • iPhone 4S iOS 6
  • iPhone 3GS iOS 5
  • iPad 2 iOS 6
  • BlackBerry OS 4 & 5
  • Symbian S60
  • Windows Phone 7.5

Asztali kliensek:

  • Apple Mail 4, 5, 6
  • Lotus Notes 8.5
  • Lotus Notes 8
  • Thunderbird
  • Windows Live Mail
  • Outlook 2013
  • Outlook 2011 for Mac
  • Outlook 2010
  • Outlook 2007
  • Outlook 2003
  • Outlook 2002/XP
  • Outlook 2000

Webmail kliensek:

  • AOL Mail (bármelyik böngészőn)
  • Gmail (bármelyik böngészőn)
  • Outlook.com (bármelyik böngészőn)
  • Yahoo! (bármelyik böngészőn)

Ez rengeteg eszköz!

Ha már jártas vagy a webfejlesztésben, felejts el mindent, amit tudtál róla.

Mindent összevetve a feltételes stilizálásra nem sok lehetőség van. Van néhány dolog, amiket meg tudunk tenni a feltételes kommentekkel, de azok az Outlook bizonyos verzióira vonatkoznak csak, vagy pedig mindenre, kivéve az Outlook bizonyos verzióit.

Ha már jártas vagy a webfejlesztésben, felejts el mindent, amit tudtál róla. A legnagyobb akadály, hogy azt várod, a dolgok úgy működnek, mint a 'normál' webfejlesztésnél. Ez frusztrálni fog téged és vissza is fog tartani. A legrosszabb dolog, amit tehetsz, hogy bedühödsz amiért nem használhatsz DIVeket vagy hogy a margin nem teljesen támogatott. Szóval felejts el mindent, amit tudtál a szemantikus HTML-ről és a legújabb CSS specifikációról. Higgy nekem, segíteni fog.

Hogyan közelítsd meg a feladatot

Vessünk egy pillantást néhány e-mail felépítési munkafolyamat javaslatra.

Először a szerkezetén dolgozz

Az emailed szerkezetének kialakításával kezdeni sok bugtól és hibától megkímél a későbbiek folyamán. Soha ne építsd fel az egészet és teszteld utána – gyakran túl sok buggal kell megküzdened, és lehet, hogy ezek egymást befolyásolják.

Teszteld sűrűn

Dolgozz addig, amíg el nem érsz egy kisebb fejlesztési mérföldkövet (például az alapszerkezet kialakítása), és utána futtass le egy tesztet. A tesztelés legjobb módja a Litmus vagy az Email on Acid használata. Én azt javaslom, hogy szerezz be egy korlátlan csomagot mindkét vállalatnál, mivel a gyakori tesztelés nagyon fontos.

Én szeretem fennhagyni az összes táblázatom szegélyét, mert így láthatom, mit hozok létre, és csak a legvégén kapcsolom ki őket. Akár bizonyos cellák hátterét is beszínezheted, hogy segítsenek látni, melyik részen vagy éppen. Az ideális munkafolyamatom a következő: váz létrehozása, tesztelés, utána a tartalmam hozzáadása, tesztelés, a színek és betűk stilizálása, újra tesztelés és végül a szegélyeim eltávolítása és egy újabb teszt elküldés előtt.

Validáld gyakran

Validáld a W3C Validator használatával olyan gyakran, amennyire csak tudod. Ez segíthet helyrerakni az apró részleteket és megmutatja a hibákat, például egy hiányzó vagy egy nyitó taget.

Az emailed elküldése

Rengeteg lehetőség jön szóba, amikor az emailed elküldésére kerül sor. Az általam leginkább használt két szolgáltatás a MailChimp és a Campaign Monitor. Elfogadható árat kérnek és nagyon könnyű használni. Van még rengeteg más kereskedelmi platform is – minden az igényeidtől függ. Regisztrálj egy ingyenes fiókért mindkettőnél, és próbáld ki a rendszereiket, hogy lásd, melyik tetszik neked. Győződj meg róla, hogy tudod hasznosítani az adatokat, amiket mindkét szolgáltatás gyűjt az emailjeidről, mint például a megnyitási idő és az email kliens használata. Ez nagyban segíthet a megfelelő területre összpontosítani az erőfeszítéseidet a következő alkalommal, amikor küldesz egy újabb levelet.

Tartalom, fejlesztés és SPAM pontok

Amikor a SPAM: tartalom, dizájn és fejlesztés kerül sorra, minden kéz a kézben jár együtt. Fontos, hogy elkerüld a tipikus spammelési taktikákat, például a csupa nagybetű és a sok felkiáltójel használatát a tárgysorban. Vannak bizonyos szavak, amik valószínűleg aktiválják a SPAM szűrőket is (mint a 'free' és 'invest'). Minél tisztább a kódod, annál kisebb valószínűséggel lesz a leveled SPAMnek jelölve, és a képek szöveghez való aránya is hatással van erre. A szöveg nélküli, képtartalmú emailek nagyobb valószínűséggel lesznek SPAMnek jelölve, ahogy a nagyon hosszú fájlnevű képeket tartalmazók is.

A SPAM pontok világa trükkös, és fontos lefuttatni egy SPAM tesztet a tesztfiókodon Litmusszal vagy Email on Aciddal még az email elküldése előtt, hogy biztos legyél benne, a nehezen elvégzett munkád nem kerül egyenesen a Kuka mappába.

A fejlesztés

Most érkeztünk el az email fejlesztés sava-borsához...

Szükséges eszközök

Szükséged lesz egy általad kedvelt szövegszerkesztőre (én Sublime Textet használok), és egy tesztfiókra a Litmusnál vagy az Email on Acidnél. Erősen javaslom, hogy legyen egy korlátlan tesztfiókod mindkét vállalatnál, mivel jelentősen megkönnyíti az életedet. Ha nem fizetsz havidíjat, akkor a végén tesztenként 3 és 5 dollár közti összeget kell kifizetned, ami elég gyorsan összeadódik.

Kezdés jó alapokkal

Azt hiszem, érdemes egy üres lappal kezelni. A HTML Email Boilerplatehez hasonló keretrendszerek tele vannak csodálatos trükkökkel és snippetekkel, amiket szép sorban implementálni tudsz. Ugyanakkor ha épp csak most fogsz bele, nem ajánlom kiindulópontként, mivel rengeteg olyan elemet tartalmaz, amire nincs szükséged. A boilerplate-ek gyakran megnehezítik a problémák elhárítását, ha sok fel nem használt kód van a fájlodban.

Megjegyzés: Mivel nagyon nem megbízható bármiféle szerkesztő használata (különösen problémamegoldáshoz), soha nem szabad WYSIWYG vagy bármi olyan szerkesztőt használni, ami azt ígéri, hogy fogja a formázott dizájnodat és valid HTML-lé alakítja emailezéshez. Ez egyszerűen nem működik.

!DOCTYPE

Úgy tűnik, mintha technikai részletezéssel kellene kezdened, de szükséged lesz egy üres sablonra, amivel tudsz dolgozni, és a sablonnal pedig szüksége lesz egy Doctype-ra. A doctype lényegében egy sor kód, ami tájékoztatja az őt olvasó programot, hogy milyen HTML tageket várhatnak, és hogy milyen HTML és CSS szabályokhoz kell ragaszkodniuk. Pár kliens teljesen kiveszi a Doctype-odat, sőt, néhány a sajátját rakja hozzá. Sok más kliens viszont tiszteletben tartja a doctype-odat és nagyban megkönnyíti a dolgodat, amikor validálod Doctype szerint.

Egy XHTML doctype használatával van általában a legkevesebb váratlan dolog és ellentmondás a dokumentumok között. Én az XHTML 1.0 Transitionalt használom, mert tapasztalataim szerint ez bizonyult a leginkább megbízható doctype-nak. A következő bemutatóban, melyben egy teljes HTML email sablont készítünk, a következő kódot fogjuk használni a dokumentumunk elkezdésére:

A Content-Type meta tag elmondja a renderelő motornak, hogy hogyan dolgozza fel a szöveget és a speciális karaktereket. A valóságban az összes speciális karakteredet le kell kódolni (pl.: &-ból & lesz), hogy biztonságosan megjelenjenek.

A viewport meta tag azt mondja az eszköznek, hogy állítsa a látható területet az eszköz képernyőjének szélességére. Ezen kívül a nagyítást 'normál'-ra állítja, azaz nem lesz se nagyított, sem kicsinyített. Ha ezt nem határozod meg, akkor sok okostelefon esetleg leskálázza a tartalmat, így a tartalom ugyan be fog férni a látható területbe, de a térközt és a margót leveszi. Ez azt eredményezheti, hogy a szöveg és a képek közvetlenül a képernyő szélén fognak kezdődni.

Végül mindig adj értelmes címet neki, mert ezt fogják látni az emberek, amikor megnézik az emailt egy böngészőben vagy amikor megosztják az ismerőseikkel.

Az emailek nem csak a táblázatok elhelyezéséről szólnak

Az emailben a szabvány támogatás hiánya miatt nem lehetséges divek, sectionök és articlesek használata – ehelyett táblázatokat használsz. Sőt, rengeteg beágyazott táblázatot kell használnod, mivel sem a colspan, sem a rowspan attribútumok nem támogatottak megfelelően.

demystifying-email-nesting

Bekezdések vagy cellák?

Megismételve a szabványok támogatásának hiánya miatt nem jó ötlet olyan szabvány tagek használata, mint a h1, h2, h3 vagy p. Úgy vettem észre, hogy ezeket igazán következetlenül renderelik az email kliensek, ami elég sok fejfájást okozhat.

A legjobb, ha minden szövegblokkot egy-egy cellába teszel és beágyazott stílust használsz arra a cellára, például:

Beágyazott stílusok vagy stíluslapok?

Ez leginkább személyes döntés. Szeretem a stílusaimat beágyazva (értsd: magukban a HTML tagekben) tartani, mivel szeretem pontosan tudni, mi hol van és mi mire van hatással. Kódolhatsz stílusok használatával úgy, hogy majd csak a végén ágyazod be (a Campaign Monitor és a MailChimp ezt automatikusan megcsinálja számodra, vagy használhatsz Premailert vagy valami hasonlót), de én ezt azért nem szeretem, mert ismerned kell a kódodat, be kell ágyaznod, és ennek következtében a kódod szinte felismerhetetlenné válhat. Szerintem ez megnehezíti a hibakeresést. De ha ily módon szeretnél dolgozni, az is rendben van; nincs semmilyen technikai oka, hogy miért nem tehetnéd meg.

Ne feledd: Nem rendelhetsz a HTML emailben több osztályt a dolgokhoz, mert az nem támogatott. Minden elemnek maximum egy osztálya lehet.

Ezt se feledd: Nem használhatsz rövid változatokat olyan dolgokra, mint a betűméret (pl.: style="font: 8px/14px Arial, sans-serif;"), mivel az sem támogatott.

Képnevek és SPAM pontok

Amikor elmented a képeket, jusson eszedbe, hogy célszerű rövid és jelentéssel bíró képneveket adni, mivel megnöveli a spam pontodat. Az olyan nevek, mint a "campaign_054_design_0x0_v6_email-link.gif" valószínűleg sokkal magasabb SPAM ponttal bírnak, mint az "email.gif".

Képméret

Szintén jó ötlet megpróbálni az egész emailedet olyan kis méretben tartani, amennyire emberileg lehetséges: 100kb alatt ideális, de nem mindig lehetséges, 250kb alatt még elfogadható. Használj egy tömörítő alkalmazást, mint a JPEGmini vagy tinyPNG, hogy lecsökkentsd a képek méretét küldés előtt annyira, amennyire csak lehetséges. Ha az összes fájlméret túl nagy, a lassabb betöltési idő, különösen mobilon, sikert vagy bukást jelent az emailedre nézve.

Egyéb problémák

Ne hagyj rá semmit az email kliensedre. Határozd meg mindennek a szélességét, mert máskülönben váratlan eredményeket kaphatsz. A fő tartalmazó elemnek mindig pixelben add meg a méretét. Ha szeretnél, ezen a tartalmazó elemen belül használhatsz százalékos megadást.

Konklúzió

Rengeteg egyéb dolgot is figyelembe kell venni, amikor egy HTML emailt tervezel és fejlesztesz, melyek többsége magába foglalja azon szabványok "nem-tanulását", amelyeket a webdizájn kapcsán éveken át gyakoroltál. Ugyanakkor ez a bemutató szilárd alapokat ad számodra a nekikezdéshez, és most már készen állsz belevágni a tényleges kialakítási folyamatba. Tovább!

Hasznos linkek

Belinkeltem néhány dolgot ebbe a bemutatóba – ezeket leírom ide újra, mindet egy helyre.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.