7 miti sullo sviluppo della posta elettronica

La posta elettronica è nata come metodo di comunicazione 1:1 di solo testo nel 1971, quando è stata ideata da Ray Tomlinson. Nel corso dei decenni l'e-mail si è evoluta, passando dalle versioni di solo testo delle prime e-mail all'HTML. A spingere l'e-mail nel futuro sono stati gli sviluppatori di e-mail, utilizzando tecniche creative entro limiti rigorosi.

A quel tempo, gli sviluppatori di posta elettronica hanno creato tutti i tipi di "best practice" per aiutare gli altri a iniziare con la codifica della posta elettronica o per fungere da promemoria per coloro che si trovano nelle trincee di ciò che gli sviluppatori di posta elettronica possono e non possono fare.

Siamo qui oggi per ricordare agli sviluppatori di posta elettronica che le best practice non dovrebbero essere viste come statiche. Cambiano. Ciò che era meglio per gli sviluppatori di posta elettronica alla fine degli anni '90 non suona più vero a metà degli anni 2010.

Ecco sette miti sullo sviluppo della posta elettronica che esistono da secoli e perché è ora di metterli finalmente a riposo:

• Mito n. 1: le e-mail devono essere larghe 600 pixel.
• Mito n. 2: è necessario utilizzare solo caratteri di sistema standard.
• Mito n. 3: utilizzare solo il DOCTYPE di transizione.
• Mito n. 4: è necessario utilizzare i selettori di attributo.
• Mito n. 5: tutti gli stili nelle e-mail devono essere in linea.
• Mito n. 6: non utilizzare immagini di sfondo nelle e-mail.
• Mito n. 7: le e-mail devono apparire identiche su tutti i client di posta.

Mito n. 1: le e-mail devono essere larghe 600 pixel.

Prima che i telefoni cellulari e i tablet diventassero comuni e l'e-mail fosse esclusivamente un'applicazione desktop, la best practice prevedeva che tutte le e-mail non dovessero essere più larghe o più strette di 600 pixel. Perché esattamente 600 pixel? La dimensione del viewport dei client di posta elettronica più comunemente utilizzati all'epoca (HoTMaiL, Yahoo e Outlook) era di circa 500-550 pixel. L'impostazione della larghezza dell'e-mail in modo che non sia più ampia di 600 pixel consentirebbe il minor scorrimento orizzontale possibile nell'e-mail.

Quella regola dei 600 pixel è rimasta. Anche se oggi ci sono più dispositivi da soddisfare, tutti con dimensioni dello schermo diverse, perché ci atteniamo alla regola dei 600 pixel?

È una regola facile da rispettare, soprattutto se il flusso di lavoro e-mail include la creazione di un design in Adobe Photoshop o Sketch: è necessaria una larghezza fisica per iniziare il design dell'e-mail. È vero che un'e-mail di 600 pixel di larghezza verrà comunque visualizzata molto bene tra i client di posta elettronica più popolari, sui desktop. E utilizzando le query multimediali, gli sviluppatori di posta elettronica possono facilmente modificare la larghezza dell'e-mail a seconda del dispositivo utilizzato dagli abbonati per aprire.

La larghezza fluida risolve il problema dell'enorme numero di dispositivi che gli sviluppatori di posta elettronica devono supportare. Per farlo funzionare, usa la larghezza massima per impedire che le e-mail diventino troppo larghe e illeggibili su finestre più grandi e le istruzioni condizionali MSO per far capire a Outlook (poiché non esegue il rendering della proprietà CSS di larghezza massima).

Le e-mail di Zalando sono larghe 450 pixel, molto lontano dallo standard di 600 pixel che siamo abituati a vedere. In combinazione con i grandi CTA, sembra che le e-mail ottimizzate per i dispositivi mobili di Zalando si rivolgano maggiormente al pubblico mobile.

Nel frattempo, le e-mail di Email Weekly utilizzano la tecnica fluida, con una larghezza massima di 960 pixel. Utilizza le query multimediali per modificare con garbo la larghezza dell'e-mail in base alla larghezza del dispositivo.

A seconda dei client e dei dispositivi utilizzati dai tuoi iscritti per aprire la tua email, può avere senso impostare la larghezza della tua email su un massimo diverso da 600 pixel.

Dove sono i tuoi iscritti che aprono le tue email? Con Email Analytics puoi scoprire in quali dispositivi e client di posta stanno aprendo le tue email. Scopri di più →

Mito n. 2: è necessario utilizzare solo caratteri di sistema standard.

I caratteri di sistema sono stati a lungo l'opzione sicura per l'uso nelle e-mail. Beh, erano l'unica opzione.

D'altra parte, i web designer hanno sperimentato l'utilizzo di caratteri non standard sul Web sin dai primi anni 2000. Nel 2008, la regola CSS @font-face ha finalmente avuto il supporto dei browser web per consentire ai web designer di utilizzare caratteri non standard sui loro siti web. Nel 2010, Google ha lanciato la propria libreria di web font, gratuita per i web designer.

Nessuna fortuna per i progettisti di posta elettronica a causa della mancanza di un metodo solido per importare i caratteri Web in un'e-mail HTML. Per non parlare della mancanza di licenza: quando i caratteri web sono stati creati per la prima volta, nessuno pensava che sarebbero stati utilizzati nelle e-mail, quindi la licenza dei caratteri web non copriva l'uso dell'e-mail.

Sebbene raccomandiamo caratteri di sistema standard nelle tue e-mail, ciò non significa che non puoi utilizzare i caratteri web come tecnica di miglioramento progressivo. I repository di font online stanno iniziando a coprire l'uso della posta elettronica nelle loro licenze. E Google Fonts, con i suoi 800 caratteri web gratuiti, sta diventando la libreria di riferimento per i progettisti di email che desiderano utilizzare caratteri web non standard nelle loro email.

Il supporto per i caratteri Web esiste in Google Android 4.4, Apple Mail per iPhone, iPad e Mac e Outlook 2011 e 2016 su OS X. Potrebbe non sembrare molto, ma a settembre di quest'anno quattro dei primi cinque client di posta elettronica , nella quota di mercato, supporta i caratteri web: iPhone, iPad, Google Android e Apple Mail. Questo è oltre il 50% di tutte le email aperte a settembre! Certo, devi guardare la tua base di iscritti, ma questo è un buon indicatore di quante persone potenzialmente saranno in grado di vedere i caratteri web nelle tue e-mail.

Riesci a vedere le sottili differenze tra queste due e-mail? Quello a sinistra utilizza i caratteri web, mentre quello di destra ha i caratteri web disabilitati. The Outnet ha scelto un ottimo carattere di riserva che è molto simile nell'aspetto al loro carattere web, mostrando come puoi utilizzare i caratteri web in modo coerente nella tua email oggi.

Mito n. 3: utilizzare solo il DOCTYPE di transizione.

Il DOCTYPE di un documento HTML indica al browser come eseguire il rendering della pagina e viene utilizzato per convalidare l'HTML del documento.

Il DOCTYPE più comunemente usato nelle email è:

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Gli sviluppatori di posta elettronica hanno preso la buona abitudine di avere un DOCTYPE, anche se alcuni client di posta rimuoveranno completamente il DOCTYPE o lo sostituiranno con uno diverso. Gmail, Outlook.com e Yahoo! La posta è tra i client di posta elettronica che eliminano qualsiasi DOCTYPE presente nella tua email e lo sostituiscono con DOCTYPE HTML5.

Sul Web, diversi DOCTYPE modificano il modo in cui vengono rese alcune proprietà CSS ed elementi HTML. Il DOCTYPE di cui sopra consente la più ampia gamma di elementi HTML, inclusi elementi deprecati come <font>, che sono stati utilizzati nelle e-mail. Nei test precedenti, questo DOCTYPE si è dimostrato il più affidabile per la posta elettronica. È stato dimostrato: tempo passato.

Questo era prima che HTML5 diventasse lo standard che è ora:

 <!DOCTYPE html>

Il DOCTYPE HTML5 consente l'utilizzo di elementi HTML5 più recenti, ad esempio <video>, che possono essere utilizzati nelle e-mail. Sebbene non tutti i client possano essere in grado di eseguire il rendering dei nuovi elementi o proprietà, non c'è motivo per non spostare la tua email in futuro aggiornando il tuo DOCTYPE. Puoi ancora utilizzare il codice obsoleto con un DOCTYPE HTML5, ma il codice non sarà più valido se controllato tramite un servizio di convalida. Sebbene non vi sia alcun impatto sulla tua email in termini di consegna o prestazioni se il tuo codice è valido o meno, può essere una buona idea controllare il tuo markup HTML per i tag HTML aperti, che possono influire sul modo in cui viene visualizzata la tua email.

Mito n. 4: è necessario utilizzare i selettori di attributo.

Yahoo! Mail è stato un client di posta elettronica leggermente più gentile da sviluppare rispetto, ad esempio, a Outlook. Ha supportato lo stile nella testa per tutto il tempo che possiamo ricordare. Una stranezza Yahoo! Mail offriva che rendesse qualsiasi istruzione CSS in una media query insieme a qualsiasi CSS al di fuori delle media query. La semplice soluzione a questo problema era scrivere l'istruzione CSS come selettore di attributi:

 *[class=”foo”] {color:#000000; font-family: sans-serif;}

Scrivere CSS nella testa di e-mail come questa è diventato lo standard poiché altri client di posta elettronica, che leggono anche lo stile nella testa, non hanno avuto problemi a leggere semplici selettori di attributi, come nell'esempio sopra.

All'inizio del 2015, Yahoo! Mail ha lanciato un aggiornamento che gli ha permesso di leggere lo stile come farebbe qualsiasi client di posta elettronica "normale":

 .foo {color:#000000; font-family: sans-serif;}

Tuttavia, poiché i selettori di attributo erano stati così radicati nello sviluppo della posta elettronica, non era sorprendente vederli ancora in giro nel codice della posta elettronica. Gli sviluppatori di posta elettronica erano semplicemente abituati a usarli e spesso i modelli di posta elettronica non venivano aggiornati.

Precedentemente innocui, i selettori di attributi ora possono fare un po' di danni alla tua email, se li hai nel tuo codice. Se lo stile della tua email non sembra funzionare in Gmail, controlla se stai ancora utilizzando i selettori di attributo nel tuo stile. Gmail non supporta i selettori di attributi, ma ora (finalmente!) supporta lo stile in <head>.

Con i selettori di attributi non più necessari per Yahoo! Mail e la mancanza di supporto di Gmail per loro, non è necessario utilizzare i selettori di attributo nel CSS nelle tue e-mail.

Mito n. 5: tutti gli stili nelle e-mail devono essere in linea.

Le tabelle per gli stili di layout e inline sono state la base dello sviluppo della posta elettronica da... da sempre. Definiscono la differenza tra e-mail e sviluppo web. Gli stili inline sono ora così comuni per gli sviluppatori di posta elettronica, è diventato un po' confuso il motivo per cui gli stili dovevano essere inline in primo luogo.

Incredibilmente, alcuni siti affermano che il motivo per cui sono necessari gli stili in linea è dovuto a Outlook e Gmail. Il che è semplicemente sbagliato. [Twitta questo]

Outlook non ha mai avuto problemi con lo stile nella testa dell'e-mail. Gmail invece sì. Gmail è stata letteralmente la ragione principale (con una quota di mercato del 16% a settembre 2016) per cui gli sviluppatori di posta elettronica incorporano il loro CSS.

Alla fine di settembre, Gmail ha iniziato a supportare lo stile nella testa. Quindi abbiamo più bisogno di incorporare tutti gli stili?

Se i tuoi abbonati utilizzano principalmente Gmail, iOS o persino Outlook, possiamo dire con sicurezza che ora è il momento di spostare i tuoi stili in testa. Tuttavia, se la maggior parte dei tuoi abbonati utilizza client di posta elettronica oscuri o client di posta elettronica internazionali (Yandex, Libero, Terra) che si basano su stili in linea, potrebbe essere necessario continuare a utilizzarli. Come sempre, consigliamo di testare la tua email ogni volta che apporti modifiche importanti.

Mito n. 6: non utilizzare immagini di sfondo nelle e-mail.

Le immagini di sfondo sono notoriamente difficili da ottenere direttamente nelle e-mail. Gli sviluppatori di posta elettronica utilizzano codice VML complicato per il rendering in molte versioni di Outlook e c'è stata una mancanza di supporto per le immagini di sfondo anche in altri client di posta elettronica.

Ecco il punto: le immagini di sfondo possono funzionare e funzionano nelle e-mail, ma è il modo in cui vengono incorporate nel design della tua e-mail. Con un supporto limitato, non dovresti utilizzare le immagini di sfondo come elemento chiave nel design della tua email, perché ciò crea o distrugge l'esperienza per il tuo abbonato. Ma puoi usarli nella tua e-mail in modo simile a come useresti i caratteri web, come un miglioramento progressivo.

Uno dei motivi principali per non utilizzare le immagini di sfondo nella posta elettronica è stata la mancanza di supporto da parte di Gmail per le proprietà CSS background-size e background-position. Queste proprietà CSS sono importanti per gli schermi ad alta densità di pixel e per le e-mail ibride/fluide/reattive, in cui è necessario disporre di una certa quantità di controllo su come vengono ridimensionate e posizionate le immagini di sfondo. Entrambi sono ora supportati in Gmail e Inbox by Gmail, quindi c'è ancora meno motivo per non provare a utilizzare le immagini di sfondo nelle e-mail.

Kristian Robinson, Lead Email Developer presso TWO Digital marketing e relatore dell'Email Design Conference 2016, approfondisce le immagini di sfondo nelle e-mail, se ti senti ispirato ad affrontarle.

Mito n. 7: le e-mail devono apparire identiche su tutti i client di posta.

I client di posta elettronica hanno tutti modi leggermente diversi di visualizzare i messaggi di posta HTML. Piuttosto che accettarlo, gli sviluppatori di posta elettronica hanno cercato di farsi strada verso e-mail identiche attraverso una moltitudine di client di posta elettronica. Un compito molto onorevole da intraprendere, ma può portare a codice HTML gonfio e hacky che può essere un incubo da gestire e mantenere aggiornato.

Potrebbe non essere lo sviluppatore di posta elettronica che cerca la perfezione della posta elettronica, ma il cliente o altre parti interessate. Tuttavia, è responsabilità dello sviluppatore di posta elettronica educare le persone intorno a loro a comprendere le insidie ​​dello sviluppo della posta elettronica: perché i client di posta elettronica vengono visualizzati in modo diverso e perché non importa se qualcosa è 1 pixel più alto in un client di posta elettronica rispetto a un altro.

"Il tempo in cui le e-mail dovevano essere perfette per i pixel è molto alle nostre spalle." @ericlepetitsf #LitmusLive

— Chad S. White (@chadswhite) 16 agosto 2016

Questo mito è particolarmente dannoso quando si tenta di utilizzare nuove tecniche nelle e-mail, che potrebbero non essere visualizzate sul 100% dei client di posta elettronica, ad esempio i caratteri Web e le immagini di sfondo. Entrambi sono modi fantastici per migliorare la tua email. E dove saremmo come industria se non provassimo ad adottare e sperimentare nuove tecniche nelle nostre e-mail?

Solo perché qualcosa è stato fatto in un modo particolare per anni non significa che non ci sia un modo migliore per farlo. Ora è il momento di mettere in discussione le regole e le migliori pratiche con cui l'industria dell'email marketing ha lavorato per decenni.

Codifica le email più velocemente e più facilmente con Builder

Velocizza il flusso di lavoro di sviluppo della posta elettronica con Builder, l'unico editor di codice creato appositamente per la posta elettronica. Ed è gratis!

Inizia a usare Builder →