Hvordan gjorde vi det Bygg de nye tastene + e-postmaler

Tuts + e-postene (nyhetsbrev, fordøyelser etc.) har nylig gjennomgått en fullstendig overhaling, inkludert nye design og en ny plattform. Denne casestudien vil forklare hvordan jeg bygget dem i HTML og CSS, basert på designene fra første del i denne serien.

Starte

Da tiden kom for å begynne å bygge de skinnende nye Tuts + e-postmalerne, var jeg heldig nok til å være ganske kjent med designene. Under designfasen hadde Ian slått meg på store beslutninger og spurte meg mange spørsmål for å sikre at vi unngikk noen klassiske e-postkasjer. Denne prosessen var et utmerket grunnlag for meg, og jeg var klar til å dykke rett inn da designene var ferdige.

Ian sendte meg designene, en oversikt over layoutene, en guide til gridoppsettet og en stilguide med alle nødvendige skriftstørrelser og farger. Jeg var klar til å komme i gang.

Opprette en plan for angrep

Mitt første skritt er alltid skisse. Målet med dette er å identifisere alle de forskjellige modulene, uten å ignorere mindre kosmetiske forskjeller. Denne prosessen gir meg et siste sett med nøkkelmoduler for å bygge at jeg kan jobbe gjennom en etter en for å bygge opp den primære strukturen.

Etter å ha identifisert disse, ville jeg i mange tilfeller bygge dem alle inn i en enkelt side før de separeres senere, men layoutene er ganske vanskelig å se gjennom i denne tilstanden. I stedet utviklet jeg hvert layout i henhold til designene slik at de kunne bli vurdert og godkjent lettere. 

Med henvisning til min skisserte oppsummering av modulene, var jeg i stand til å huske på når en modul måtte gjenbrukes over flere maler, og bygge den tilsvarende. Senere ville jeg sette opp klasser på hver variants kropp, som VAR-admin og VAR-fordøye, Tillater meg å lage stiler som er spesifikke for hver enkelt layout.

Begynner å kode

Jeg begynte med å sette opp noen mindre variabler for elementer jeg visste at jeg ville bruke om og om igjen, som farger og målinger.

En guide til de fleste typografiske stiler

Noen av mine variabler (i MINDRE syntaks) er vist nedenfor.

// Variabler @ bg-body: # f2f2f2; @ paletttekst: # 58595a; @ palett-marine: # 212a34; @ palettdesign: # c94e4b; @ palettkode: # 4cc1be; @ palett-web: # 49b293; @ palettfotografering: # 8360a8; @ palettspill: # 72BF40; @ palett-datamaskin: # 5d7dba; @ Palette-virksomhet: # f38844; @ palette-3d: # f95858; @ palettmusikk: # 56a4ca; @ palett-footer: # 5a6e7a; @ palettadresse: # 999999; @ divider-color: #EAEAEA; @ link-farge: # 136fd2; @ alt-farge: @ palett-tekst; @ bredde: 640px; @ ytre gutter: 53px; @ innholdsbredde: @width - (@ ytre-gutter * 2); @ grid-enhet: 16px; .rounded (@radius: 1px) border-radius: @radius; -webkit-grense-radius: @radius; 

Jeg forbereder alltid fargene mine med palett å holde dem sammen. Dette gjør det lettere for meg å velge en farge fra forslaget, som vises i Sublime Text:

Konfigurere webfonter

Det neste viktige trinnet var å sette opp webfonter som ble brukt i designene. Skriften er Roboto tilgjengelig fra Google Fonts, så jeg la denne taggen til av malen:

Dette genereres av Google Fonts og koblinger til deres CSS for de fire forskjellige vektene til Roboto som vi bruker.

Jeg brukte fonten til kroppsmerket og min hovedinnpakningstabell for de klientene som ignorerer kroppsmerket eller striper formateringen.

body, .wrapper font-family: 'Roboto', sans-serif; 

Så, for å hindre Outlook 2007-2016 på Windows fra å vise Times New Roman-som det pleier å gjøre når det møter et ukjent skrifttype-ansikt-satt jeg opp noen betinget Outlook-only-kode i av malen:

Dette sikrer at alle forekomster av webfont er overstyrt i Outlook med en sans-serif. Jeg bruker den til tabeller og divs, de eneste to elementene som brukes til å inneholde innhold i malen. Det er ikke nødvendig å gå til et lavere nivå enn dette, da alle andre tagger vil arve dette i Outlook.

Å få layoutene ser fine ut

Deretter var det på strukturell koding. Jeg begynte med den første modulen som jeg hadde skissert: mastopen. En utfordring her var logoen, fordi for noen av malene ser den litt annerledes ut på mobilen:

For å oppnå dette, skjulte jeg på hovedlogoen og teksten øverst på mobilen. Jeg gjemte logoen også, og la det lille bladet som et bakgrunnsbilde til mastopen.

.logo img display: none! important;  .logo bakgrunnsbilde: url (images/[email protected]); høyde: 17px; bakgrunnsposisjon: senter senter; bakgrunnsstørrelse: 15px 17px; bakgrunn-gjentak: ikke-gjenta; 

Shifting Elements 

Neste avsnitt jeg taklet var "helt" artikkelen i Digest-e-postene; den første vanskelige delen her er etikettene. I designene dukket opp ved siden av overskriften tekst på skrivebordet, men ovenfor teksten på mobilen. For å oppnå dette i kode kan vi bruke noen visningsegenskaper for å få dem til å skifte seg.

Først opprettet jeg overskriften tag med innholdet inni splittet i to spenner, en for teksten og en for etiketten.

Bruke kurver i Adobe Photoshop FUNKSJONSKURS

Styling-wise, the .tekst span arver h2 styling, og deretter .merkelapp span er utformet separat for å gjøre det mindre og gi det en farget bakgrunn:

.etikett display: inline-block; margin-venstre: 5px; polstring: 3px 8px; vertikaljustering: 4px; border-radius: 3px; -webkit-grense-radius: 3px; farge: #ffffff; skriftstørrelse: 8px; linjehøyde: 10px; font-style: normal; Letter-avstand: 0.1em; 

Ved hjelp av medieforespørsler bytter vi da elementene rundt på mindre visningsporte:

@media skjerm og (maksimal bredde: 700px) h2 display: tabell! viktig;  h2 .text display: table-footer-group! viktig;  h2 .label margin-bottom: 12px! viktig; 

H2 er vår container, og vi setter den til å vise som bord slik at vi kan fortelle .tekst span for å fungere som bunntekstgruppen på den tabellen og gå til selve bunnen av layoutet. De .merkelapp Spenningen vises da øverst, og vi legger til en margin under den for å gi det litt puste.

Det var overraskende at Outlook på Windows (2007-2016) ikke vil vise etikettene på riktig måte, siden det ikke respekterer grense-radius, og heller ikke liker å legge til polstring til inline-elementer. Resultatene var egentlig ikke bra, så jeg satte opp noen alternativ styling for Outlook som jeg hadde lagt inn i betinget kode i malen:

Dette betydde at i Outlook ville de fremstå som enkel farget tekst:

Bakgrunnsbilder 

Kampanjemalen har en veldig særegen funksjon: En kant-til-kant-helt med et bakgrunnsbilde.

Kreditt til Marco Goran Romano for det strålende bildet som brukes som stedholder

Bakgrunnsbilder i e-post støttes ikke overalt. De to viktigste e-postklientene som stiller problemer, er Outlook 2007-2016 (Windows) og Gmail.

Outlook viser ikke vanlig bakgrunn i det hele tatt, og krever noen spesielle Vector Markup Language for å få dem til å fungere. (Stig på Campaign Monitor bakgrunns.cm er et flott verktøy for å generere denne koden). Problemet med det er imidlertid at du ender med to kodeblokker: en i HTML og en i VML. Dette er risikabelt når du vet at andre trenger å kunne enkelt oppdatere bakgrunnsbildet: hvis noen prøver å gjøre dette uten å lese instruksjonene på riktig måte, vil de trolig få det galt.

Gmail viser bakgrunnsbilder, men det respekterer ikke background-size eller Bakgrunnen-stilling egenskaper, som kan gjøre styling dem ganske vanskelig.

Vi så på abonnentnumrene og var i stand til å ringe på Outlook: Det ville være fint hvis Outlook-brukere så en solid tilbakebetalingskvalitet i stedet for bildet.

For Gmail-brukere må vi sette opp noen retningslinjer rundt akseptable bilder når malene brukes. Bakgrunnen skal enten være en sømløs gjentakende bakgrunn eller sette opp slik at den alltid vil se bra ut på 100%, festet til øverste venstre hjørne.

Interessant, Gmail gjør støtte vertikal Bakgrunnen-stilling Egenskaper på venstre side: øverst til venstre , nede til venstre og sentrum venstre . Dessverre kan du ikke posisjonere horisontalt, noe som vanligvis er det du vil gjøre ved å vise det sentrum senter .

På noen av annonseblokkene kunne vi ha bakgrunnsbilder i Gmail, fordi de er festet nederst til venstre. Disse blokkene er også tilbake til en solid bakgrunnsfarge i Outlook.

Navigere Negative Marginer 

Jeg lekte rundt med to måter å få den negative toppmarginen på mastepoten til å fungere, hvor den hvite boksen med innhold vises på selve mastopen.

I webutvikling vil du legge til et negativt margin-top til innholdsruten, støv hendene og fortsett med dagen din.

I e-postutvikling er dette imidlertid ikke mulig. Negative marginer støttes bare av en håndfull e-postklienter, og etterlater mange vanlige i smuss (som Gmail, Yahoo og Outlook.com).

Det forblir vårt første alternativ, men bruk en negativ top-margin som en progressiv forbedring, som ville vise med en margin på 0 i alle ikke-støttede klienter (sett under venstre). Ulempen er at ganske mange kunder ville se denne marginale versjonen, og layoutet mistet absolutt noe uten det.

Det andre alternativet var å fake den negative marginen ved å lage et tomt hvitt bord med riktig høyde og bredde. Ulempen med denne tilnærmingen er at Gmail-appen ofte viser små hårfjerninger når du skaler ned innhold på mobilen der det er lettere innhold over en mørk bakgrunn eller omvendt. Disse er egentlig ikke ekte linjer eller grenser, bare små feil som ikke kan løses med kode. Vi bestemte oss for å gå med dette scenariet, fordi det gav det største antall lesere, og hairlines var generelt umerkelig. Vi bestemte oss også for å holde øye med problemet og se om vi ikke var fornøyd med resultatene. (Dessverre kunne disse malene ikke bygges ved hjelp av fluid-hybrid-metoden fordi både MailChimp og Campaign Monitor har store problemer med å gjøre det.)

Ingen overlappingOverlapp, med Gmails lille linje mellom seksjoner

Forbereder for ulike plattformer

Jeg visste at jeg ville overlevere malene til Ian for integrasjon med flere e-post sendingsplattformer: MailChimp og Kampanje Monitor. Siden koden min måtte fungere godt med begge malespråkene, fulgte jeg et par tips for å gjøre denne prosessen så jevn som mulig.

Redaktørens notat: Siden design- og utviklingsfasen har vi faktisk flyttet fra MailChimp, i stedet bare ved hjelp av Kampanje Monitor. Når det er sagt, er følgende tips veldig nyttige!

Stil på det høyeste nivået mulig

For eksempel med tekst styling, brukte jeg alt til

, ikke noen av sine barn, slik at hvis celler eller avsnitt ble omgjort til redigerbare områder, var det ingen risiko for å miste noen styling hvor som helst. Tabell innhold arver sin tekst styling fra overordnet på tvers av alle e-postklienter. Det eneste unntaket er AOL-post, som ofte ikke klarer å arve farge eiendom med mindre du plasserer det på den enkelte cellen.

Bruk avsnitt for tekst

Kampanjeovervåkningsmaler krever en Multi element som skal defineres når du vil ha en redigerbar tekstblokk som muliggjør linjebrytende, fet / kursiv / understreket, lenket valgt tekst og så videre. Det bryter også automatisk inn hele teksten i Multi med en p tag, som virkelig kan ødelegge oppsettet ditt hvis du ikke har tillatt for avsnitt. Når du bruker en linjeskift i Kampanjeovervåkning, avsluttes det nåværende avsnittet og starter en ny. MailChimp gjør ikke dette, og når du lager en linjeskift, legger du ganske enkelt til a
stikkord. Men det har ikke noe problem med avsnittene og vil respektere stykkeformat som du har satt opp, så det er trygt å bruke dem til kampanjemonitorens skyld, uten å ha ubehagelige bivirkninger i MailChimp.

Velg variabler som kan velges av brukeren

En av malene behøvde å ha et sett med de forskjellige fargede overskriftene for hvert emne som kunne velges når du oppretter et nyhetsbrev i MailChimp. Jeg satte opp en gruppe overskriftsstiler som kunne velges fra en rullegardin i MailChimp, ved å bruke riktig syntaks for å definere deres @stil blokker:

/ ** * @stil emne-design * / .topic-design farge: # c94e4b;  .topic-design a color: # c94e4b;  / ** * @stil emnekode * / .topic-kode farge: # 4cc1be;  .topic-kode a color: # 4cc1be;  / ** * @style topic-web * / .topic-web color: # 49b293;  .topic-web a color: # 49b293;  / ** * @style topic-photography * / .topic-photography color: # 8360a8;  .topic-photography a color: # 8360a8;  / ** * @style topic-game * / .topic-game color: # 72BF40;  .topic-game a color: # 72BF40;  / ** * @style topic-computer * / .topic-computer color: # 5d7dba;  .topic-computer en color: # 5d7dba;  / ** * @style topic-business * / .topic-business farge: # f38844;  .topic-business a color: # f38844;  / ** * @style topic-3d * / .topic-3d color: # f95858;  .topic-3d a color: # f95858;  / ** * @stil emne-musikk * / .topic-musikk farge: # 56a4ca;  .topic-music a color: # 56a4ca; 

Men… Jeg ga dette til Ian som oppdaget at det ikke fungerte i det hele tatt; Ingen av disse overskriftsstablene ble vist i rullegardinmenyen da han redigerte teksten. Han tinkered med det og oppdaget at MailChimp faktisk ikke viser disse alternativene som valgbare overskriftsstiler, med mindre de har noen form for skriftrelatert eiendom som font-family eller font-vekt

Det fungerte heller ikke fordi jeg leverte det separat, og noen spesiell MailChimp-malkode for redigerbare områder eller egendefinerte stiler må vises i av malen din; Det kan ikke være en ekstern fil. Så vi la til en font-weight: bold erklæring til våre retninger stiler, poppet CSS i hodet, og fikk det hele til å fungere.

Final Testing og Wrapping Up

Nå som alle våre layouter var blitt vist og godkjent, bestemte problemer og kompromisser bestemt, var det på tide å fullføre testing og forberede alle filene for distribusjon.

Jeg satte meg om å gjøre mange grueling siste tester i Litmus og Email on Acid. Jeg bruker Trello til å holde oversikt over krav, oppgaver og feil for hvert prosjekt jeg jobber med. Jeg jobbet gjennom mine lister over feil og oppgaver til det ikke var noe igjen, og filene var klare til å distribuere.

Må elske Trello for oppgavebehandling

Sette opp et sett med maler 

Envato-teamet ønsket å kunne dykke inn i koden for å mikse og matche forskjellige layouter, så jeg trengte å gi klare HTML- og CSS-kommentarer, samt sørge for at overføring av moduler mellom maler ikke ville forårsake større katastrofe.

Jeg satte opp hver mal med sin egen kroppsklasse:

   

Og sett opp en klasse som kan legges til for å bytte mellom en hvit og grå bakgrunn:

Jeg har også skilt ut layoutspesifikke stiler (både mobil og skrivebord) i individuelle stilark for å lagre filstørrelse:

   

Jeg ga instruksjoner for å legge til en lenke til hvert stilark der elementer fra det aktuelle layoutet ble brukt. For eksempel, hvis en Digest-modul blir sendt til Nyhetsbrev-malen, skal Digest CSS-lenken legges til hode av nyhetsbrevmalen før du kopierer over modulen HTML.

For vanlige elementer, som annonsefeltet og annonseblokkene, sørget jeg for at stylingen var helt uavhengig av layout, slik at de kunne flyttes rundt fritt.

Jeg har tatt med alle disse instruksjonene i en README-fil, og pakket den opp med all HTML og bilder som skal sendes.

E-postleveranser

Shipping

Og så var vi ferdige! Jeg sendte alt over til Ian som tok resten av integrasjonen selv. Det er noe neglerende å overgi malfiler uten evnen til å foreta obsessivt test og omprøve under integrasjon, men jeg hadde den største troen på Ian, selvfølgelig!

Når hans arbeid var ferdig, og det var på tide å begynne å sende, sendte Ian testkopier til min Litmus og Email on Acid-kontoer, slik at jeg kunne gå gjennom forhåndsvisningene for gjengivelse og flagg eventuelle problemer. Et par bakgrunnsbilder droppet av her og der, som vi løst opp før malerne endelig var klare til å bli sendt.

I neste og siste del av denne serien tar vi våre statiske maler til neste nivå, og viser hvordan vi integrerte dem i Kampanje Monitor!

Relaterte linker

  • Hvis du trenger mer HTML-e-postinspirasjon, kan en av våre responsive e-postmaler være akkurat det du trenger.
  • Opprette en fremtidssvarlig responsiv e-post uten medieforespørsler