Xúlio Fernández

Xúlio Fernández

Senior Front end Developer
Related topics: Web Development

Cómo hacer que tu newsletter se visualice correctamente en la mayoría de clientes de correo

7 noviembre 2018
2 min
Cómo hacer que tu newsletter se visualice correctamente en la mayoría de clientes de correo
ZZZ
Si estás familiarizado con el envío de campañas a través de newsletters, sabrás ya que uno de los principales problemas al que siempre nos enfrentamos, es el hecho de conseguir que los emails se visualicen de forma correcta en la mayoría de clientes de correo. Está dificultad surge por la forma en la que los clientes de correo interpretan el HTML y el CSS, que son los dos lenguajes con los que construimos los emails. A diferencia de los navegadores actuales, en los que se ha hecho un gran trabajo de estandarización, los clientes de correo renderizan el HTML, y sobre todo el CSS, de forma muy diferente entre ellos, dejando sin funcionar algunas etiquetas HTML y muchas propiedades CSS. Una vez conocido el heterogéneo contexto tecnológico en el que trabajamos, podemos trazar nuestra estrategia a la hora de diseñar y maquetar emails. Nosotros planteamos una basada en dos puntos fundamentales:

  • Enfoque inicial.
  • Adecuación del código al contexto tecnológico.

Enfoque inicial

Es evidente que una newsletter es un medio muy eficaz a la hora de difundir campañas u otro tipo de información entre nuestros clientes, pero a veces tendemos a tratarla como si se tratase de una página web y esto es un error. Por dos motivos: uno, el hecho ya comentado de la deficiencia a la hora de interpretar el lenguaje HTML/CSS por parte de los diferentes clientes de correo. Otro, que la forma de recibir, abrir, leer, interactuar y cerrar los emails es diferente, mucho más rápida. ¿Y esto cómo influye a la hora enfocar la creación de un email? Quizás una buena forma de resumirlo sea con una frase: “Hazlo simple”.

  • Información breve y concisa.
  • Enlace(s) a la página objetivo de nuestra campaña bien visible.
  • Diseño sencillo: ancho de 600-800 px y grid a una columna (preferiblemente).

De esta forma nos aseguramos de que el usuario va a leer, comprender e interesarse por nuestro mensaje y de que, al evitar una maquetación compleja, la visualización del email sea siempre correcta en la mayoría de clientes de correo.

Adecuación del código al contexto tecnológico

Maquetar de forma correcta un email es un trabajo en el que intervienen infinidad de factores: qué queremos comunicar, cómo lo vamos a diseñar, si tenemos métricas de otras campañas, a qué clientes de correo vamos a enviar nuestra campaña, etc. Pero aun así, existen reglas y recomendaciones que son comunes a todos los emails para newsletters.

Reglas básicas

  • Siempre debemos maquetar con tablas. Desde hace muchos años el uso de tablas en web ha quedado reducido a su función inicial: organizar datos en filas y columnas, pero maquetar un email es como comprar un billete de regreso a 2003… El motivo es sencillo, como hay clientes que no soportan la etiqueta <div> y también hay clientes que no soportan las propiedades float y position , la única forma que tenemos de que nuestra maquetación se mantenga en todos los clientes de correo, es utilizar las tablas como elemento estructural (incluso anidando tablas dentro de tablas para mantener la consistencia de los diferentes elementos de nuestro email)
  • Debemos usar estilos CSS en línea. Esto no significa que no usemos la etiqueta <style type=»text/css»> en el head de nuestro email para incluir estilos, pero como el soporte de ésta por parte de los clientes no es total, declarar estilos en las etiquetas de HTML a través de style=»», es la única forma que tenemos de asegurarnos de que se apliquen correctamente en la mayoría de clientes. Usar una hoja de estilos externa a través de la etiqueta <link> no es buena idea, ya que su soporte en clientes es muy reducido.
  • No podemos usar Javascript. Por un tema de seguridad, la mayoría de clientes de correo bloquean el código de Javascript. Si no hiciesen esto, “los malos” tendrían la posibilidad de inyectar código malicioso en nuestros dispositivos.

Recomendaciones

  • Usa fuentes tipográficas del sistema (Arial, Helvetica, Georgia, Times New Roman, etc.). Esto no significa que no puedes usar fuentes propias, pero si lo haces, que sea teniendo claro que muchos clientes de correo no las van a mostrar e, indicando en tus estilos, cuáles son las fuentes del sistema que marcas como alternativa: font-family: ‘Tu fuente’, Helvetica, Arial, sans-serif;
  • Evita confiar en las imágenes. Como muchos clientes bloquean de entrada las imágenes de un email, no es buena idea dejar en sus manos toda el peso de la comunicación. Para esto podemos:
    • Alternar siempre texto e imagen. Hay empresas que envían newsletters sólo con imágenes, mala idea…
    • No usar una imagen como primer elemento de la newsletter. Así en el caso de que las imágenes estén bloqueadas, el usuario podrá ver de forma rápida sobre qué trata el email.
    • Usar el atributo alt. De esta forma, aunque de inicio no se cargue la imagen, al menos veremos un texto que la describe.
    • Usar piés de imágenes. La idea es la misma que la del punto anterior, pero en este caso al contrario que el alt, que no es soportado por todos los clientes de correo, esta técnica es 100% segura.

Outlook 2007–16

“Outlook 2007-16 is the new IE8 Anónimo. Cualquier historia que se precie debe tener un villano y en esta este papel lo representa el Outlook 2007-2016. Atrás quedan ya los tiempos en los que Internet Explorer 8 (y versiones anteriores) resultaba un dolor de cabeza a la hora de desarrollar páginas webs, pero, quizás como recordatorio de aquella época, en el campo de la maquetación de emails aun tenemos el Outlook 2007-2016. Este cliente es con diferencia el que más problemas de visualización genera y esto se debe fundamentalmente a que usa Word (¡el procesador de texto!) para renderizar el HTML y CSS de los emails, lo que hace que el soporte de muchas propiedades sea nulo. Bueno, realmente no es tan grave si se sabe lidiar con él, pero esto mejor lo dejamos para otro post!