Hvis du åbner et indholdsstyringssystem for at bygge websider, er det en ret simpel proces. Moderne webbrowsere understøtter HTML, CSS og JavaScript til en streng sæt webstandarder. Og de er i virkeligheden kun en håndfuld browsere, som designere skal bekymre sig om. Der er selvfølgelig undtagelser ... og nogle enkle løsninger eller funktioner, der er specifikke for disse browsere.
På grund af de overordnede standarder er det virkelig nemt at udvikle sidebyggere i indholdsstyringssystemer. Browsere overholder HTML5, CSS og JavaScript... og udviklere kan bygge utrolig robuste løsninger til at bygge websider, der er lydhøre over for enheder og konsistente på tværs af browsere. For to årtier siden brugte stort set alle webdesignere desktopsoftware til at udvikle websider. Nu er det ret ualmindeligt, at en webdesigner udvikler en webside – oftere end ikke udvikler de skabeloner og bruger redaktører i indholdssystemer til at udfylde indholdet. Hjemmesideredaktører er fantastiske.
Men e-mail-redaktører er sørgeligt bagud. Her er hvorfor...
At designe HTML-e-mails er langt mere komplekst end til et websted
Hvis din virksomhed ønsker en smuk HTML-e-mail designet, er processen eksponentielt mere kompleks end at bygge en webside af en række årsager:
- Ingen standarder – Der er INGEN streng overholdelse af noget web standarder af e-mail-klienter, der viser HTML-e-mail. Faktisk virtuelt hver e-mail-klient og hver version af hver e-mail-klient handler anderledes. Nogle vil ære CSS, eksterne skrifttyper og moderne HTML. Andre ærer noget inline-styling, vil kun vise en samling af skrifttyper og ignorerer alt andet end tabeldrevne strukturer. Det er faktisk ret latterligt på nuværende tidspunkt, at ingen arbejder med dette spørgsmål. Som følge heraf er design af skabeloner, der gengives på tværs af klienter og enheder konsekvent, blevet big business og kan være ret dyrt.
- Email Client Sikkerhed – Bare i denne uge opdaterede Apple Mail til at blokere alle billeder i HTML-e-mails som standard, der ikke er indlejret i e-mailen. Du giver enten tilladelse til at indlæse dem en e-mail ad gangen, eller du skal aktivere indstillingerne for at deaktivere denne indstilling. Sammen med sikkerhedsindstillinger for e-mailklienter er der også virksomhedsindstillinger.
- IT-sikkerhed – Dit it-team kan implementere strenge regelsæt for, hvilke objekter der rent faktisk kan gengives i en e-mail. Hvis dine billeder for eksempel kommer fra et bestemt domæne, der ikke er hvidlistet i en virksomheds firewall, vil billeder simpelthen ikke dukke op i din e-mail. Til tider har vi været nødt til at udvikle e-mails og hoste alle billederne på virksomhedens server, så deres egne medarbejdere kunne se billederne.
- E-mail-udbydere – For at gøre tingene værre, e-mail-byggere, som e-mail-tjenesteudbydere (ESPs) faktisk indføre problemer i stedet for at begrænse dem. Mens de fremmer deres redaktør er Hvad du ser, er hvad du får (WYSIWYG), er det modsatte ofte tilfældet med e-maildesign. Du vil forhåndsvise e-mailen på deres platform, hvorefter e-mail-modtageren ser alle former for designproblemer. Virksomheder vælger ofte ubekendt en funktionsrig editor i stedet for en låst redaktør, der tror, at den ene har flere funktioner end den anden. Det modsatte er sandt ... hvis du vil have e-mails, der gengives konsekvent på tværs af alle e-mail-klienter, jo enklere jo bedre, fordi mindre kan gå galt.
- Gengivelse af e-mailklient – Der er hundredvis af e-mail-klienter, som hver gengiver HTML forskelligt på tværs af desktop-, apps-, mobil- og webmail-klienter. Mens din smarte teksteditor på din e-mail-tjenesteudbyder kan have en indstilling til at sætte en overskrift i din e-mail... kan polstring, marginer, linjehøjde og skriftstørrelse variere på hver enkelt e-mail-klient. Som et resultat er du nødt til at dumme HTML'en og kode hvert enkelt element anderledes (se eksemplet nedenfor) - og ofte skrive undtagelser, der er e-mailklientspecifikke - for at få en e-mail til at gengives konsekvent. Der er ingen simple bloktyper, du skal lave tabeldrevne layouts, der svarer til at bygge til nettet for tredive år siden. Det er derfor, ethvert nyt layout kræver både udvikling og cross-e-mail klient- og enhedstest. Det, du ser i din indbakke, kan være helt anderledes, hvad jeg ser i min indbakke. Det er derfor, at rendere værktøjer som E-mail på syre or Lakmus er et must for at sikre, at dine nye designs fungerer på tværs af alle e-mail-klienter. Her er en kort liste over populære e-mail-klienter og deres gengivelsesmotorer:
- Brug af Apple Mail, Outlook til Mac, Android Mail og iOS Mail WebKit.
- Brug af Outlook 2000, 2002 og 2003 Internet Explorer.
- Brug af Outlook 2007, 2010 og 2013 Microsoft Word (ja, Word!).
- Webmail-klienter bruger deres browsers respektive motor (for eksempel bruger Safari WebKit, og Chrome bruger Blink).
Et eksempel på HTML til web vs. E-mail
Hvis du vil have et eksempel, der illustrerer kompleksiteten i at designe i e-mail kontra nettet, er her et perfekt eksempel fra Mailbakerys artikel 19 store forskelle mellem e-mail og web-html:
Vi er nødt til at bygge en række tabeller, der inkorporerer al den inline-styling, der er nødvendig for at placere knappen korrekt og sikre, at den ser godt ud på tværs af e-mail-klienter. Der vil også være et medfølgende stilmærke øverst i denne e-mail for at inkorporere klasserne.
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="left">
<table border="0" cellspacing="0" cellpadding="0" bgcolor="#43756e">
<tr>
<td class="text-button" style="padding: 5px 20px; color:#ffffff; font-family: 'Oswald', Arial, sans-serif; font-size:14px; line-height:20px; text-align:center; text-transform:uppercase;">
<a href="#" target="_blank" class="link-white" style="color:#ffffff; text-decoration:none"><span class="link-white" style="color:#ffffff; text-decoration:none">Find Out More</a>
</td>
</tr>
</table>
</td>
</tr>
</table>Website
Vi kan bruge et eksternt stylesheet med klasser til at definere sagen, justeringen, farven og størrelsen af et ankermærke, der vises som en knap.
<div class="center">
<a href="#" class="button">Find Out More</a>
</div>Sådan undgår du problemer med e-maildesign
Problemer med e-maildesign kan undgås ved at følge en anstændig proces:
- Skabelon design – Byg en skabelon med forskellige layouts og indholdsblokke, der omfatter enhver stil, som du nogensinde ønsker at producere i dine e-mail-designs. Når vi implementerer en klient, presser vi dem altid til designe en e-mail til fremtiden – ikke kun den næste e-mail-kampagne, der sendes ud. På den måde kan vi fuldt ud designe, udvikle, teste og implementere de nødvendige løsninger før de sender nogensinde den første e-mail.
- Skabelon test – At forstå de e-mail-klienter, som dine abonnenter bruger, og at sikre, at din HTML-e-mail er fuldt testet på tværs af mobil og desktop, er afgørende, før du implementerer en skabelon. Vi kan designe en e-mail bogstaveligt fra et photoshop-layout... men at skære den op i en tabeldrevet cross-e-mail-klient er afgørende for at implementere e-mail-designs, der er optimale og konsistente.
- Intern test – Når din skabelon er designet og testet, skal den sendes til en intern seed-liste i organisationen for at gennemgå og godkende. Du vil måske endda starte med en meget begrænset delmængde af enkeltpersoner for først at sikre, at der ikke er firewall- eller sikkerhedsproblemer forbundet med gengivelse af e-mailen internt. Hvis dette bygger en instans ud på en ny e-mail-tjenesteudbyder, kan du endda finde nogle filtrerings- eller blokeringsproblemer forbundet med selv at få din e-mail til indbakken.
- Skabelonversionering – Ændre ikke dine layouts eller designs uden at arbejde på en ny version af din skabelon, der kan designes, testes korrekt og implementeres. Mange virksomheder elsker enkeltstående designs til hver kampagne... men det kræver, at hver e-mail er designet, udviklet og implementeret til hver kampagne. Dette tilføjer masser af tid til den interne e-mailmarketingproces. Og du risikerer ikke at forstå, hvilke elementer i din e-mail, der fungerer godt i forhold til, hvilke elementer der ikke er. Konsistens er ikke kun en måde at gøre processen nemmere på, det er også vigtigt for dine abonnenters adfærd.
- Undtagelser fra e-mail-tjenesteudbydere – Stort set alle e-mail-tjenesteudbydere har et middel til at omgå de problemer, som deres e-mail-bygger introducerer. Vi kan ofte tilføje rå CSS til en konto - eller endda have en indholdsblok, der skal inkluderes i hver e-mail - for at virksomheden kan bruge den indbyggede e-mail-editor og ikke få den til at bryde designet af din e-mail. Det kan selvfølgelig kræve noget træning og proceskontrol for at implementere disse trin for at sikre, at de bliver overholdt. Eller - du vil måske bogstaveligt talt bare udvikle dit e-mail-design i en løsning, der har vist sig at fungere på tværs af klienter og enheder, og derefter indsætte det i din e-mail-tjenesteudbyder.
E-mail design platforme
Fordi e-mail-serviceplatforme har gjort et dårligt stykke arbejde med at opbygge og vedligeholde konsekvent renderede buildere på tværs af klienter og på tværs af enheder, er der kommet en række fantastiske platforme på markedet. En som vi har brugt flittigt er Stripo.
Stripo er ikke bare en e-mail-bygger, de har også et bibliotek med over 900 skabeloner, som nemt kan importeres. Når du har designet e-mailen, kan du sende e-mailen til 60+ ESP'er og e-mail-klienter, inklusive MailChimp, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlook og Gmail. Det bedste af alle Strip-skabeloner kommer med e-mail-gengivelsestestene inkluderet, så du kan sikre dig, at de er blevet testet og fungerer konsekvent på tværs af over 40 e-mail-klienter.
Log ind på Stripo Editor-demoen
Offentliggørelse: Jeg linker til min marketingkonsulentfirma der designer og implementerer e-mails på tværs af klienter til førende brands i stort set enhver e-mail-tjenesteudbyder. Jeg er også tilknyttet Stripo og jeg bruger mit link i denne artikel.
