Share
E-post är ett fantastiskt medium. Den går direkt in i inkorgen och dess avkastning rapporteras allmänt som taket på 4000%. Det är också ständigt missförstått och alltför ofta är det gjort illa. Med den senaste tidens explosion av smartphones läser vi oftare vårt mail på vår iPhone eller Galaxy, men tyvärr har mycket email marknadsföring misslyckats med att fortsätta. Jag ser detta som ett enormt missat tillfälle eftersom ett väl utfört e-postmeddelande kan vara roligt att öppna och mycket framgångsrikt.
Om du redan har provat din hand på HTML-e-postdesign och -utveckling har du förmodligen redan fastställt att det kan vara ganska svårt. Och du föreställer dig inte det - det är ganska svårt. Här är varför:
[Vi kommer] fortsätta att använda Word för att skapa e-postmeddelanden eftersom vi anser att det är den bästa e-postförfattarupplevelsen runt.
Outlook-teamet
När du kodar för webben kan du minst räkna med att alla större webbläsare (Chrome, Firefox, Internet Explorer, Safari och Opera) försöker följa webbstandarder för att göra HTML och CSS.
När det gäller e-postklienter testar du på ett stort antal gamla och nya program. De sträcker sig från nya telefoner som körs på Android och iOS till IBMs Lotus Notes eller Microsoft Office 2007 (vilket otroligt gör din kärleksfullt skapade HTML med Word HTML-återgivningsmotorn. De tidigare versionerna av Outlook använde en webbläsare för att göra deras HTML - vilket är faktiskt logiskt. Varför växla till en ordbehandlare för att göra HTML du frågar? Tja, för "säkerhetsskäl" säger de). Och inget av dessa program måste följa några standarder. De gör i grund och botten bara det. Du kan se vilken standardstöd som ser ut för några av de mest populära e-postklienterna på Email Standards Project.
Om det inte är tillräckligt illa, koppla det med nästa faktum: Det finns ungefär en miljon olika kombinationer av sätt som e-post kan göra på skrivbord och mobil.
Återgivningsmöjligheterna är (nästan) oändliga. Här är en lista över några av de vanligaste e-postklienterna:
Mobila klienter:
Skrivbordsklienter:
Webmail klienter:
Det är många enheter!
Om du redan är bekant med webbutveckling, glöm allt du vet om det.
För att förena allt detta är villkorlig styling inte heller mycket av ett alternativ. Det finns några saker du kan göra med villkorliga kommentarer, men det är begränsat till att rikta vissa versioner av Outlook eller allt bortsett från vissa versioner av Outlook.
Om du redan är bekant med webbutveckling, glöm allt du vet om det. Det enskilt största hinderet för dig förväntar dig att saker fungerar som "normal" webbutveckling. Detta kommer att frustrera dig och hålla dig tillbaka. Det värsta du kan göra är att bli arg att du inte kan använda DIV eller det marginal stöds inte fullt ut. Så glöm allt du vet om semantisk HTML och den senaste CSS-specifikationen. Lita på mig, det hjälper.
Låt oss ta en titt på några förslag på e-postbyggande arbetsflöden.
Att bygga strukturen på ditt mail först kan hjälpa dig att undvika många buggar och problem senare efter spåret. Bygg aldrig upp det hela och test sedan - du kan ofta sluta med alltför många buggar att hantera, och de kan alla påverka varandra.
Arbeta tills du når en mindre utvecklingsmilestone (till exempel när du avslutar grundstrukturen) och kör sedan ett test. Det bästa sättet att testa använder Litmus eller Email on Acid. Jag rekommenderar att du tar en obegränsad plan med någon av dessa företag eftersom det är väldigt viktigt att kunna testa ofta.
Jag gillar också att lämna i alla mina bordgränser så att jag kan se vad jag skapar, så slår jag dem alla i slutet. Du kan också färga bakgrunden för vissa celler för att se vilka avsnitt som är där. Mitt idealiska arbetsflöde är att skapa ett skelett, prova, sedan lägga till mitt innehåll, testa, stila färgerna och teckensnitt, testa igen och slutligen ta bort mina gränser och testa igen innan du skickar.
Bekräfta det med W3C Validator så ofta som möjligt. Detta hjälper dig att stryka ut små detaljer och det kommer att hämta på misstag som saknas eller öppna taggar.
Det finns ett stort antal alternativ när det gäller att skicka din e-post. De två tjänster som jag använder mest är MailChimp och Campaign Monitor. De erbjuder konkurrenskraftiga priser och de är mycket lätta att använda. Det finns också massor av kommersiella plattformar - allt beror på dina behov. Registrera dig för ett gratis konto med någon av dessa och ha en tinker i sina system för att se vilken du vill. Se till att du använder de användbara uppgifterna som båda tjänsterna samlar om dina e-postmeddelanden, till exempel öppna tider och användarvänlighet för e-postklienter. Det kan verkligen hjälpa dig att fokusera dina ansträngningar i rätt område nästa gång du skickar.
När det gäller SPAM; innehåll, design och utveckling går hand i hand. Det är viktigt att undvika typiska spammy taktik som att använda all-caps och massor av utropstecken i din ämnesrad. Det finns vissa ord som sannolikt kommer att utlösa SPAM-filter också (som "gratis" och "investera"). Städaren din kod, desto mindre sannolikt kommer din e-post att markeras som SPAM, och förhållandet mellan bilder och text har också en effekt. Bildrelaterade e-postmeddelanden utan text är mer benägna att markeras som SPAM och så är e-postmeddelanden med riktigt långa bildfilnamn.
Världen av SPAM-poäng är en knepig och det är viktigt att du kör ett SPAM-test genom ditt testkonto med Litmus eller Email on Acid innan du skickar din e-post, för att se till att allt ditt hårda arbete inte är rakt fram till skräpmappen.
Nu, för nitty-gritty av e-postutveckling ...
Du behöver en textredigerare som du gillar (jag använder Sublime Text) och ett testkonto med Litmus eller Email on Acid. Jag rekommenderar starkt att ha ett obegränsat testkonto hos någon av dessa företag, eftersom det kommer att göra ditt liv så mycket enklare. Om du inte betalar en månadsavgift kommer du sluta betala mellan $ 3 och $ 5 per test vilket kan lägga upp ganska snabbt.
Jag tycker att det är bra att börja med en tom skiffer. Ramar som HTML Email Boilerplate är fulla av underbara knep och utdrag som du kan implementera bit för bit. Men om du bara börjar, rekommenderar jag inte att du använder det som utgångspunkt eftersom det innehåller många element som du inte behöver. Källplattor kan ofta göra det svårare att felsöka några problem om det finns mycket oanvänd kod i din fil.
Notera: Eftersom det kan vara mycket osäkert att använda någon form av redigerare (speciellt när det är dags att felsöka), bör du aldrig använda en WYSIWYG-redigerare eller någon form av redaktör som lovar att ta din formaterade design och omvandla den till giltig HTML för att maila . Det här fungerar bara aldrig.
Det här kan verka som en teknisk detalj till att börja med, men du behöver en tom mall för att börja arbeta med, och den mallen behöver en Doctype. En doktyp är i huvudsak en kodlinje som informerar programmet om att läsa det som HTML-taggar ska förvänta sig och vilken uppsättning regler HTML och CSS följer. Helt få kunder klämmer bort din Doctype, och vissa gör även en egen. Många kunder hedrar din doktyp och det kan göra saker mycket enklare om du kan validera ständigt mot en Doctype.
Att använda en XHTML-doktyp har generellt de minsta ryck och inkonsekvenser mellan dokument. Jag använder XHTML 1.0 Transitional eftersom det har visat mig vara den mest pålitliga doktypen i min erfarenhet. I följande handledning, under vilken vi bygger en komplett HTML-e-postmall, använder vi följande kod för att starta vårt dokument:
Demystifying Email Design
De Innehållstyp metataggen är för att berätta för destinationens reningsmotor hur man behandlar text och specialtecken. I själva verket måste du koda alla dina specialtecken ändå (till exempel & blir & för ampersand) för att vara säker, men det är värt att hålla den här linjen där ändå.
Visningsmetataggen säger att enheten ska ställa in det visbara området till bredden på enhetens skärm. Den ställer också in initialskalan till "normal" som varken zoomas in eller ut. Om du inte anger det här kan många smartphones skala ditt innehåll ner så att innehållet passar inom det visade området, men inte någon av dess vadderingar eller marginaler. Detta kan leda till att text och bilder raderas upp mot skärmens kant.
Slutligen, skriv alltid in en meningsfull titel eftersom det här är vad folk ser när de visar e-postmeddelandet i en webbläsare eller delar det med sina vänner.
På grund av bristen på standardstöd i e-post är det inte möjligt att använda div, sektioner eller artiklar - istället måste du använda tabeller. Dessutom måste du använda massor och massor av kapslade tabeller eftersom varken colspan inte heller rowspan attribut stöds ordentligt.
Återigen, på grund av bristen på standardstöd, är det inte en bra idé att använda standardkoder som h1, h2, h3 eller p. Jag finner att dessa kan göra verkligen inkonsekvent över e-postklienter och kan skapa några ganska stora huvudvärk.
Din bästa satsning är att placera varje textblock i sin egen cell och tillämpa inline styling till den cellen, till exempel:
Text
Den här är mer av ett personligt val. Jag föredrar att hålla alla mina stilar inline (dvs: inom HTML-taggarna själva) eftersom jag gillar att veta exakt var allt är och vad som påverkar vad. Du kan koda med hjälp av stilar och sedan dra dem alla inline i slutet (Kampanjövervakning och MailChimp kan göra det automatiskt för dig, du kan också använda Premailer eller något liknande) men anledningen till att jag inte gillar det här är att du lär dig veta din kod, kör den via en inliner, och då kan din kod bli något oigenkännlig. Jag tycker att det här gör det svårare att felsöka. Att säga att, om det här är så som du vill arbeta, är det bra. Det finns ingen teknisk anledning till varför du inte borde göra det.
Glöm inte: Du kan inte tillämpa flera klasser på saker i HTML-e-post eftersom det inte stöds. Varje element kan ha högst en klass.
Glöm inte heller: Du kan inte använda stenografi för saker som typsnittstorlek (dvs) eftersom den inte stöds.
När du sparar bilder, kom ihåg att det är bra att ge dina bildnamn som är korta och meningsfulla eftersom det kommer att förbättra din spampoäng. Namnen som "campaign_054_design_0x0_v6_email-link.gif" kommer sannolikt att ha en mycket högre SPAM-poäng än "email.gif".
Det är också en jättebra idé att försöka hålla hela ditt e-mail så litet som mänskligt möjligt: under 100kb är det idealiskt men inte alltid möjligt, under 250kb är ganska standard. Använd en komprimeringsapp som JPEGmini eller tinyPNG för att skära alla dina bilder så mycket som möjligt innan du skickar. Långsamma belastningstider, särskilt på mobilen, kan göra eller bryta ditt email om den totala filstorleken är för stor.
Lämna inte något upp till e-postklienten. Ange alla dina bredder, för annars kan du sluta med oväntade resultat. För dina huvudbehållarelement måste du alltid ställa in storleken i pixlar. Du kan sedan använda procentandelar inom din innehållsdel om du vill.
Det är mycket att ta hänsyn till när man utformar och utvecklar HTML-e-post, varav de flesta innebär "un-learning" -standarder du har uppmanats att träna för webbdesign genom åren. Denna handledning borde dock ha gett dig en solid bas för att fungera, och du är nu redo att hoppa in i den faktiska byggprocessen. Framåt!
Jag hänvisade till några saker under denna handledning - så här är de igen, allt på ett ställe.
Accentsconagua