Una newsletter formattata con l’utilizzo di un layout HTML rende il messaggio decisamente più efficace e piacevole da ricevere rispetto a una newsletter in stile “muro di testo”.

La criticità più frequente nella costruzione di una newsletter è, di fatto, la sua resa, che non sempre appare uniforme su tutti i client di posta di chi la riceve. Succede spesso che, effettuando una verifica dopo l’invio su diversi client di posta, si noti una difformità del messaggio quando visualizzato in Outlook, mentre in Gmail la formattazione appare corretta (o viceversa).

Sebbene degli standard per la costruzione del template HTML validi su tutti client di posta esistano, sono gli stessi client che decidono di bloccare alcuni tag HTML nella posta. Per fortuna esistono delle strategie per aggirare il problema.

Cosa fare quando un template newsletter è visualizzato in modo diverso da client diversi: tool per il testing

Quando si costruisce un template HTML per una newsletter, effettuare il test di invio sui propri client di posta differenti è fondamentale per capire se questi interpretano il codice in modo diverso.

Per fare un buon testing sul layout della newsletter si può utilizzare E-mail on Acid, un tool pensato appositamente per testare il layout su tutti i vari dispositivi e i client di posta.

Utilizzando e-mail on acid, però, il messaggio verrà testato sì su ciascun client – anche nella versione trial – ma risulterà inutile testarne la compatibilità sui client in disuso come Outlook 2003 per fare un esempio, in quanto la riduzione del codice HTML utile per una semplicità di sviluppo non andrebbe a generare benefici sui client con uno 0.02% di share.

Un’alternativa a e-mail on acid è OpenDEM, che restituisce una diagnostica dei tag da eliminare per ripristinare la compatibilità con i client. Come viene spiegato nella guida Opendem per inviare newsletter (paragrafo “Newsletter dall’aspetto professionale”), durante la creazione del codice HTML, è la piattaforma stessa a effettuare la verifica di eventuali errori che potrebbero inficiare la riuscita del messaggio.

Il tool, che si può visualizzare nella pagina di creazione di una nuova newsletter sotto la voce di “validator” alla destra dell’editor, è attivo ogni volta che la voce “sorgente” è selezionata e consente la correzione immediata e facile (basta un click) dell’eventuale anomalia riscontrata. É il sistema stesso ad apportare le modifiche necessarie a validare il codice, rendendo il messaggio leggibile e compatibile per la maggior parte dei client di posta.

Massimizzare la compatibilità di una newsletter: tutti gli accorgimenti lato HTML

Per migliorare l’impaginazione di una e-mail HTML rendendola il più compatibile possibile si possono adottare degli accorgimenti:

  • è sempre meglio usare stili css in linea, sebbene i fogli di stile con lo <style> in testa al codice consentano soluzioni grafiche più veloci e adattabili. Il rischio è che il foglio di stile con lo <style> venga inibito da alcuni client invalidando il messaggio;
  • è bene preferire il fondo bianco, perché alcuni client non accettano i colori o le immagini sullo sfondo. Se, ad esempio, lo sfondo nero con testo bianco non viene applicato perché il colore nero viene inibito, si avrà un messaggio illegibile in quanto il testo risulterà bianco su sfondo bianco (bisogna sempre considerare i casi peggiori);
  • utilizzare sfondi chiari è sempre una garanzia, così come un font scuro del testo, in modo da rendere il messaggio sempre leggibile evitando, nel caso peggiore, di inviare un messaggio interamente bianco;
  • evitare di includere script quali JavaScript, ActiveX, Flash, Video, Embedding, Include, Form perché solitamente non funzionano sui principali client;
  • non esagerare con il peso, che dovrà rimanere tra i 50 e i 100 kb;
  • prestare attenzione alla larghezza del messaggio, meglio se compresa tra i 550 e i 600 px, in modo da permetterne la visualizzazione corretta su tutti i client (alcuni web client tagliano le porzioni in eccesso specialmente nella visualizzazione da mobile);
  • utilizzare i codici esadecimali per impostare i colori evitando le stringhe: SI color=”#ffffff” – NO color=”white”;
  • utilizzare esclusivamente i tag di markup XHTML come p, strong, em, li, ul, ecc;
  • utilizzare il tag title=”Nome contenuto” e alt=”descrizione immagine” sia nei tag delle immagini che nel tag dei link. Questi tag mostreranno, al momento del passaggio del mouse sull’immagine o sul link, una piccola descrizione in sovraimpressione che spiegherà il contenuto degli oggetti anche qualora non si attivassero i contenuti remoti;
  • i seguenti tag possono essere inibiti da alcuni client poiché considerati inrilevanti: <body>, </body>, <meta>, <head>, </head>, <base>, <link>, <script>, </script>, <applet>, </applet>, <frameset>, </frameset>, <frame>, </iframe>, </iframe>, <li>, </li>, <!– …commenti… –>;
  • è preferibile usare <table> per la struttura delle tabelle e non gli stili, poiché mal supportati;
  • porre gli attributi dei link, quali name, class, ecc, alla fine del link, ossia dopo HREF;
  • usare nel link il tag target=”_blank” per aprirne il contenuto in una pagina diversa;
  • usare il codice: style=”color: #000001;” nel tag <a> impedisce ai client di modificare il colore del link.

Tali accorgimenti consentono di evitare risvolti penalizzanti nell’invio delle e-mail HTML, poiché un codice validato agevola sempre la corretta visualizzazione del messaggio. Ma questo non è l’unico vantaggio: un codice validato riduce, seppur minimamente, le probabilità che l’e-mail venga inibita dai filtri antispam.

Comments

comments