Hvis du åpner et innholdsstyringssystem for å bygge nettsider, er det en ganske enkel prosess. Moderne nettlesere støtter HTML, CSS og JavaScript til en streng sett med webstandarder. Og de er egentlig bare en håndfull nettlesere som designere trenger å bekymre seg for. Det er unntak, selvfølgelig ... og noen enkle løsninger eller funksjoner som er spesifikke for disse nettleserne.
På grunn av de generelle standardene er det veldig enkelt å utvikle sidebyggere i innholdsstyringssystemer. Nettlesere overholder HTML5, CSS og JavaScript... og utviklere kan bygge utrolig robuste løsninger for å bygge nettsider som er responsive på enheter og konsistente på tvers av nettlesere. For to tiår siden brukte praktisk talt alle webdesignere desktop-programvare for å utvikle nettsider. Nå er det ganske uvanlig at en webdesigner utvikler en nettside – oftere enn ikke utvikler de maler og bruker redaktører i innholdssystemer for å fylle ut innholdet. Nettstedsredaktører er fantastiske.
Men e-postredaktører er sørgelig bak. Her er hvorfor...
Å designe HTML-e-poster er langt mer komplisert enn for et nettsted
Hvis bedriften din vil ha en vakker HTML-e-postdesign, er prosessen eksponentielt mer kompleks enn å bygge ut en nettside av en rekke årsaker:
- Ingen standarder – Det er INGEN streng overholdelse av noe web standarder av e-postklienter som viser HTML-e-post. Faktisk så og si hver e-postklient og hver versjon av hver e-postklient opptrer annerledes. Noen vil respektere CSS, eksterne fonter og moderne HTML. Andre ærer noe innebygd stil, vil bare vise en samling fonter og ignorerer alt annet enn tabelldrevne strukturer. Det er faktisk ganske latterlig på dette tidspunktet at ingen jobber med denne saken. Som et resultat har det å designe maler som gjengir på tvers av klienter og enheter konsekvent blitt big business og kan være ganske dyrt.
- E-postklientsikkerhet – Bare denne uken oppdaterte Apple Mail for å blokkere alle bilder i HTML-e-post som standard som ikke er innebygd i e-posten. Du gir enten tillatelse til å laste dem en e-post om gangen, eller du må aktivere innstillingene for å deaktivere denne innstillingen. Sammen med e-postklientens sikkerhetsinnstillinger er det også bedriftsinnstillinger.
- IT-sikkerhet – IT-teamet ditt kan distribuere strenge regelsett for hvilke objekter som faktisk kan gjengis i en e-post. Hvis bildene dine, for eksempel, kommer fra et spesifikt domene som ikke er hvitelistet i en bedriftsbrannmur, vil bilder rett og slett ikke vises i e-posten din. Til tider har vi måttet utvikle e-poster og hoste alle bildene på selskapets server slik at deres egne ansatte kunne se bildene.
- E-posttjenesteleverandører – For å gjøre vondt verre, e-postbyggere som e-posttjenesteleverandører (ESPs) faktisk introdusere problemer i stedet for å begrense dem. Mens de promoterer redaktøren deres Det du ser er det du får (WYSIWYG), er det motsatte ofte sant med e-postdesign. Du vil forhåndsvise e-posten på plattformen deres, så ser e-postmottakeren alle slags designproblemer. Bedrifter velger ofte ukjent for en funksjonsrik redaktør i stedet for en låst redaktør som tenker at den ene har flere funksjoner enn den andre. Det motsatte er sant ... hvis du vil ha e-poster som gjengis konsekvent på tvers av alle e-postklienter, jo enklere jo bedre fordi mindre kan gå galt.
- Gjengivelse av e-postklient – Det er hundrevis av e-postklienter, som hver gjengir HTML forskjellig på tvers av skrivebords-, app-, mobil- og nettpostklienter. Mens det smarte tekstredigeringsprogrammet på e-postleverandøren din kan ha en innstilling for å sette en overskrift i e-posten din... kan utfyllingen, margene, linjehøyden og skriftstørrelsen variere på hver enkelt e-postklient. Som et resultat må du dumme ned HTML-en og kode hvert enkelt element annerledes (se eksempelet nedenfor) - og ofte skrive inn unntak som er e-postklientspesifikke - for å få en e-post til å gjengi konsekvent. Det er ingen enkle blokktyper, du må gjøre tabelldrevne layouter som tilsvarer å bygge for nettet for tretti år siden. Det er grunnen til at enhver ny layout krever både utvikling og testing av klienter og enheter på tvers av e-post. Det du ser i innboksen din kan være helt annerledes enn det jeg ser i innboksen min. Det er grunnen til å gjengi verktøy som E-post på syre or Lakmus er et must for å sikre at de nye designene dine fungerer på tvers av alle e-postklienter. Her er en kort liste over populære e-postklienter og deres gjengivelsesmotorer:
- Bruk av Apple Mail, Outlook for Mac, Android Mail og iOS Mail WebKit.
- Bruk av Outlook 2000, 2002 og 2003 Internet Explorer.
- Bruk av Outlook 2007, 2010 og 2013 Microsoft Word (ja, Word!).
- Webmail-klienter bruker nettleserens respektive motor (for eksempel Safari bruker WebKit og Chrome bruker Blink).
Et eksempel på HTML for web vs. E-post
Hvis du vil ha et eksempel som illustrerer kompleksiteten ved å designe i e-post kontra nettet, her er et perfekt eksempel fra Mailbakerys artikkel 19 Store forskjeller mellom e-post og web-HTML:
E-post
Vi må bygge en serie tabeller som inneholder all den innebygde stylingen som er nødvendig for å plassere knappen riktig og sikre at den ser bra ut på tvers av e-postklienter. Det kommer også til å være en medfølgende stil-tag øverst i denne e-posten for å inkludere klassene.
<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>web
Vi kan bruke et eksternt stilark med klasser for å definere kasus, justering, farge og størrelse på en anker-tag som vises som en knapp.
<div class="center">
<a href="#" class="button">Find Out More</a>
</div>Hvordan unngå problemer med e-postdesign
Problemer med e-postdesign kan unngås ved å følge en anstendig prosess:
- Maldesign – Bygg ut en mal med forskjellige oppsett og innholdsblokker som omfatter alle stiler du noen gang ønsker å produsere i e-postdesignene dine. Når vi implementerer en klient, presser vi dem alltid til designe en e-post for fremtiden – ikke bare den neste e-postkampanjen som sendes ut. På den måten kan vi fullt ut designe, utvikle, teste og implementere de nødvendige løsningene før du de sender noen gang ut den første e-posten.
- Mal testing – Å forstå e-postklientene som abonnentene dine bruker og sikre at HTML-e-posten din er fullstendig testet på mobil og skrivebord er avgjørende før du distribuerer en mal. Vi kan designe en e-post bokstavelig talt fra et photoshop-oppsett... men å dele den opp i en tabelldrevet, kryss-e-postklient er avgjørende for å implementere e-postdesign som er optimalt og konsistent.
- Intern testing – Når malen din er designet og testet, bør den sendes til en intern frøliste i organisasjonen for å gjennomgå og godkjenne. Det kan til og med være lurt å starte med et svært begrenset undersett av individer for først å sikre at det ikke er brannmur- eller sikkerhetsproblemer knyttet til gjengivelse av e-posten internt. Hvis dette bygger ut en forekomst på en ny e-postleverandør, kan du til og med finne noen filtrerings- eller blokkeringsproblemer forbundet med å få e-posten din til innboksen.
- Malversjon – Ikke endre layoutene eller designene dine uten å jobbe med en ny versjon av malen som kan utformes, testes på riktig måte og distribueres. Mange bedrifter elsker engangsdesign for hver kampanje ... men det krever at hver e-post er designet, utviklet og distribuert for hver kampanje. Dette legger massevis av tid til den interne e-postmarkedsføringsprosessen. Og du risikerer ikke å forstå hvilke elementer i e-posten din som gir gode resultater i forhold til hvilke elementer som ikke gjør det. Konsistens er ikke bare en måte å gjøre prosessen enklere på, det er også viktig for oppførselen til abonnentene dine.
- Unntak fra e-posttjenesteleverandører – Praktisk talt hver e-postleverandør har en måte å omgå problemene som deres e-postbygger introduserer. Vi kan ofte legge til rå CSS til en konto – eller til og med ha en innholdsblokk som må inkluderes i hver e-post – for at selskapet skal kunne bruke den innebygde e-posteditoren og ikke få den til å bryte utformingen av e-posten din. Det kan selvfølgelig kreve litt opplæring og prosesskontroll for å implementere disse trinnene for å sikre at de blir overholdt. Eller – du vil kanskje bokstavelig talt bare utvikle e-postdesignet ditt i en løsning som har vist seg å fungere på tvers av klienter og enheter, og deretter lime den inn igjen i e-postleverandøren din.
E-postdesignplattformer
Fordi e-posttjenesteplattformer har gjort en dårlig jobb med å bygge ut og vedlikeholde konsekvent gjengitte byggherrer på tvers av klienter og enheter på tvers av enheter, har en rekke flotte plattformer kommet på markedet. En som vi har brukt mye er Stripo.
Stripo er ikke bare en e-postbygger, de har også et bibliotek med over 900 maler som enkelt kan importeres. Når du har utformet e-posten, kan du sende e-post til 60+ ESP-er og e-postklienter, inkludert MailChimp, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlook og Gmail. Det beste av alt Stripo-maler kommer med e-postgjengivelsestestene inkludert, slik at du kan sikre at de er testet og fungerer konsekvent på tvers av over 40 e-postklienter.
Logg inn på Stripo Editor-demoen
Avsløring: Jeg linker til min markedsføringskonsulentfirma som designer og distribuerer e-poster på tvers av klienter for ledende merker i praktisk talt alle e-postleverandører. Jeg er også en affiliate av Stripo og jeg bruker linken min i denne artikkelen.
