Förstå utmaningarna (och frustrationerna) med HTML-e-postdesign

Om du öppnar ett innehållshanteringssystem för att bygga webbsidor är det en ganska enkel process. Moderna webbläsare stöder HTML, CSS och JavaScript till en sträng uppsättning webbstandarder. Och de är egentligen bara en handfull webbläsare som designers behöver oroa sig för. Det finns undantag, naturligtvis... och några enkla lösningar eller funktioner som är specifika för dessa webbläsare.

På grund av de övergripande standarderna är det väldigt enkelt att utveckla sidbyggare i innehållshanteringssystem. Webbläsare följer HTML5, CSS och JavaScript... och utvecklare kan bygga otroligt robusta lösningar för att bygga webbsidor som är lyhörda för enheter och konsekventa i alla webbläsare. För två decennier sedan använde praktiskt taget varje webbdesigner datorprogramvara för att utveckla webbsidor. Nu är det ganska ovanligt att en webbdesigner utvecklar en webbsida – oftare än inte utvecklar de mallar och använder redaktörer i innehållssystem för att fylla i innehållet. Webbredaktörer är fantastiska.

Men e-postredaktörer ligger bedrövligt efter. Här är varför...

Att designa HTML-e-postmeddelanden är mycket mer komplicerat än för en webbplats

Om ditt företag vill ha ett vackert HTML-e-postmeddelande är processen exponentiellt mer komplex än att bygga ut en webbsida av ett antal anledningar:

• Inga standarder – Det finns INGEN strikt efterlevnad av någon webb standarder av e-postklienter som visar HTML-e-post. Faktiskt så gott som varje e-postklient och varje version av varje e-postklient agerar annorlunda. Vissa kommer att hedra CSS, externa typsnitt och modern HTML. Andra hedrar viss inline-stil, visar bara en samling teckensnitt och ignorerar allt annat än tabelldrivna strukturer. Det är faktiskt ganska löjligt vid det här laget att ingen arbetar med den här frågan. Som ett resultat har det blivit en stor affär att designa mallar som renderar över klienter och enheter konsekvent och kan bli ganska dyrt.
• E-postklientsäkerhet – Bara den här veckan uppdaterade Apple Mail för att blockera alla bilder i HTML-e-postmeddelanden som standard som inte är inbäddade i e-postmeddelandet. Antingen ger du tillåtelse att ladda dem ett e-postmeddelande åt gången eller måste aktivera inställningarna för att inaktivera den här inställningen. Tillsammans med e-postklientens säkerhetsinställningar finns det även företagsinställningar.
• IT-säkerhet – Ditt IT-team kan använda strikta regeluppsättningar för vilka objekt som faktiskt kan renderas i ett e-postmeddelande. Om dina bilder, till exempel, kommer från en specifik domän som inte är vitlistad i en företagsbrandvägg, kommer bilder helt enkelt inte att dyka upp i din e-post. Ibland har vi varit tvungna att utveckla e-postmeddelanden och lagra alla bilder på företagets server så att deras egna anställda kunde se bilderna.
• E-posttjänstleverantörer – För att göra saken värre, e-postbyggarna som e-posttjänstleverantörer (ESPs) faktiskt införa problem snarare än att begränsa dem. Medan de främjar deras redaktör är Vad du ser är vad du får (WYSIWYG), motsatsen är ofta sant med e-postdesign. Du kommer att förhandsgranska e-postmeddelandet på deras plattform, sedan ser e-postmottagaren alla typer av designproblem. Företag väljer ofta omedvetet en funktionsrik editor istället för en låst redaktör som tror att den ena har fler funktioner än den andra. Det motsatta är sant... om du vill ha e-postmeddelanden som återges konsekvent i alla e-postklienter, ju enklare desto bättre eftersom mindre kan gå fel.
• E-postklientrendering – Det finns hundratals e-postklienter som var och en renderar HTML på olika sätt för datorer, appar, mobiler och webbmailklienter. Medan din snygga textredigerare på din e-postleverantör kan ha en inställning för att sätta en rubrik i din e-post... kan utfyllnad, marginaler, radhöjd och teckenstorlek skilja sig åt på varje enskild e-postklient. Som ett resultat måste du fördumma HTML och koda varje enskilt element på olika sätt (se exemplet nedan) – och ofta skriva in undantag som är e-postklientspecifika – för att få ett e-postmeddelande att rendera konsekvent. Det finns inga enkla blocktyper, du måste göra tabelldrivna layouter som motsvarar att bygga för webben för trettio år sedan. Det är därför som alla nya layouter kräver både utveckling och testning av klient- och enhetsöverskridande e-post. Vad du ser i din inkorg kan vara helt annorlunda vad jag ser i min inkorg. Det är därför man renderar verktyg som E-post på Acid or Litmus är ett måste för att säkerställa att din nya design fungerar i alla e-postklienter. Här är en kort lista över populära e-postklienter och deras renderingsmotorer:
  • Använd Apple Mail, Outlook för Mac, Android Mail och iOS Mail WebKit.
  • Outlook 2000, 2002 och 2003 används Internet Explorer.
  • Outlook 2007, 2010 och 2013 används Microsoft Word (ja, Word!).
  • Webbmailklienter använder sin webbläsares respektive motor (till exempel Safari använder WebKit och Chrome använder Blink).

Ett exempel på HTML för webb vs. E-post

Om du vill ha ett exempel som illustrerar komplexiteten i att designa i e-post kontra webben, här är ett perfekt exempel från Mailbakerys artikel 19 Stora skillnader mellan e-post och webb-HTML:

<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>

<div class="center">
   <a href="#" class="button">Find Out More</a>
</div>

Hur man undviker e-postdesignproblem

E-postdesignproblem kan undvikas genom att följa en anständig process:

1. Malldesign – Bygg ut en mall med olika layouter och innehållsblock som omfattar alla stilar som du någonsin skulle vilja skapa i dina e-postdesigner. När vi implementerar en kund pressar vi dem alltid till designa ett e-postmeddelande för framtiden – inte bara nästa e-postkampanj som skickas ut. På så sätt kan vi fullt ut designa, utveckla, testa och implementera nödvändiga lösningar innan de skickar ut det första e-postmeddelandet.
2. Malltestning – Att förstå e-postklienterna som dina prenumeranter använder och att se till att din HTML-e-post är fullständigt testad på mobil och dator är avgörande innan någon mall implementeras. Vi kan designa ett e-postmeddelande bokstavligen från en photoshop-layout... men att skära upp och dela upp det till en tabelldriven, kors-e-postklient är avgörande för att distribuera e-postdesigner som är optimala och konsekventa.
3. Intern testning – När din mall är designad och testad ska den skickas till en intern frölista inom organisationen för att granska och godkänna. Du kanske till och med vill börja med en mycket begränsad delmängd av individer för att först säkerställa att det inte finns några brandväggs- eller säkerhetsproblem förknippade med att rendera e-postmeddelandet internt. Om detta bygger ut en instans på en ny e-postleverantör kan du till och med hitta vissa filtrerings- eller blockeringsproblem som är förknippade med att till och med få din e-post till inkorgen.
4. Mallversionering – Ändra inte dina layouter eller design utan att arbeta med en ny version av din mall som kan designas, testas korrekt och distribueras. Många företag älskar engångsdesigner för varje kampanj... men det kräver att varje e-postmeddelande designas, utvecklas och distribueras för varje kampanj. Detta lägger massor av tid till den interna e-postmarknadsföringsprocessen. Och du riskerar att inte förstå vilka element i din e-post som presterar bra över vilka element som inte gör det. Konsekvens är inte bara ett sätt att göra processen enklare, det är också viktigt för dina prenumeranters beteende.
5. Undantag för e-postleverantörer – Praktiskt taget alla e-postleverantörer har ett sätt att komma runt de problem som deras e-postbyggare introducerar. Vi kan ofta lägga till rå CSS till ett konto – eller till och med ha ett innehållsblock som måste inkluderas i varje e-postmeddelande – för att företaget ska kunna använda den inbyggda e-postredigeraren och inte få den att bryta utformningen av din e-post. Naturligtvis kan det kräva viss utbildning och processkontroll för att implementera dessa steg för att säkerställa att de efterlevs. Eller – du kanske bokstavligen bara vill utveckla din e-postdesign i en lösning som har visat sig fungera över klienter och enheter, och sedan klistra in den i din e-postleverantör.

E-postdesignplattformar

Eftersom e-posttjänstplattformar har gjort ett dåligt jobb med att bygga ut och underhålla konsekvent renderade byggare över klienter och enheter över flera enheter, har ett antal fantastiska plattformar kommit ut på marknaden. En som vi har använt flitigt är Stripo.

Stripo är inte bara en e-postbyggare, de har också ett bibliotek med över 900 mallar som enkelt kan importeras. När du har designat e-postmeddelandet kan du skicka e-post till 60+ ESP:er och e-postklienter, inklusive Mailchimp, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlook och Gmail. Bäst av allt Stripo-mallar kommer med e-postrenderingstesterna som ingår så att du kan säkerställa att de har testats och fungerar konsekvent i över 40 e-postklienter.

Logga in på Stripo Editor Demo

Avslöjande: Jag länkar till min marknadsföringskonsultföretag som designar och distribuerar e-postmeddelanden över flera klienter för ledande varumärken i praktiskt taget alla e-postleverantörer. Jag är också en affiliate till Stripo och jag använder min länk i den här artikeln.