Che cosa dovreste conoscere delle email HTML

L'email è un mezzo fantastico. Va direttamente nella posta in arrivo e il suo ROI ha ampiamente riportato un record del 4000%. È anche perennemente fraintesa e troppo spesso è fatta male. Con la recente esplosione degli smartphone, leggeremo più spesso la nostra posta sul nostro iPhone o Galaxy, ma purtroppo un sacco di email marketing non è riuscito a tenere il passo. Lo vedo questo come un'enorme occasione persa perché un'email ben eseguita può essere piacevole da aprire e un enorme successo.

Programmare un'email HTML può essere una sfida

Se avete già provato la progettazione e lo sviluppo di un'email HTML, probabilmente avete già stabilito che può essere abbastanza difficile. E non ve lo state immaginando — è abbastanza difficile. Ecco perché:

Non esistono standard di posta elettronica

[Noi] continueremo a utilizzare Word per la creazione di messaggi di posta elettronica perché crediamo che sia la migliore esperienza esistente per la creazione e la modifica di email.

Il Team di Outlook

Quando programmate per il web, potete almeno contare sul fatto che tutti i principali browser (Chrome, Firefox, Internet Explorer, Safari e Opera) stanno cercando di aderire agli standard web per il rendering di HTML e CSS.

Quando si tratta di client di posta elettronica, state testando su un enorme mucchio di vecchi e nuovi programmi. Si va dai nuovi telefoni che usano Android e iOS agli IBM Lotus Notes o Microsoft Office 2007 (che in modo ignobile esegue il rendering del vostro codice HTML creato con amore con il motore di rendering HTML di Word. Le versioni precedenti di Outlook utilizzavano un browser per il rendering HTML — che è effettivamente logico. Perché passare a un elaboratore di testo per il rendering dell'HTML vi chiederete? Beh, per "ragioni di sicurezza", dicono). E nessuno di questi programmi deve rispettare alcun standard. In pratica tutti lo inventano. Potete vedere a cosa assomiglia il supporto degli standard per alcuni dei più popolari client di posta elettronica sull'Email Standards Project.

Come se non bastasse, accoppiatelo con il seguente fatto: ci sono circa 1 milione di diverse combinazioni di modi in cui si può eseguire il rendering dell'email sul desktop e sul mobile.

Ecco un elenco di alcuni dei più comuni client di posta elettronica:

Client mobili:

• Android 2.3 & 4.0
• iPhone 5 iOS 6
• iPhone 4S iOS 6
• iPhone 3GS iOS 5
• iPad 2 iOS 6
• BlackBerry OS 4 & 5
• Symbian S60
• Windows Phone 7.5

Client desktop:

• Apple Mail 4, 5, 6
• Lotus Notes 8.5
• Lotus Notes 8
• Thunderbird
• Windows Live Mail
• Outlook 2013
• Outlook 2011 for Mac
• Outlook 2010
• Outlook 2007
• Outlook 2003
• Outlook 2002/XP
• Outlook 2000

Client webmail:

• AOL Mail (su qualsiasi browser)
• Gmail (su qualsiasi browser)
• Outlook.com (su qualsiasi browser)
• Yahoo! (su qualsiasi browser)

Sono un sacco di dispositivi!

Se avete già familiarità con lo sviluppo web, dimenticate tutto quello che sapete.

A complicare tutto questo, lo styling condizionale non è nemmeno un'opzione. Ci sono alcune cose che potete fare con i commenti condizionali, ma è limitato a individuare determinate versioni di Outlook, o a tutto tranne alcune versioni di Outlook.

Se avete già familiarità con lo sviluppo web, dimenticate tutto quello che sapete. L'ostacolo singolo più grande per voi è aspettarsi che le cose funzionino come il 'normale' sviluppo web. Questo vi frustrerà e vi tratterrà. La cosa peggiore che potete fare è arrabbiarvi perché non potete utilizzare i div o che margin non è completamente supportato. Quindi dimenticate tutto quello che sapete sull'HTML semantico e le più recenti specifiche CSS Fidatevi di me, vi aiuterà.

Come affrontare il vostro lavoro

Diamo un'occhiata ad alcuni suggerimenti sul flusso di lavoro per la realizzazione dell'email.

In primo luogo lavorate strutturalmente

La costruzione della struttura della vostra email per prima cosa può aiutarvi a evitare molti bug e problemi più tardi. Mai costruire il tutto e poi testare — spesso si può finire con troppi bug da affrontare, e tutti possono essere influenzarsi reciprocamente.

Testate spesso

Lavorate fino a raggiungere un traguardo di sviluppo minore (ad esempio, quando finite la struttura di base) e quindi eseguite un test. Il modo migliore per testare è utilizzare Litmus o Email on Acid. Vi consiglio di prendere un piano illimitato con una di queste aziende, perché essendo in grado di testare frequentemente è davvero importante.

Mi piace molto anche lasciare tutti i bordi della mia tabella in modo che possa vedere quello che sto creando, quindi li tolgo tutti alla fine. Potete forse anche colorare lo sfondo di alcune celle per aiutarvi a vedere dove sono le varie sezioni. Il mio flusso di lavoro ideale è quello di creare uno scheletro, testare, quindi aggiungere il mio contenuto, i test, i colori e i caratteri, provare nuovamente e infine rimuovere i miei bordi e provare nuovamente prima dell'invio.

Convalidate spesso

Convalidatelo con il validatore W3C quanto il più spesso possibile. Questa vi aiuterà ad appianare i piccoli dettagli e si accorgerà degli errori come tag mancanti o aperti.

Inviare la vostra Email

Ci sono un numero enorme di opzioni quando si tratta di inviare la vostra email. I due servizi che uso di più sono MailChimp e Campaign Monitor. Offrono prezzi competitivi e sono molto facili da usare. Ci anche sono un sacco di piattaforme commerciali — tutto dipende dalle vostre esigenze. Iscrivetevi gratis con uno di questi e smanettate con i loro sistemi per vedere quello che vi piace. Assicuratevi di utilizzare i dati utili che entrambi i servizi raccolgono sulla vostra email, come i tempi di apertura e l'utilizzo del client di posta elettronica. Questo può davvero aiutarvi a concentrare i vostri sforzi nell'area giusta la prossima volta che inviate.

Contenuti, sviluppo e punteggio SPAM

Quando si tratta di SPAM; contenuti, progettazione e sviluppo vanno mano nella mano. È importante evitare tattiche tipiche dello spam come l'utilizzo di maiuscole e un sacco di punti esclamativi nel vostro oggetto. Ci sono alcune parole che sono anche suscettibili di innescare i filtri  SPAM filtri (come 'gratis' e 'investire'). Più il codice è pulito, meno è probabile che la vostra email sia contrassegnata come SPAM, e anche il rapporto tra le immagini e il testo ha un effetto. È più probabile che le email basate su immagini senza testo vengano contrassegnate come SPAM e così sono le email con nomi di file davvero lunghi.

Il mondo dei punteggi di SPAM è uno spinoso ed è importante eseguire un test di SPAM tramite il vostro account di prova con Litmus o Email on Acid prima di inviare la vostra email, per assicurarvi che tutto il vostro duro lavoro non è andato dritto nella cartella di posta indesiderata.

Immergetevi nello sviluppo

Ora, per gli aspetti fondamentali dello sviluppo di email...

Strumenti del mestiere

È necessario un editor di testo che vi piace (io uso Sublime Text) e un account di prova su Litmus o Email on Acid. Consiglio vivamente di avere un account di prova illimitato con una di queste aziende poiché vi renderà la vita molto più facile. Se non pagate un canone mensile, finirete per pagare tra i $3 e i $5 per ogni test che si sommano abbastanza rapidamente.

Partite con una buona Base

Penso che è bene iniziare con un foglio bianco. I framework come HTML Email Boilerplate sono pieni di trucchi meravigliosi e frammenti di codice che è possibile implementare pezzo per pezzo. Tuttavia, se siete appena agli inizi non vi consiglio di usarlo come punto di partenza in quanto contiene un sacco di elementi di cui non avrete bisogno. Boilerplate spesso può rendere più difficile la risoluzione di eventuali problemi se c'è un sacco di codice inutilizzato nel file.

Nota: Perché può essere molto precario utilizzare qualsiasi tipo di editor (soprattutto quando è il momento di risolvere i problemi), non si dovrebbe mai utilizzare un editor WYSIWYG, o qualsiasi tipo di editor che promette di prendere il vostro disegno formattato e magicamente trasformarlo in codice HTML valido per inviare email. Questa roba non funziona mai.

!DOCTYPE

Questo potrebbe sembrare un dettaglio tecnico per cominciare, ma avete bisogno di un modello vuoto su cui iniziare a lavorare, e tale modello ha bisogno di un Doctype. Un doctype è essenzialmente una riga di codice che informa il programma che lo legge quali tag HTML aspettarsi e a quale set di regole, l'HTML e il CSS aderiscono. Parecchi client si sbarazzano del vostro Doctype, e alcuni applicano persino il loro. Molti client onorano il vostro doctype e può rendere le cose molto più facili se potete convalidare costantemente rispetto a un Doctype.

Utilizzare un doctype XHTML generalmente ha il minor numero di stranezze e incongruenze tra i documenti. Io uso XHTML 1.0 Transitional, perché ha dimostrato di essere il più affidabile doctype nella mia esperienza. Nel seguente tutorial, durante il quale costruiremo un modello completo di email HTML, useremo il codice seguente per iniziare il nostro documento:

1

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

2

<html xmlns="http://www.w3.org/1999/xhtml">

3

<head>

4

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

5

<title>Demystifying Email Design</title>

6

<meta name="viewport" content="width=device-width, initial-scale=1.0"/>

7

</head>

Il tag meta Content-Type è per dire al motore di rendering di destinazione come elaborare il testo e i caratteri speciali. In realtà, è necessario codificare tutti i vostri caratteri speciali in ogni caso (ad es. & diventa & per e commerciale) per essere sicuro, ma vale la pena tenere questa linea da qui in poi.

Il meta tag viewport sta dicendo al dispositivo di impostare l'area visualizzabile alla larghezza dello schermo del dispositivo. Stabilisce inoltre la scala iniziale su 'normale' che non viene né ingrandita né rimpicciolita. Se non lo specificate, molti smartphone possono scalare il contenuto verso il basso così che il contenuto si inserisce all'interno dell'area visibile, ma non i suoi padding o margini. Questo può comportare che il testo e le immagini cozzino proprio contro il bordo dello schermo.

Infine, inserite sempre un titolo significativo, perché questo è ciò che le persone vedranno quando visualizzano l'email in un browser, o la condividono con i loro amici.

L'email è tutta una questione di tabelle nidificate

A causa della mancanza di supporto per gli standard nell'email, non è possibile utilizzare div, sezioni o articoli — invece è necessario utilizzare le tabelle. Inoltre, è necessario utilizzare un sacco e un sacco di tabelle nidificate, perché né gli attributi colspan né rowspan sono correttamente supportati.

Paragrafi o celle?

Ancora una volta, a causa della mancanza di supporto per gli standard, non è una grande idea di utilizzare i tag standard come h1, h2, h3 o p. Trovo che questi possono renderizzare davvero in modo incoerente nei client di posta elettronica e possono creare dei mal di testa piuttosto forti.

Il modo migliore è quello di posizionare ogni blocco di testo nella propria cella e applicare lo stile in linea a tale cella, per esempio:

1

<tr>

2

 <td style=“font-size: 12px; font-family: Arial, sans-serif; color: #666666;”>

3

   Text

4

 </td>

5

</tr>

Stili inline o fogli di stile?

Questa è una scelta personale. Io preferisco mantenere tutti i miei stili inline (vale a dire: all'interno degli stessi tag HTML) perché mi piacerebbe sapere esattamente dove si trova tutto e cosa sta interessando cosa. Potete programmare utilizzando gli stili e poi metterli tutti inline alla fine (Campaign Monitor e MailChimp possono farlo per voi automaticamente, potete anche utilizzare Premailer o qualcosa di simile), ma il motivo per cui non mi piace è perché conoscerete il vostro codice, lo lancerete attraverso un inliner, e quindi il vostro codice può diventare un po' irriconoscibile. Trovo che questo ne rende più difficile la risoluzione. Non dimenticate: non è possibile applicare più classi di cose nell'email HTML perché non sono supportate.

Non dimenticate: non è possibile applicare più classi di cose nell'email HTML perché non sono supportate. Ogni elemento può avere al massimo una classe.

Inoltre, non dimenticate: non è possibile utilizzare abbreviazioni per cose come la dimensione del carattere (cioè style="font: 8px/14px Arial, sans-serif;") perché non è supportato.

I nomi delle immagini e il punteggio SPAM

Quando si salvano le immagini è necessario ricordare che è bene dare nomi alle vostre immagini che siano brevi e significativi perché migliorerà il vostro punteggio di spam. Nomi come "campaign_054_design_0x0_v6_email-link.gif" rischiano di avere un punteggio di SPAM più alto rispetto a "email.gif".

Dimensione dell'immagine

È anche un'ottima idea cercare di mantenere la vostra intera email quanto più piccola sia umanamente possibile: meno di 100kb è ideale, ma non sempre è possibile, sotto i 250kb è piuttosto standard. Utilizzate un'applicazione di compressione come JPEGmini o tinyPNG per ridurre di dimensione tutte le vostre immagini per quanto possibile prima dell'invio. Tempi di caricamento più lenti, soprattutto sul telefonino, possono inviare o distruggere la vostra email se la dimensione complessiva del file è troppo grande.

Altri trucchi

Non lasciare nulla al client di posta elettronica. Specificate tutte le larghezze, perché altrimenti si potrebbe finire con risultati imprevisti. Per gli elementi del contenitore principale impostate sempre la dimensione in pixel. Potete allora utilizzare le percentuali all'interno del vostro elemento contenitore, se lo desiderate.

Conclusione

C'è un sacco da prendere in considerazione quando si progetta e si sviluppa un'email HTML, la maggior parte delle quali coinvolge standard "da disimparare" che siete stati incoraggiati a praticare nel web design nel corso degli anni. Tuttavia, questo tutorial dovrebbe darvi una solida base per lavorare, e ora siete pronti a saltare nel processo di realizzazione. Avanti!

Link utili

Ho fatto riferimento a un paio di cose durante questo tutorial - così eccoli qui di nuovo, in un unico posto.

• Strumenti di test di Litmus
• Strumenti di test di Email on Acid
• Il Blog del Team di Outlook
• Il Blog del Team di Litmus
• L'Email Standards Project
• Validatore del W3C
• MailChimp
• Campaign Monitor
• Premailer, verifica preliminare per le email
• Strumento di compressione di immagine JPEGmini
• Strumento di compressione di immagine tinyPNG
• Sublime Text, il mio editor preferito
• Dite ciao a HTML Email Boilerplate
• Non dimenticate il Viewport Meta Tag
• Icone Thumbnail di Pierre Borodin