HTML & Email: los 6 errores más comunes al redactar un correo electrónico

Sabemos que gracias al lenguaje HTML y al CSS se puede construir una estructura de correo electrónico y darle forma o, mejor, formato, de manera que aparezca, por ejemplo, un cierto tipo de fuente, un color de fondo específico, imágenes, etc.

Ahora vamos a ver cómo a través de algunos aspectos tanto de las etiquetas HTML como de las CSS se cumple, superponiéndose, la misma función. Pongamos un ejemplo práctico: definiremos en HTML o en CSS el color de fondo de una tabla.

El código se muestra en la imagen. Podrás notar que hay dos puntos en los que se define el color de fondo:

• bgcolor=”#e75c00” es el atributo de la etiqueta table (tabla);
• background-color es el atributo del CSS aplicado a la tabla.

Ambos atributos hacen lo mismo, por lo que se superponen: aplican el color naranja (#e75c00 según el formato hexadecimal) al fondo de la tabla.

Ahora debería estar más claro el punto crítico: el solapamiento de las definiciones de propiedad entre HTML y CSS. A menudo, de hecho, en diversas modificaciones o variaciones de la misma plantilla de correo electrónico puede suceder que el código se sobrecargue de propiedades redundantes que desempeñan la misma función.

Profundicemos. Dado que los estilos inline (en línea) pueden aplicarse a cada elemento individual, también podría presentarse este (retorcido) caso:

Un navegador (o un cliente de correo electrónico) lee el código más o menos de la siguiente manera:

• aplica un fondo gris (bgcolor=»#efefef») a la tabla;
• a continuación, aplica un fondo negro (bgcolor=»#000000″) a la fila;
• por último, aplica un fondo naranja (background-color:#e75c00) a la celda que contiene la frase Hello World!

En este ejemplo y en el anterior, el resultado final es el mismo: letras blancas sobre fondo naranja. El problema es que, en el segundo caso, se definen tres normas diferentes de fondo. La que se muestra al usuario se define en la celda debido a que el navegador lee el código secuencialmente (table -> tr -> td) y, puesto que la última definición se impuso sobre <td>, esta es la que se mostrará.

Es evidente que gran parte del código no es necesario. No solo porque el único color de fondo que se muestra es el que se aplica a la celda, sino también porque uno de los propósitos de un buen marketing por correo electrónico es mantener la comunicación lo más ligera posible. Un código con muchas palabras y redundante no es un código ligero.

• Mantén el código lo más limpio posible;
• Evita repeticiones innecesarias en el formato del código;
• Apuesta por los estilos inline;
• Trata de construir una estructura modular del código de la comunicación;
• Intenta mantener el código lo más ordenado posible, a través del uso de sangrías (hay varios servicios en línea que hacen esto, como HTMLformatter o Clean CSS), para ver de un vistazo la estructura de la comunicación;
• Realiza un seguimiento del historial de los cambios más importantes de una plantilla.

Al igual que en la mayoría de los lenguajes, el HTML también tiene la posibilidad de insertar comentarios. ¿Qué es un comentario en un script HTML? Es una parte del listado que es ignorada por el programa que lee y ejecuta el código.

Podrás notar que todo lo que está entre <!– y –> no solo es de un color diferente (dependiendo del programa de edición), sino que, sobre todo, no se muestra en la pantalla.

Esto permite insertar «comunicaciones de servicio» relativas al código que se ha escrito o indicaciones sobre partes que necesitan completarse o mejorarse.

Además, hay otra manera de utilizar los comentarios. Puesto que todo lo que se encuentra entre el marcador de apertura y el de cierre no se visualiza, con esto se pueden ocultar partes enteras de la página como se muestra en el siguiente ejemplo. De hecho, podrás apreciar que en el vídeo solo se pueden ver tres líneas en lugar de las cuatro que están escritas en el código.

Es útil, por supuesto, pero no debemos abusar de este instrumento: si bien es cierto que el código comentado no se muestra, también hay que tener en cuenta que permanece en la comunicación enviada, haciéndola más pesada.

Nuestro consejo:

• utiliza los comentarios sabiamente: por ejemplo, para indicar el principio y el final de la estructura de la comunicación o para insertar indicaciones útiles para el desarrollador;
• no utilices muchas palabras complejas en los comentarios, mejor aún, escribe en inglés;
• elimina el código comentado antes del envío, siempre que no sea necesario para el propósito de la comunicación.

En la fase de diseño de un correo electrónico, incluso antes de escribir una sola línea de código, es bueno definir algunos parámetros que no se pueden modificar en la siguiente etapa de realización ni, por tanto, en la de producción.

Algunos de estos parámetros son:

• Anchura del correo electrónico
• Tamaño de la imagen
• Número de imágenes
• Tamaño de la fuente utilizada en el encabezado
• Tamaño de la fuente del texto principal.

Un parámetro que a menudo se omite a propósito es el número máximo de líneas de un elemento de texto cualquiera. En este sentido, se podría argumentar que se peca de fanatismo normativo, pero hay dos buenas razones para ser tan rígido. El primero es conceptual, el segundo operativo.

A nivel conceptual, el contenido (texto, imágenes, etc.) y el contenedor (estructura HTML) son dos entidades muy diferenciadas con una jerarquía bien definida en la que el primero está subordinado al segundo.

De hecho, es el contenido el que debe adaptarse al contenedor y no al revés. Al escribir el código se construye la arquitectura de la comunicación y se define el contenedor, el cual, una vez configurado, permanece así con independencia del contenido, incluso en el caso de que el correo electrónico se haya creado para ser receptivo.

Para ser breves, parafraseando a Bruce Lee, el contenido es como el agua: si pones agua en una taza, se convierte en la taza; si pones agua en una botella, se convierte en la botella; si la pones en una tetera, se convierte en la tetera.

No se puede esperar que una taza se convierta en botella, así como una tetera nunca será una taza.
Por tanto, debe ser el texto (o una imagen o un botón) el que se adapte a la estructura que lo contiene y no al revés.

La segunda razón es más operativa. Si conoces de antemano exactamente todos los parámetros que van a componer la comunicación, entonces, en la fase de elaboración, se puede realizar no solo una comunicación más eficaz, sino también una comunicación más equilibrada.

Pongamos un ejemplo más concreto: supongamos que tienes un DEM (mensaje de marketing directo por correo electrónico) con dos productos uno al lado del otro. Por lo general, un producto se asocia con:

• Una imagen
• El nombre del producto
• La descripción del producto
• El precio
• La CTA (llamada a la acción) que lleva a la página del producto

Ahora, dado que los productos van juntos, necesariamente tiene que haber un equilibrio entre las partes. Esto significa que las imágenes deben tener la misma altura, que los textos descriptivos deben tener una longitud similar y que las dos CTA no deben ser demasiado diferentes.

Al ignorar o no respetar estos principios básicos, se puede dar el caso de la imagen de arriba. La simetría entre los dos elementos se rompe porque el título del producto de la izquierda ocupa tres líneas, mientras que el de la derecha ocupa una sola línea. Hay una distonía que acaba debilitando toda la comunicación.

El cumplimiento de estas normas se vuelve aún más importante cuando se tiene en cuenta el ámbito de los teléfonos móviles, donde las resoluciones de los distintos dispositivos son de lo más diversas: desde los 1125 x 2436 píxeles del iPhone X hasta los 1440 x 2960 píxeles del Samsung Galaxy S8, pasando por los 768 x 1280 píxeles del Microsoft Lumia 1020.

Esta enorme heterogeneidad, que se superpone a la ya densa selva de clientes de correo electrónico, no permite tener un control total de la visualización del DEM, ya que no existe un código definitivo que se adapte a todos los píxeles. Por tanto, puesto que no se puede comprobar mediante el código, debemos tratar de hacerlo de manera indirecta, actuando sobre otras partes del correo electrónico, como precisamente la longitud del texto o el tamaño de las imágenes.

Nuestras recomendaciones:

• Define la plantilla en todas sus partes;
• Mantén la coherencia entre los diversos componentes de la comunicación;
• Respeta tus reglas;
• Puedes hacer excepciones a la regla, pero con plena conciencia;
• Si la plantilla no satisface tus necesidades, puedes pensar en definir una nueva.

A veces, especialmente en el pie de página, el titular del correo electrónico añade la información de contacto. Por lo general, hay una dirección y un número de teléfono. Para los clientes de correo electrónico que utilizan un ordenador, el número de teléfono y la dirección pueden ser información estándar, pero para los que usan un teléfono móvil, utilizados en pocas ocasiones, estos elementos son de particular importancia.

Principalmente por dos razones:

• Con un clic se puede abrir una aplicación que gestiona los datos (calendario, teléfono, navegador);
• El espacio de visualización es reducido, por lo que la información, incluso si se coloca en el pie de página, tiene una mayor visibilidad.

Al desarrollar una comunicación, por tanto, también es importante no pasar por alto estos detalles, que se comportan de manera diferente en los diversos dispositivos. Detengámonos en un ejemplo realizado ad hoc mediante una simulación. Ambos ejemplos se muestran a través del iPhone 6+ iOS 9.

La imagen de la izquierda representa el boletín recibido por el usuario con el texto introducido directamente, sin ningún formato.

Desde un punto de vista técnico es del todo correcto, pero hay que tener en cuenta que en el móvil dicho código se interpreta por la aplicación del correo electrónico. Esta «lee» el texto del correo, y cuando reconoce un texto con la forma de una fecha, una dirección o un número de teléfono, conecta automáticamente el enlace activo con las respectivas aplicaciones: Calendario, Mapa, o con el teléfono.

Es todo muy cómodo, ya que con un solo clic se puede hacer una llamada telefónica, añadir un evento al calendario o abrir el mapa para establecer una ruta. Los únicos a los que no complace son el artista y el desarrollador, que no querrán ver el enlace azul ni el subrayado. Entonces, ¿qué hacemos, cómo procedemos?

Se puede acudir a una pequeña salida alternativa (workaround), un truco, para que las cosas vuelvan a la normalidad. Que quede claro: a pesar de que estas salidas alternativas también suponen romper las reglas de un HTML con un bueno formato, son indispensables en el inmenso mar de clientes de correo electrónico. Si el objetivo principal para un desarrollador es que la comunicación sea visible para el máximo de clientes posible, entonces debe hacer concesiones y recurrir a las salidas alternativas.

Vamos a ver cómo se ha intervenido en el código

En cuanto a lo que respecta al teléfono es simple: dado que la etiqueta de anclaje permite definir también un número de teléfono mediante tel en la propiedad href, vamos a añadir el número de teléfono sin espacios ni líneas de separación.

Para la dirección o la fecha, sin embargo, debemos proceder de manera diferente: es necesario definir una clase (.address) que obligue a la etiqueta de anclaje a insertar automáticamente el cliente y el color (color:#ffffff;) y, sobre todo, a eliminar el subrayado, el cual es una característica por defecto de cada enlace (text-decoration:none;).

Hay que tener en cuenta que ambos atributos de la clase address tienen !important, lo que obliga al cliente a aplicarlos con independencia de la propiedad. Sin esto, las salidas alternativas podrían no funcionar.

Nuestras recomendaciones:

• Presta siempre atención a cómo se podría visualizar la comunicación desde el móvil (es decir, haz la prueba);
• Cuando sea posible, haz pequeños ajustes para convertir la comunicación en apta para móviles;
• No asumas que lo que va bien para un ordenador también funciona con un móvil;
• Conoce a tu público: ¿qué tecnología utiliza? ¿Qué dispositivo? ¿Qué soportes?;
• Experimenta también tus comunicaciones con pruebas internas, especialmente cuando haya actualizaciones sustanciales de la aplicación del cliente de correo electrónico.

Siempre con el objetivo de tratar de mantener la comunicación con el mínimo peso total, debemos prestar atención a aquellas partes del código existente que vaciamos de su contenido natural.

Pongamos un ejemplo concreto: una etiqueta <font>, quizás con una serie de estilos inline, que no contiene texto alguno. Obviamente en el correo electrónico no se puede leer nada, pero las etiquetas de formato <font> continúan ocupando espacio físico en el correo.

Otro ejemplo típico es la etiqueta de anclaje <a> que no tiene ningún objeto vinculado, algo como: <a href=”http://www.miosito.com” style=”color:#00000;text-decoration:none”></a>.

Por lo general, estos «errores» están presentes en el código que se ha alterado o utilizado muchas veces para diferentes componentes como imágenes, enlaces y textos que se han insertado, modificado o eliminado.

O también pueden ser señal de que se ha utilizado de manera incorrecta un editor WYSIWYG. Estos editores, de hecho, si se usan mal o con poca cautela tienen el defecto de añadir código al código, debido a que cada elemento predefinido normalmente tiene una parte del código definida en el momento de la realización por el propio editor.

El programa aplica la plantilla a ciegas cada vez que se introduce el elemento seleccionado, lo que puede originar este problema al editar un número suficiente de veces la misma parte del correo electrónico.

Nuestro consejo:

• Cuando se escribe el código, comprueba siempre que no hay etiquetas abandonadas o vacías;
• Si utilizas un editor WYSIWYG y se puede acceder al código, comprueba que todo está en orden y que no hay errores como estos.

Hablar de la validación del código de un correo electrónico es un tema espinoso. Con respecto al código, en el mundo del marketing por correo electrónico tenemos:

• Por un lado el HTML, es decir, un lenguaje estandarizado con normas y estructuras muy definidas
• Por el otro, una serie de salidas alternativas que no están estandarizadas, a menudo obsoletas, pero que funcionan bien para conseguir una visualización correcta por parte del cliente de correo electrónico.

Ya hemos tropezado con una de estas salidas alternativas en el tercer párrafo, cuando hablamos acerca de los números de teléfono y las direcciones.

Estos dos aspectos son como un viejo matrimonio en el que la pasión se acabó hace tiempo: no saben bien porqué conviven juntos, pero se ven obligados a hacerlo mediante concesiones. Entonces ¿por qué hablar de la validación del código? ¿Tiene sentido? ¿Cuáles son las concesiones?

Tiene sentido hablar de la validación del código cuando se plantea en una perspectiva más amplia, sin entrar en demasiados detalles. Así, desde un enfoque de la estructura, los módulos que componen el correo y las tablas que conforman la columna vertebral de la comunicación, tiene mucho sentido tener un código lo más limpio y cercano posible a las normas dictadas por el W3C.

El W3C como guardián y garante del código viene en nuestra ayuda al proporcionarnos una herramienta de validación del código cuyo análisis señala los errores y sugiere sus correcciones. Con esta herramienta, se pueden detectar y corregir los errores de estructura más grandes.

Pero hay que tomar nota de la realidad, y aquí el compromiso consiste en construir una estructura sólida y funcional a la que se van a añadir las salidas alternativas en una especie de puesta a punto para extender una correcta visualización al máximo posible de clientes.

Ya sabemos que las salidas alternativas no son más que excepciones a la regla o técnicas no perfectamente ortodoxas, que nacen de conocimientos acumulados con la experiencia, pero existen porque permiten que el código se muestre correctamente, sin cambios en su formato.

Nuestros consejos:

• Si tienes dudas sobre el código, la validación puede ser una buena herramienta de análisis rápida;
• La validación del código puede ser un buen instrumento para identificar rápidamente los errores más grandes de un listado de código;
• Un código validado es siempre un buen punto de partida para continuar con la evolución y la adaptación de la comunicación mediante salidas alternativas para hacerla más universal.
• La validación puede verse como la «brecha» del código, sobre todo en modelos manipulados y modificados a menudo;
• Constrúyete, con la acumulación de experiencia, una pequeña biblioteca de soluciones a medida para los diferentes clientes con el fin de ahorrar tiempo en la resolución de problemas.