Nozioni base per sviluppare email HTML responsive

In questa serie di post mostreremo per sommi capi i passaggi necessari per costruire da zero una email in HTML che sia responsive e che abbia la caratteristica di reggere, senza spaginare, sulla maggior parte dei client e dei dispositivi: dal desktop al mobile.

Non sarà un percorso breve: per realizzare una email solida è necessario adottare una serie di tecniche e workaround che per il normale sviluppo web sarebbero del tutto impensabili.

È proprio in questo che l’email si distingue rispetto allo sviluppo del web: non esistendo uno standard univoco, spesso bisogna affidarsi a workaround che vanno a riempire le falle aperte dai vari client.

Si sa che le varie versioni di Outlook, da 2003 a 2016, per non parlare di Lotus Notes, hanno regalato infiniti mal di testa ai developer. Bastano questi due esempi per capire che i client sono estremamente differenti e che un codice solido deve tenere conto anche di questi aspetti.

Alla fine forse non si avrà un lavoro preciso al pixel per tutti i client, ma il punto essenziale dell’email marketing non è il delta di due o cinque pixel di padding, bensì che il messaggio sia leggibile dall’utente e che in ultima analisi passi il messaggio che si vuole comunicare.

La seconda considerazione che si può fare alla luce di quanto detto è che l’email perfetta non esiste. Non esiste.

Le variabili da tenere in considerazione e le differenze di gestione del codice HTML da parte dei vari client sono così ampie che risulta di fatto impossibile soddisfarli tutti.

Diventa imprescindibile fare delle scelte nel momento della realizzazione creativa e dello sviluppo tecnico. Volenti o nolenti bisogna scendere a compromessi.

Un approccio alla problematica è conoscere la propria audience e in base ad essa scegliere la strategia di sviluppo: se adottare una soluzione più aggressiva, più rischiosa dal punto di vista della resa dei client, oppure propendere per un codice più conservativo a favore di una email più solida.

Qualunque sia la scelta se da un lato si avranno dei vantaggi, da un altro delle penalizzazioni e alla fine si dovrà fare un bilancio complessivo se conviene adottare o meno una soluzione tecnica piuttosto di un’altra.

Personalmente credo che un messaggio, essendo tale, deve in ogni caso essere leggibile dal destinatario. Teniamo presente che un’email cerca di catturare l’attenzione della nostra audience e come tutti i messaggi deve essere letto e compreso.

Prendendo a prestito il motto del Robustness principle: “Be conservative in what you send, be liberal in what you accept”, credo che – salvo le debite eccezioni – un codice robusto, capace di superare la prova dei client più difficili sia alla lunga molto più remunerativa di soluzioni alla moda o di puro effetto funzionanti esclusivamente solo un gruppo di dispositivi.

Premessotutto questo, da dove iniziare? Qual è il punto zero di una mail?

Potrebbe sorprendere, ma lo sviluppo di una email non parte dal codice. Il primo passo è l’analisi della creatività, per individuare la struttura a blocchi da cui è composta.

Si parla di blocchi perché l’approccio modulare, in ottica responsive, è sicuramente uno dei migliori da adottare.

Il concetto di modularità introduce l’indipendenza del singolo elemento rispetto al contesto in cui è inserito. Ciò significa che una volta realizzato, è possibile spostare, modificare, rielaborare il modulo all’interno della comunicazione senza che l’intera struttura ne risenta o peggio che l’intera comunicazione spagini (effetto Picasso).

Lo stessoconcetto è estensibile a sua volta anche ai singoli elementi del modulo.

Ad esempio, una volta impostata la struttura di un bottone per una call-to-action è possibile re-inserirla in un’altra parte della email senza che ciò influenzi la comunicazione.

Lo strumento migliore, soprattutto in fase di ideazione grafica, per l’individuazione dei blocchi è un wireframe.

Con un wireframe è possibile individuare ciascun blocco costitutivo della comunicazione, definendone gli elementi principali (es. la headline, le immagini, la CTA, ecc.)

Se è possibile, risulta molto utile realizzare un wireframe anche per la versione mobile. Ricordiamoci che uno dei mantra fondamentali dell’email marketing è mobile first.

Concettosecondo cui il punto di partenza dell’ideazione grafica dovrebbe essere primala visualizzazione da smartphone.

L’esempioche andremo a considerare è un piccolo modello in cui si ha la seguentestruttura:

• Header (visualizzazione web, logo, payoff);
• Blocco principale (visual, headline, testo, CTA);
• Blocco secondario (immagini secondarie, titolo principale, abstract, CTA);
• Footer (parte di trust, contatti, ecc.);
• Legal (disclaimer, unsubscribe).

Una volta definiti i blocchi, si può cominciare a scrivere il codice, dove l’architrave portante di una solida comunicazione è il tag table.

Potrebbe sembrare un po’ fuori dal tempo parlare di tabelle nel 2019, ma se il web ha avuto grandi evoluzioni tecniche e una serie di innovazioni notevoli (si pensi all’introduzione della semantica, ai tag grafici o agli elementi multimediali), la stessa cosa non si può dire per le email.

Questo – come vedremo in altri casi – non sarà l’unico esempio in cui la mancanza di uno standard obbliga lo sviluppatore a soluzioni che possono sembrare tecnicamente sorpassate. La struttura a tabella è la soluzione più solida per mantenere un buon controllo sull’output finale sulla maggior parte dei client di posta elettronica.

Il primo passo sarà quindi costruire una tabella generale, contenitrice del modulo in cui inseriremo gli elementi (testo, immagini, CTA, ecc.) che interessano. Questa tecnica ci permette non solo di avere un buon controllo sul posizionamento del modulo, ma dà anche la possibilità di inserire tante altre proprietà come il colore o immagine di background, la spaziatura tramite padding, ecc.

Si è creata una tabella con una larghezza al 100%, esplicitando a zero i bordi, il padding e la spaziatura delle celle.

La larghezza al 100% ci assicura l’adattamento della tabella indipendentemente dallo schermo su cui sarà visualizzata. L’azzeramento delle proprietà padding, border e spacing, invece impone un punto zero di partenza evitando spiacevoli spaziature indesiderate introdotte da alcuni client, non ultimo Outlook.

Infine, tramite uno stile inline, si definisce la proprietà table-layout: fixed;.

Questo forza sul client di posta come Yahoo! la corretta larghezza della tabella al 100%.

Dato che vogliamo centrare l’intera email, impostiamo align=”center” alla cella e non alla tabella: avendo quest’ultima una larghezza al 100% risulta centrata per definizione.

Già così si possono vedere alcuni workaround che devono essere applicati se si vuole che una visualizzazione corretta sui vari client di posta elettronica. Vedremo altri punti simili nel corso dell’analisi.

Ora che si è costruito il contenitore principale, possiamo inserire il contenuto che, inutile dirlo, sarà a sua volta messo in una tabella.

La strutturaè molto simile alla precedente: l’impianto di base non cambia.

Ciò che cambia è larghezza: non più al 100%, bensì a 600px.

Questaseconda tabella è l’altra pietra angolare della mail: i 600px fissano lalarghezza da desktop della comunicazione. Ed è su questo parametro che si deveagire per impostare la larghezza complessiva della email.

A questo punto si è tentati di inserire qui il contenuto vero e proprio: testi, immagini, CTA.

È fattibile,ma non consigliabile. Il motivo è presto detto: quella appena implementata è latabella che serve solo a impostare – leggi controllare – la larghezza dellacomunicazione. Vedremo come si agirà proprio su di essa per determinare lalarghezza anche per i dispositivi mobile, in ottica responsive.

Per contenuti semplici, come ad esempio il testo view online, non è un particolare problema aggiungerli direttamente, tuttavia strutture più complesse come ad esempio il logo e il payoff (blocco 2) è meglio incapsularle in un’ulteriore tabella.

La tecnica dell’annidamento o nesting viene in nostro soccorso per due motivi: perché è funzionale alla modularità e perché ci permette un maggior controllo sul singolo elemento che stiamo definendo.

Così per il blocco 2 si può vedere come sia stata creata una nuova tabella, questa volta con due celle.

Lo stile delcodice è simile a quanto già visto: dopo aver azzerato bordi, padding espacing, si è imposta una larghezza in percentuale al 100%.

Dopodiché si dichiarano due celle: entrambe con una larghezza percentuale pari al 47%.

Si lavora con dimensioni in percentuale per avere una struttura fluida, che si adatti allo schermo su cui sarà visualizzata la comunicazione. In questo modo, quando si andrà a modificare la larghezza della tabella padre, quella con width=”600” avremo la garanzia che tutte le altre tabelle figlie si adatteranno di conseguenza.

Alle due celle non si è imposta una larghezza del 50% come suggerirebbe la logica sempre per lo stesso problema di fondo: la diversa interpretazione del codice da parte dei vari client.

Imponendo il 50% il rischio di spaginazione a causa di spaziature non volute o per l’inserimento di stili da parte dei client sarebbe troppo alto. Così alto che conviene mantenere un certo margine di sicurezza.

Inoltre i due elementi, il logo e il testo sono allineati rispettivamente a destra e a sinistra, quindi la distribuzione del contenuto ci agevola nel compiere una scelta conservativa che non dovrebbe essere fonte di criticità.

A questo punto possiamo riassumere la struttura di base dell’esempio in questo modo:

1. Tabella contenitore principale o modulo principale, con larghezza al 100%;
2. Tabella secondaria, che determina la forma della email, con larghezza 600px;
3. Tabella contenuto, con larghezza al 100% dove sono inseriti testi, immagini, CTA, ecc.

La resa dafront-end, per ora via browser, non è molto incoraggiante, lo stato dilavorazione è evidentemente molto grezzo, mancano molti altri dettagli e puntifondamentali. Ci sarà modo e tempo per vederli singolarmente.

Tuttavia, come in una costruzione, si sono gettate le fondamenta quanto più solide possibili per una corretta visualizzazione sui vari client di posta elettronica. Al prossimo blog post!