Share
E-mail is een geweldig medium. Het gaat rechtstreeks naar de inbox en de ROI wordt algemeen gerapporteerd als door het dak op 4000%. Het is ook onophoudelijk verkeerd begrepen en te vaak is het slecht gedaan. Met de recente explosie van smartphones lezen we vaker onze e-mail op onze iPhone of Galaxy, maar helaas hebben veel e-mailmarketing het niet bij kunnen houden. Ik zie dit als een enorme gemiste kans omdat een goed uitgevoerde e-mail leuk kan zijn om te openen en enorm succesvol is.
Als je al hebt geprobeerd HTML-e-mailontwerp en -ontwikkeling te volgen, heb je waarschijnlijk al vastgesteld dat het behoorlijk moeilijk kan zijn. En je verbeeld je het niet - het is best moeilijk. Dit is waarom:
[We zullen] Word blijven gebruiken voor het maken van e-mailberichten omdat we denken dat dit de beste e-mail authoring-ervaring is.
Het Outlook-team
Wanneer u codeert voor het web, kunt u er op zijn minst op rekenen dat alle grote browsers (Chrome, Firefox, Internet Explorer, Safari en Opera) zich aan webstandaarden proberen te houden voor het weergeven van HTML en CSS.
Als het gaat om e-mailclients, test u een groot aantal oude en nieuwe programma's. Deze variëren van nieuwe telefoons op Android en iOS tot IBM Lotus Notes of Microsoft Office 2007 (die berucht uw liefdevol gemaakte HTML rendert met de HTML-renderingengine voor Word.De vorige versies van Outlook gebruikten een browser om hun HTML weer te geven - wat eigenlijk is logisch. Waarom overschakelen naar een tekstverwerker om HTML te maken die u vraagt? Nou, om "veiligheidsredenen", zeggen ze). En geen van deze programma's hoeft aan enige normen te voldoen. Ze maken het eigenlijk allemaal gewoon goed. U kunt zien hoe de standaardondersteuning eruitziet voor enkele van de populairste e-mailclients in het project Email Standards.
Als dat niet erg genoeg is, koppel dat dan met het volgende feit: er zijn ongeveer een miljoen verschillende combinaties van manieren die e-mail op desktop en mobiel kan renderen.
De weergavemogelijkheden zijn (bijna) eindeloos. Hier is een lijst met enkele van de meest voorkomende e-mailclients:
Mobiele clients:
Desktop-clients:
Webmail-clients:
Dat zijn veel apparaten!
Als u al bekend bent met webontwikkeling, vergeet dan alles wat u weet.
Om dit alles samen te stellen, is conditionele styling ook niet echt een optie. Er zijn enkele dingen die u kunt doen met voorwaardelijke opmerkingen, maar deze is beperkt tot het targeten van bepaalde versies van Outlook of alles behalve bepaalde versies van Outlook.
Als u al bekend bent met webontwikkeling, vergeet dan alles wat u weet. Het grootste obstakel voor u is dat dingen werken zoals 'normale' webontwikkeling. Dit zal je frustreren en je tegenhouden. Het ergste wat je kunt doen is boos worden dat je geen DIV's of dat kunt gebruiken marge wordt niet volledig ondersteund. Dus vergeet alles wat u weet over semantische HTML en de nieuwste CSS-specificaties. Vertrouw me, het zal helpen.
Laten we een paar suggesties voor het maken van workflows voor e-mail bekijken.
Door eerst de structuur van uw e-mail te bouwen, kunt u later vele bugs en problemen voorkomen. Bouw nooit het hele ding en test dan - je kunt vaak eindigen met te veel bugs om mee om te gaan, en ze kunnen allemaal elkaar beïnvloeden.
Werk totdat u een kleine ontwikkelingsmijlpaal bereikt (bijvoorbeeld wanneer u de basisstructuur hebt voltooid) en voer vervolgens een test uit. De beste manier om te testen is het gebruik van Litmus of Email on Acid. Ik raad aan om bij deze bedrijven een onbeperkt abonnement te nemen omdat het vaak erg belangrijk is om vaak te testen.
Ik vind het ook heel leuk om in al mijn tafelranden weg te gaan, zodat ik kan zien wat ik aan het maken ben, en dan schakel ik ze allemaal uit aan het einde. U kunt ook de achtergrond van bepaalde cellen kleuren om te zien welke secties waar zijn. Mijn ideale workflow is om een skelet te maken, test, voeg dan mijn inhoud toe, test, style de kleuren en lettertypen, test opnieuw en verwijder tenslotte mijn randen en test opnieuw voor verzending.
Valideer het zo vaak mogelijk met de W3C Validator. Dit zal je helpen kleine details glad te strijken en het zal fouten als ontbrekende of open tags oppikken.
Er zijn een groot aantal opties als het gaat om het verzenden van uw e-mail. De twee services die ik het meest gebruik, zijn MailChimp en Campaign Monitor. Ze bieden concurrerende prijzen en ze zijn heel gemakkelijk te gebruiken. Er zijn ook veel commerciële platforms - het hangt allemaal af van uw behoeften. Meld je aan voor een gratis account bij een van deze sites en laat een knutsselaar in hun systeem zien om te zien welke je leuk vindt. Zorg ervoor dat u de nuttige gegevens gebruikt die beide services over uw e-mails verzamelen, zoals open tijden en het gebruik van e-mailclients. Dit kan u echt helpen uw inspanningen op het juiste gebied te concentreren de volgende keer dat u verzendt.
Als het gaat om SPAM; inhoud, ontwerp en ontwikkeling gaan allemaal hand in hand. Het is belangrijk om typische spammy-tactieken te vermijden, zoals het gebruik van caps en veel uitroeptekens in uw onderwerpregel. Er zijn bepaalde woorden die waarschijnlijk ook SPAM-filters activeren (zoals 'gratis' en 'investeren'). Hoe schoner uw code, hoe kleiner de kans dat uw e-mail als SPAM wordt gemarkeerd en de verhouding tussen afbeeldingen en tekst ook een effect heeft. Beeldafhankelijke e-mails zonder tekst worden eerder als SPAM gemarkeerd en dat geldt ook voor e-mails met hele lange bestandsnamen.
De wereld van SPAM-scores is een lastige en het is belangrijk om een SPAM-test uit te voeren via je testaccount met Litmus of Email on Acid voordat je je e-mail verzendt, om er zeker van te zijn dat al je harde werk niet recht op de map Ongewenst terechtkomt.
Nu, voor de onbetwistbaarheid van e-mailontwikkeling ...
Je hebt een teksteditor nodig die je leuk vindt (ik gebruik Sublime-tekst) en een testaccount met Litmus of Email on Acid. Ik raad ten zeerste aan om een onbeperkt testaccount bij een van deze bedrijven te hebben, omdat het je leven zo veel gemakkelijker zal maken. Als u geen maandelijks bedrag betaalt, betaalt u uiteindelijk tussen $ 3 en $ 5 per test, wat vrij snel kan oplopen.
Ik denk dat het goed is om met een schone lei te beginnen. Kaders zoals de HTML Email Boilerplate zitten vol met prachtige trucs en fragmenten die je stuk voor stuk kunt implementeren. Als u echter net begint, raad ik u aan dit als uitgangspunt te gebruiken omdat het veel elementen bevat die u niet nodig hebt. Boilerplates kunnen het vaak moeilijker maken om problemen op te lossen als er veel ongebruikte code in uw bestand staat.
Notitie: Omdat het erg onzeker kan zijn om elke vorm van editor te gebruiken (vooral wanneer het tijd is om problemen op te lossen), moet u nooit een WYSIWYG-editor gebruiken, of een editor die belooft uw opgemaakte ontwerp te nemen en op magische wijze in geldige HTML te veranderen voor e-mailen . Dit spul werkt gewoon nooit.
Dit lijkt misschien een technisch detail om mee te beginnen, maar je hebt een lege sjabloon nodig om mee te werken en die sjabloon heeft een Doctype nodig. Een doctype is in wezen een coderegel die het programma informeert welke HTML-tags moeten worden verwacht en aan welke set regels de HTML en CSS voldoen. Heel wat klanten ontdoen uw Doctype en sommigen passen zelfs hun eigen doctype toe. Veel klanten eren je doctype en het kan de dingen veel gemakkelijker maken als je constant kunt valideren tegen een Doctype.
Het gebruik van een XHTML-doctype heeft doorgaans de minste eigenaardigheden en inconsistenties tussen documenten. Ik gebruik XHTML 1.0 Transitional omdat het heeft bewezen het meest betrouwbare doctype te zijn in mijn ervaring. In de volgende zelfstudie, waarin we een volledige HTML-e-mailsjabloon maken, gebruiken we de volgende code om ons document te starten:
Demystifying Email Design
De Content-Type Metatag is bedoeld om de bestemmingsweergave-engine te laten weten hoe tekst en speciale tekens moeten worden verwerkt. In werkelijkheid moet je toch al je speciale personages coderen (bijvoorbeeld & wordt & voor ampersand) om veilig te zijn, maar het is de moeite waard om deze regel daar toch te houden.
De metatag voor de viewport vertelt het apparaat om het te bekijken gebied in te stellen op de breedte van het scherm van het apparaat. Het stelt ook de beginschaal in op 'normaal', waardoor noch ingezoomd noch uitzoomd wordt. Als u dit niet opgeeft, kunnen veel smartphones uw inhoud opschalen, zodat de inhoud binnen het zichtbare gebied past, maar niet de opvulling of marges. Dit kan ertoe leiden dat tekst en afbeeldingen tegen de rand van het scherm worden afgedrukt.
Ten slotte, voer altijd een zinvolle titel in, want dit is wat mensen zien wanneer ze de e-mail bekijken in een browser of delen met hun vrienden.
Vanwege het gebrek aan standaardondersteuning in e-mail, is het niet mogelijk om divs, secties of artikelen te gebruiken - in plaats daarvan moet u tabellen gebruiken. Bovendien moet je heel veel geneste tabellen gebruiken, omdat geen van beide colspan noch rowspan attributen worden goed ondersteund.
Nogmaals, vanwege het gebrek aan standaardondersteuning, is het geen geweldig idee om standaardtags zoals te gebruiken h1, h2, h3 of p. Ik merk dat deze heel inconsistent kunnen worden weergegeven in e-mailclients en dat het behoorlijk grote kopzorgen kan veroorzaken.
Je kunt het beste doen om elk blok tekst in een eigen cel te plaatsen en inline styling toe te passen op die cel, bijvoorbeeld:
Tekst
Deze is meer een persoonlijke keuze. Ik geef er de voorkeur aan al mijn stijlen inline te houden (dat wil zeggen: binnen de HTML-tags zelf) omdat ik graag precies weet waar alles is en wat van invloed is op wat. Je kunt codes gebruiken met behulp van stijlen en ze vervolgens allemaal inline aan het einde trekken (Campaign Monitor en MailChimp kunnen dit automatisch voor je doen, je kunt ook Premailer of iets dergelijks gebruiken) maar de reden dat ik dit niet leuk vind, is omdat je weet uw code, voer deze uit via een inliner en dan kan uw code enigszins onherkenbaar worden. Ik merk dat dit het moeilijker maakt om problemen op te lossen. Zeggen dat, als dit de manier is waarop je wilt werken, dat is prima; er is geen technische reden waarom je het niet zou moeten doen.
Vergeet niet: U kunt in HTML-e-mail geen meerdere klassen op dingen toepassen, omdat dit niet wordt ondersteund. Elk element kan maximaal één klasse hebben.
Vergeet ook niet: U kunt geen steno gebruiken voor zaken als lettergrootte (d.w.z.) omdat deze niet wordt ondersteund.
Denk er bij het opslaan van afbeeldingen aan dat het goed is om uw afbeeldingen namen te geven die kort en betekenisvol zijn omdat het uw spamscore zal verbeteren. Namen als 'campaign_054_design_0x0_v6_email-link.gif' hebben waarschijnlijk een veel hogere SPAM-score dan 'email.gif'.
Het is ook een heel goed idee om te proberen je hele e-mail zo klein mogelijk te houden als menselijk mogelijk: minder dan 100 kB is ideaal, maar niet altijd mogelijk, onder 250 kb is vrij standaard. Gebruik een compressieapp zoals JPEGmini of tinyPNG om al uw afbeeldingen zoveel mogelijk op maat te knippen voordat u verzendt. Langere laadtijden, vooral op mobiele apparaten, kunnen uw e-mail maken of breken als de algemene bestandsgrootte te groot is.
Laat niets aan de e-mailclient over. Geef al uw breedten op, anders kunt u onverwachte resultaten krijgen. Stel voor uw belangrijkste containerelementen altijd de grootte in pixels in. U kunt dan percentages in uw element gebruiken als u dat wilt.
Er is veel om rekening mee te houden bij het ontwerpen en ontwikkelen van HTML-e-mail, waarvan de meeste betrekking hebben op "niet-lerende" standaarden die u in de loop der jaren hebt aangemoedigd om te oefenen voor webdesign. Deze tutorial had je echter een solide basis moeten geven om vanaf te werken, en je bent nu klaar om in het daadwerkelijke bouwproces te springen. Onwards!
Ik heb tijdens deze tutorial naar een aantal dingen verwezen, dus hier zijn ze weer allemaal op één plek.
Accentsconagua