I løbet af de sidste par år har stigende mobil brug udløst en udvikling, eller måske revolution, på den måde, vi nærmer os at levere indhold til online brugere. Det ultimative mål er en væske-, mobil- og enhed-agnostisk web, og en tankegang er fremkommet som det mest fordelagtige middel til dette formål: responsivt design. Men selvom den responsive zeitgeist har samlet damp, har e-mail-design og -udvikling kæmpet for at holde trit.

Dette skyldes til dels, at HTML-e-mails er et notorisk vanskeligt medium for udviklere at arbejde med. Arkæisk e-mail-klientteknologi og mangel på standarder har gjort mange af reglerne for moderne semantisk kode ubrugelig. Men e-mail er stadig en vigtig marketingkanal, der er for vigtig for at blive overset. I en halv måned i 2012 rapporterede Litmus en stigning på 80% i e-mail, der åbnes på mobile enheder. I samme år afslørede kampagnemonitoren, at deres mobile e-mail-åbningsrate for første gang faktisk havde overgået desktop og webmail.

Det er klart, at det er vigtigt at foretage en korrekt analyse af dit publikum, før man træffer beslutningen om at investere i mobiloptimering. Men et godt udført responsivt e-mail-design kan sikre en fremragende brugeroplevelse til både desktop og mobile brugere - og med udbredt 4G lige rundt om hjørnet er trenden mod mobil ubemærket, så hvorfor ikke fremtidssikker?

Kvadratisk peg, rund hul

Hvis du nogensinde har haft det uheldigt at åbne en fast bredde-email på en mobil enhed, så forstår du behovet for lydhurt email-design. Skærmbrud, layouter med flere søjler kan fremhæves zoomet ud, så skrifttypestørrelser reduceres til punktet for ulæselighed. Brugere kan zoome ind, men skal så konstant og smidigt kræve at rulle vandret til venstre og tilbage igen for at læse indhold. Lænkerne forekommer små og overbelastede, uden hensyntagen til fede fingre på berøringsskærmen. Og design med lav kontrast på små visningsporte, dæmpet for at spare strøm, bliver ofte ulæselige. Det er klart, mobiloptimering er vigtig, men hvad er den bedste måde at klare sig på?

internal_img1

Mobil bedste praksis

Før du skriver en enkelt kode kode, kan overvejelser af designfunktioner i høj grad forbedre brugeroplevelsen for dem på mobilen, selvom det nok er tilrådeligt at anbefale indrømmelser uanset skærmens størrelse.

  • Klar, kortfattet indhold: Små skærme betyder, at det er vigtigere end nogensinde at engagere brugeren så effektivt som muligt.  
  • Enkelt søjle layout: enkelhed er nøglen. Layouter ikke større end 640px vil nedbrydes yndefuldt. En enkelt kolonne sikrer intet indhold vil blive helt tabt uden for visningsporten, når den zoomes ind.
  • En engagerende emnelinje: Dette er en af ​​e-mail marketingmedarbejderens mest effektive våben i en overfyldt indbakke. Hold det kort og snappy.
  • Stort anfald til handling (CTA): Straffer ikke fede fingre! Apples iOS Human Interface Retningslinjer anbefaler et minimum "tappable" målområde på 44 × 44 point.
  • Generøse skrifttypestørrelser: Sørg for, at din besked let kan læses.
  • Pre-header: Et andet nøgleområde, når det kommer til synlighed i indbakken. Prøv at undgå at blot vise 'visning i browser' tekst.
  • Venstrejusteret tekst: Der er en række grunde til at tilpasse vigtige elementer til venstre på indholdsområdet. (Eye tracking research tyder på, at vestlige brugere fokuserer størstedelen af ​​deres opmærksomhed på venstre side af e-mail indhold. Dette er næppe overraskende, da vi læser tekst fra venstre mod højre. Visse operativsystemer, især Android, vil ikke skalere indholdet til at passe skærmen viser derfor kun den venstre halvdel af en email. Fra et ergonomisk perspektiv vil de fleste brugere finde det nemmest at interagere med elementer nederst til venstre / midt på deres håndholdt skærm.)
  • Lodret hierarki: mindsket skærm fast ejendom placerer mere troværdighed end nogensinde på ideen om 'fold'en. Væsentlige CTA'er skal placeres så tæt på toppen som muligt hvis de ikke ses straks, vil de måske ikke blive brugt.
  • Brug billederne omhyggeligt: Antag ikke, at billederne ses. iPhone's native email app vil vise billeder som standard, men mange kunder vil ikke.

Disse tip kan forbedre brugeroplevelsen for mobilkunder, men du kan og muligvis optimere yderligere. Takket være den voksende CSS3-understøttelse blandt mobil e-mail-klienter, er responsivt email design nu muligt.

Kom i gang

Som jeg nævnte tidligere, lider HTML-e-mails af en voldsom mangel på standarder - til de uindviede, vil meget af det følgende være en rejse tilbage i tiden til de tidlige dage af webudvikling. Layouts skal arrangeres med tabeller på grund af de uddaterede HTML-renderingsmotorer af nogle e-mail-klienter, og CSS skal anvendes inline. Flere e-mail-klienter ignorerer helt de stilerklæringer, der er lavet i afsnit af dokumentet.

Der er nogle fantastiske email boilerplates tilgængelige, jeg anbefaler Sean Powell fremragende HTML Email Boilerplate Som udgangspunkt, men for demonstrationens skyld, lad os begynde fra bunden.

For de af jer, der gerne følger med koden, kan du download en skabelon til denne artikel herfra.

doctype

Hotmail og Gmail indsætter automatisk XHTML 1.0 Strict doctype. Det er derfor ikke en dårlig ide at bruge det, men det er vigtigt at teste din email grundigt med og uden en doktype, da mange e-mail-klienter helt enkelt vil fjerne det helt.

Email på Acid har gennemført omfattende undersøgelser af e-mail-typer her.

Medieforespørgsler

Vi kan nu indsætte et metadag for visningsporte for at sikre, at vores email vises korrekt på mobile enheder. Det er også en god idé at angive indholdstypen og et titelmærke også. Disse vil blive ignoreret af mange e-mail-klienter, men det er en god ide, hvis du planlægger at give et link til en "browser version" af din email.

Da indholdstypen sandsynligvis ignoreres, er det tilrådeligt at kode alle specialtegn i din e-mail som HTML-enheder.

Vi vil også inkludere et par fornuftige stilindstillinger for at sikre, at vores e-mail bliver gjort, hvordan vi vil have det på tværs af platforme.

Email subject or title

Bemærk, at Viewport Meta Tag har negative konsekvenser for Blackberry.

Nu kan vi indsætte vores medieforespørgsler; hvor mange afhænger af det specificitetsniveau, du ønsker at levere til hver enhed. I dette eksempel vil vi kun bruge en - hvilket gør den fornuftige antagelse, at de fleste enheder med en skærmstørrelse, der ikke er større end 600px, er moderne, mobile og touch-screen og vil drage fordel af mobiloptimeret styling. Desuden vil vi antage, at ved at følge de universelle mobile bedste praksis teknikker, der skitseres tidligere, vil mobile brugere på større enheder, der modtager skrivebordets layout, ikke støde på store anvendelsesmuligheder.

Vi bruger medieforespørgsler på samme måde, som vi ville, når vi byggede en hjemmeside; hvis visningsstørrelsen er inden for de begrænsninger, der er angivet i medieforespørgslen, skal du anvende den stil.

@media only screen and (max-width: 600px) {table[class="hide"], img[class="hide"], td[class="hide"] {display:none!important;}}

I eksemplet ovenfor fortæller vi nogle elementer med en klasse af "skjul" til visning: ingen på skærme snævrere end 600px. Den vigtige ejendom sikrer, at enhver inline-stil overskrides. Dette er det grundlæggende princip for responsivt email design: overordnede inline stil erklæringer lavet i HTML dokumentets krop med! Vigtige stil erklæringer lavet i afsnit og målretning mod disse stil overstyres til specifikke skærmstørrelser med medieforespørgsler. En glimrende undtagelse er gmail-appen, som vil ignorere stilformler i afsnit. Men samvittighedsfuldt venstrejustering af indhold skal sikre en tilfredsstillende brugeroplevelse for gmail-fans i din mailingliste. Selvfølgelig er dette ikke en ideel løsning, men i øjeblikket er responsivt email design lige så meget om at betragte kompromiser, som det handler om avancerede teknikker.

Det er værd at bemærke, at vi målretter mod vores HTML-elementer med CSS-attributtselektorer for at overvinde en gengivelse af Yahoo! Post.

Så vi kan se, at medieforespørgsler er et nyttigt værktøj til selektivt at vise indhold, men vi kan også bruge dem til at manipulere andre funktioner i vores layout. Måske vigtigst kan vi begrænse kolonnebredden af ​​vores email - nøglen til en fantastisk mobil oplevelse.

@media only screen and (max-width: 600px) {table[class="content_block"] {width: 92%!important;}}

Vi har nu angivet i vores medieforespørgsel, at alle tabeller med en klasse af "content_block" skal skalere til 92% bredde på enheder med en skærmstørrelse på op til 600px. Nu er alt, hvad vi skal gøre, at angive en breddeattribut inline (600px) for ethvert bord med en klasse content_block, og vi har en fast breddebeholder, som derefter skaleres proportionalt på skærme under en vis størrelse. Forudsat at breddeattributterne af barnets elementer i denne beholder alle er angivet som procentdele, er dette en grundlæggende lydhør-e-mail-skabelon.

Vær forsigtig, når du deaktiverer webkit automatisk justering af tekststørrelsen på legemærkatet, skal du som en tommelfingerregel forsøge at beholde skrifttypestørrelser over 12 px minimum.

Knapper

Opkald til handling (CTA) er normalt den vigtigste del af en marketing e-mail. De skal være iøjnefaldende, velplacerede og frem for alt anvendelige. Kriterierne for en stor CTA er forskellige afhængigt af om det skal vælges af en markør eller en finger. Dette er en stærk funktion af responsiv email; at give brugere på mindre berøringsskærmsenheder med fingervennlige knapper, der ikke påvirkes af billedblokkere.

internal_img2

Desværre kan sådanne knapper ikke vises universelt, da de er afhængige af polstringsegenskaber, som ikke understøttes i nogle stationære e-mail-klienter.

@media only screen and (max-width:600) {a[class="button"]{display: block;padding: 7px 8px 6px 8px;-webkit-border-radius: 5px;-moz-border-radius: 5px;border-radius: 5px;color: #fff!important;background: #f46f62;text-align: center;text-decoration: none!important;}}

Stildeklarationerne ovenfor vil omdanne tags med en klasse af "knap", som den nedenfor, til store, engagerende, farvede knapper, der spænder over bredden af ​​indholdsområdet, så længe enhedens skærmbredde ikke er større end 600px. CSS3-understøttelse bør ikke være et problem, da vi kan antage, at den mobilteknologi, vi målretter mod, er rimeligt moderne.