Share
E-post er et fantastisk medium. Den går rett inn i innboksen, og avkastningen på avkastningen er allment rapportert som takket være 4000%. Det er også perpetually misforstått og for ofte er det gjort dårlig. Med den nyeste eksplosjonen av smarttelefoner, leser vi oftere e-posten vår på vår iPhone eller Galaxy, men dessverre har e-postmarkedsføring dessverre ikke lykkes. Jeg ser dette som en stor savnet mulighet fordi en godt utført e-post kan være hyggelig å åpne og enormt vellykket.
Hvis du allerede har prøvd din hånd på HTML-e-postdesign og -utvikling, har du sikkert allerede oppdaget at det kan være ganske vanskelig. Og du tenker ikke på det - det er ganske vanskelig. Her er hvorfor:
[Vi vil] fortsette å bruke Word for å lage e-postmeldinger fordi vi tror det er den beste e-postforfatteropplevelsen rundt.
Outlook-teamet
Når du kodes for nettet, kan du i det minste regne med at alle de store nettleserne (Chrome, Firefox, Internet Explorer, Safari og Opera) prøver å overholde webstandarder for gjengivelse av HTML og CSS.
Når det gjelder e-postklienter, tester du på en stor mengde gamle og nye programmer. De spenner fra nye telefoner som kjører på Android og iOS til IBMs Lotus Notes eller Microsoft Office 2007 (som gjenspeiler din kjærlig HTML med HTML-gjengivelsesmotoren. De tidligere versjonene av Outlook brukte en nettleser til å gjengi HTML-en, som faktisk er logisk. Hvorfor bytte til en tekstbehandler for å gjengi HTML du spør? Vel, for "sikkerhetsmessige grunner" sier de). Og ingen av disse programmene må følge noen standarder. De gjør i utgangspunktet bare det. Du kan se hvilken standardstøtte som ser ut til noen av de mest populære e-postklienter ved e-poststandardprosjektet.
Hvis det ikke er så ille, par det med det neste faktumet: Det er omtrent en million forskjellige kombinasjoner av måter som e-post kan gjengi på skrivebord og mobil.
Gjenvinningsmulighetene er (nesten) uendelige. Her er en liste over noen av de vanligste e-postklienter:
Mobil klienter:
Skrivebordsklienter:
Webmail klienter:
Det er mange enheter!
Hvis du allerede er kjent med webutvikling, glem alt du vet om det.
For å sammensatte alt dette er betinget styling heller ikke mye av et alternativ. Det er noen ting du kan gjøre med betingede kommentarer, men det er begrenset til å målrette mot bestemte versjoner av Outlook, eller alt unntatt visse versjoner av Outlook.
Hvis du allerede er kjent med webutvikling, glem alt du vet om det. Det eneste største hindret for deg forventer at ting skal fungere som "normal" webutvikling. Dette vil frustrere deg og holde deg tilbake. Det verste du kan gjøre er å bli sint at du ikke kan bruke DIV eller det margin er ikke fullt støttet. Så glem alt du vet om semantisk HTML og den nyeste CSS-spesifikasjonen. Stol på meg, det vil hjelpe.
La oss ta en titt på noen forslag til e-postbygging av arbeidsflyt.
Å bygge strukturen til e-posten din først kan hjelpe deg med å unngå mange feil og problemer senere nedover banen. Bygg aldri hele greia og test deretter - du kan ofte ende opp med for mange feil å håndtere, og de kan alle påvirke hverandre.
Arbeid til du når en mindre utviklingsmilestone (for eksempel når du er ferdig med grunnstrukturen) og kjør en test. Den beste måten å teste på, bruker Litmus eller Email on Acid. Jeg anbefaler å ta ut en ubegrenset plan med noen av disse selskapene fordi det er veldig viktig å være i stand til å teste ofte.
Jeg liker også å forlate i alle mine bordgrenser slik at jeg kan se hva jeg lager, og så slår jeg dem alle på slutten. Du kan også farge bakgrunnen til enkelte celler for å se hvilke seksjoner som er der. Min ideelle arbeidsflyt er å lage et skjelett, test, deretter legge til innholdet mitt, test, stil farger og skrifttyper, test igjen og til slutt fjern mine grenser og prøv igjen før du sender.
Bekreft det ved å bruke W3C Validator så ofte som mulig. Dette vil hjelpe deg med å stryke ut små detaljer, og det vil hente på feil som mangler eller åpne koder.
Det er et stort antall alternativer når det gjelder å sende e-posten din. De to tjenestene jeg bruker mest, er MailChimp og Campaign Monitor. De tilbyr konkurransedyktige priser, og de er veldig enkle å bruke. Det er også mange kommersielle plattformer - alt avhenger av dine behov. Registrer deg for en gratis konto med en av disse og ha en tinker i deres systemer for å se hvilken du liker. Pass på at du bruker de nyttige dataene som begge tjenestene samler inn om e-postene dine, for eksempel åpne tider og bruk av e-postklienter. Dette kan virkelig hjelpe deg med å fokusere innsatsen i riktig område neste gang du sender.
Når det gjelder SPAM; innhold, design og utvikling går hånd i hånd. Det er viktig å unngå vanlig spammy taktikk som å bruke all-caps og mange utropstegn i emnelinjen. Det er visse ord som sannsynligvis vil utløse SPAM-filtre også (som "gratis" og "investere"). Rengjør koden din, desto mindre sannsynlig er e-posten din merket som SPAM, og forholdet mellom bilder til tekst har også en effekt. Bilderelaterte e-postmeldinger uten tekst er mer sannsynlig å bli merket som SPAM, og det er også e-post med veldig lange bildefilnavn.
Verden av SPAM-poeng er en vanskelig og det er viktig å kjøre en SPAM-test gjennom testkontoen din med Litmus eller Email on Acid før du sender e-posten din, for å sørge for at alt hardt arbeid ikke blir ledet rett til søppelmappen.
Nå, for nitty-gritty av e-utvikling ...
Du trenger en tekstredigerer som du liker (jeg bruker Sublime Text) og en testkonto med Litmus eller Email on Acid. Jeg anbefaler på det sterkeste å ha en ubegrenset testkonto hos noen av disse selskapene, da det vil gjøre livet ditt så mye lettere. Hvis du ikke betaler en månedlig avgift, vil du ende opp med å betale mellom $ 3 og $ 5 per test som kan legge opp ganske raskt.
Jeg synes det er bra å starte med en tom skifer. Rammer som HTML Email Boilerplate er fulle av fantastiske triks og utdrag som du kan implementere stykke for hverandre. Men hvis du bare starter, anbefaler jeg ikke å bruke det som utgangspunkt, da det inneholder mange elementer som du ikke trenger. Boilerplates kan ofte gjøre det vanskeligere å feilsøke eventuelle problemer hvis det er mye ubrukt kode i filen din.
Merk: Fordi det kan være svært usikre å bruke noen form for redigeringsprogram (spesielt når det er på tide å feilsøke), bør du aldri bruke en WYSIWYG-editor eller en hvilken som helst form for redaktør som lover å ta formatert design og forvandle det til gyldig HTML for å sende e-post . Denne tingen virker bare aldri.
Dette kan virke som en teknisk detalj for å begynne med, men du trenger en tom mal for å begynne å jobbe med, og at malen trenger en Doctype. En doktype er i hovedsak en linje med kode som informerer programmet om å lese det som HTML-koder forventer og hvilket sett av regler HTML og CSS overholder. En hel del klienter striper Doctype ut, og noen bruker selv sine egne. Mange klienter respekterer din doktype, og det kan gjøre ting mye enklere hvis du kan validere hele tiden mot en Doctype.
Bruke en XHTML-doktype har generelt de færre quirks og inkonsekvenser mellom dokumenter. Jeg bruker XHTML 1.0 Transitional fordi det har vist seg å være den mest pålitelige doktypen i min erfaring. I den følgende veiledningen, der vi skal bygge en komplett HTML-e-postmal, bruker vi følgende kode for å starte dokumentet vårt:
Demystifying Email Design
De Innholdstype metakode er for å fortelle målgjenvinningsmotoren hvordan man behandler tekst og spesialtegn. I virkeligheten må du kodes for alle dine spesialtegn uansett (for eksempel & blir & for ampersand) for å være trygg, men det er verdt å holde denne linjen der inne uansett.
Visnings metataggen forteller enheten for å angi det synlige området til bredden på enhetens skjerm. Den setter også opprinnelige skalaen til "normal", som hverken zoomes inn eller ut. Hvis du ikke angir dette, kan mange smarttelefoner skal innholdet ditt ned, slik at innholdet passer i det synlige området, men ikke noen av dens polstring eller marginer. Dette kan føre til at tekst og bilder stikker rett opp mot kanten av skjermen.
Til slutt må du alltid skrive inn en meningsfull tittel fordi dette er hva folk vil se når de ser e-posten i en nettleser, eller deler den med vennene sine.
På grunn av mangelen på standardstøtte i e-post, er det ikke mulig å bruke div, seksjoner eller artikler - i stedet må du bruke tabeller. Videre må du bruke mange og nestede tabeller fordi verken colspan eller rowspan Attributtene støttes riktig.
Igjen, på grunn av mangel på standardstøtte, er det ikke en god ide å bruke standardkoder som h1, h2, h3 eller p. Jeg finner at disse kan gjøre virkelig inkonsekvent over e-postklienter og kan skape noen ganske store hodepine.
Din beste innsats er å plassere hver blokk med tekst i sin egen celle og bruke inline styling til den cellen, for eksempel:
Tekst
Denne er mer av et personlig valg. Jeg foretrekker å holde alle mine stiler inline (dvs. innen HTML-kodene selv) fordi jeg liker å vite nøyaktig hvor alt er og hva som påvirker hva. Du kan kode ved hjelp av stiler og deretter trekke dem all inline på slutten (Kampanje Monitor og MailChimp kan gjøre dette automatisk for deg, du kan også bruke Premailer eller noe lignende), men grunnen til at jeg ikke liker dette er fordi du blir kjent med det. Koden din, kjør den gjennom en inliner, og så kan koden bli noe uigenkjenelig. Jeg finner at dette gjør det vanskeligere å feilsøke. Å si at hvis dette er slik du vil jobbe, er det greit. Det er ingen teknisk grunn til at du ikke bør gjøre det.
Ikke glem: Du kan ikke bruke flere klasser til ting i HTML-e-post fordi den ikke støttes. Hvert element kan ha maksimalt en klasse.
Ikke glem også: Du kan ikke bruke stenografi for ting som skriftstørrelse (dvs.) fordi den ikke støttes.
Når du lagrer bilder, husk at det er bra å gi bildene dine navnene som er korte og meningsfulle fordi det vil forbedre spampoengene dine. Navn som "campaign_054_design_0x0_v6_email-link.gif" er sannsynligvis å ha en mye høyere SPAM-poengsum enn "email.gif".
Det er også en veldig god idé å prøve å holde hele e-posten så liten som mulig for mennesker: under 100kb er ideell, men ikke alltid mulig, under 250kb er ganske standard. Bruk en komprimeringsapp som JPEGmini eller tinyPNG for å kutte alle bildene dine i størrelse så mye som mulig før du sender. Langsommere belastningstider, spesielt på mobil, kan gjøre eller ødelegge e-posten hvis den totale filstørrelsen er for stor.
Ikke legg noe opp til e-postklienten. Angi alle breddene dine, for ellers kan du ende opp med uventede resultater. For de viktigste beholderelementene dine stiller du alltid størrelsen i piksler. Du kan da bruke prosentandeler i ditt inneholdende element hvis du ønsker det.
Det er mye å ta hensyn til når du designer og utvikler HTML-e-post, hvorav de fleste innebærer "un-learning" -standarder du har blitt oppfordret til å trene for webdesign gjennom årene. Denne opplæringen bør imidlertid ha gitt deg en solid base for å jobbe fra, og du er nå klar til å hoppe inn i selve byggeprosessen. utover!
Jeg refererte noen ting under denne opplæringen - så her er de igjen, alt på ett sted.
Accentsconagua