• HOME
  • Blog
  • Nozioni base per sviluppare email HTML responsive
Andrea Russo
18 Aprile 2019
Tempo di lettura: 7 min.

Nozioni base per sviluppare email HTML responsive

Come in una costruzione, occorrono solide fondamenta: oggi vediamo le operazioni per gettare le basi delle tue campagne, garantendo la corretta visualizzazione sui vari client di posta.

Un’introduzione all’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.

256x218
prova la piattaforma
Attiva la trial gratuita e scopri cosa puoi fare con MailUp.

Dallo sviluppo di integrazioni al supporto strategico, dalla creazione di concept creativi all’ottimizzazione dei risultati.

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.

Approcci e filosofia

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.

Da dove iniziare

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.

newsletter html 768x1201 2

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).

La struttura portante, le table

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.

html1

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%.

email html 997x1024 2
email newsletter html 1

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.

html2

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.

html

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à.

Per concludere

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!

Share this article

80x80
Andrea Russo

Nerd al 100% certificato; appassionato di astronomia, fisica e matematica. Credo nell’eleganza della semplicità, nel pensiero critico e nella sintesi hegeliana di esperienze come fucina di nuove idee.

    Ricevi aggiornamenti e novità con la nostra newsletter!