HTML y correo electrónico: 6 errores comunes que debe evitar

¿Creando correo electrónico con código HTML? Aquí hay 6 errores demasiado frecuentes que debe evitar para aprovechar los beneficios de las comunicaciones por correo electrónico optimizadas y limpias.

Error 1. Usar código demasiado detallado

Sabemos que gracias a HTML y CSS podemos construir una estructura de correo electrónico y darle una forma, o más bien un formato, que permita mostrar un determinado tipo de fuente, un color de fondo específico, imágenes, etc.

Ahora veremos cómo las etiquetas HTML y CSS llevan a cabo la misma función en algunos aspectos y terminan superponiéndose. Tomemos un ejemplo práctico: definir el color de fondo de una tabla tanto en HTML como en CSS.

El código se muestra en la imagen. Puedes ver que hay dos puntos donde se define el color de fondo:

• bgcolor = “# e75c00” es el atributo de la tabla de etiquetas;
• background-color es el atributo CSS aplicado a la tabla.

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

El punto crítico ahora debería estar más claro: las definiciones de propiedades HTML y CSS pueden apilarse unas sobre otras. De hecho, al reelaborar o variar el mismo modelo de correo electrónico, el código a menudo puede atascarse con propiedades redundantes que realizan la misma función.

Y eso no es todo. Dado que los estilos en línea se pueden aplicar a cada elemento, este caso (perverso) también puede ocurrir:

Un navegador (o cliente de correo electrónico) leería el código más o menos así:

• Aplicar un fondo gris ( bgcolor = “#efefef” ) a la mesa
• Diez aplican un fondo negro ( bgcolor = "# 000000" ) a la fila
• Finalmente, aplique un fondo naranja ( color de fondo: # e75c00 ) a la celda que contiene el texto ¡Hola mundo!

El resultado final es idéntico tanto en este ejemplo como en el anterior: texto blanco sobre fondo naranja.

El problema es que se han definido tres reglas de fondo diferentes en el segundo caso. El que ve el usuario es el definido en relación a la celda, porque el navegador lee el código secuencialmente (tabla -> tr -> td). Dado que la última definición se estableció en <td> , eso es precisamente lo que se mostrará.

Está claro que gran parte del código no es necesario. Esto no solo se debe a que el único color de fondo que se muestra es el que se aplica a la celda, sino también a que uno de los objetivos del buen marketing por correo electrónico es mantener las comunicaciones lo más claras posible. El código redundante y muy detallado no es un código ligero.

Nuestras recomendaciones:

• Mantenga el código lo más limpio posible
• Evite repeticiones innecesarias al formatear el código
• Dar preferencia a los estilos en línea
• Intente construir una estructura modular para el código de comunicación.
• Intenta mantener el código lo más ordenado posible mediante sangría (hay varios servicios online que hacen esto, como HTMLformatter o Clean CSS), para poder tener una visión general de la estructura de la comunicación.
• Realice un seguimiento del historial de cambios macro realizados en un modelo

Error 2. Comentar excesivamente el código

Como ocurre con la mayoría de los lenguajes, también es posible agregar comentarios a HTML. ¿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.

En la figura siguiente se ofrece un ejemplo de comentario:

Como puede ver, todo entre <! - y -> no solo es de un color diferente (dependiendo del programa de edición), lo que es más significativo, no se muestra en la pantalla.

Esto permite insertar “comunicaciones de servicio” sobre el código que se ha escrito, o instrucciones para partes que aún no se han completado o que necesitan mejorarse.

También hay otra forma de utilizar los comentarios. Dado que no se muestra todo lo que se incluye entre los marcadores de apertura y cierre, es posible ocultar partes enteras de la página con él, como se muestra en el siguiente ejemplo. De hecho, podemos ver que solo tres líneas son visibles en la pantalla en lugar de las cuatro que están escritas en el código.

Es una herramienta útil, por supuesto, pero no debemos abusar de ella. Si bien es cierto que el código comentado no se muestra, sin embargo permanece en la comunicación enviada, poniéndole peso.

Nuestro consejo:

• Utilice los comentarios de forma inteligente, por ejemplo, para indicar el comienzo y el final de las estructuras de comunicación, o para insertar información útil para el desarrollador.
• No seas prolijo en los comentarios y, mejor aún, escríbelos en inglés
• Eliminar el código comentado antes de enviarlo, ya que no es necesario para fines de comunicación.

Error 3. Gestión incorrecta del contenido del correo electrónico

Al diseñar un correo electrónico, incluso antes de escribir una sola línea de código, es bueno definir ciertos parámetros que no se pueden modificar en la siguiente fase de realización y, en consecuencia, durante la producción.

Algunos de estos parámetros incluyen:

• Ancho de correo electrónico
• Tamaño de la imagen
• Numero de imagenes
• Tamaño de fuente utilizado en el encabezado
• Tamaño de fuente del texto del cuerpo

Etcétera. Un parámetro que a menudo se omite es el del número máximo de pulsaciones de tecla para cualquier elemento de texto.

En este punto, podría objetar que somos culpables de ser fanáticos con las reglas, pero hay dos buenas razones para ser tan estrictos. El primero es conceptual y el segundo operativo.

A nivel conceptual, el contenido (texto, imágenes, etc.) y el contenedor (estructura HTML) son dos entidades separadas con una jerarquía muy precisa que ve al primero subordinado al segundo.

De hecho, el contenido debe adaptarse al contenedor y no al revés. La arquitectura de la comunicación se construye al escribir el código. Esto define el contenedor y, una vez configurado, el contenedor permanece así independientemente del contenido, incluso si el correo electrónico se ha creado para responder.

En resumen, y 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 pones agua en una tetera, se convierte en tetera.

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

La segunda razón es más operativa. Si todos los parámetros para redactar la comunicación se conocen exactamente a priori, entonces no solo es posible crear comunicaciones más efectivas durante la fase de redacción, sino también comunicaciones más equilibradas.

Tomemos un ejemplo más concreto: supongamos que tenemos un DEM con dos productos uno al lado del otro. Un producto suele estar asociado con:

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

Ahora, dado que los productos están uno al lado del otro, las partes deben necesariamente estar equilibradas.

Esto significa que las imágenes deben tener la misma altura, los textos descriptivos deben tener una longitud similar y los dos CTA no deben ser muy diferentes.

Ignorar o no respetar estos principios básicos puede llevar a casos como el de la imagen de arriba.

La simetría entre los dos elementos se rompe porque el título del producto de la izquierda es tan largo que cubre tres líneas, mientras que el de la derecha es tan corto que solo llena una línea. Se ha introducido una discordia, que finalmente debilita toda la comunicación.

El cumplimiento de estas reglas se vuelve aún más importante cuando se piensa en el mundo móvil, donde todos los distintos dispositivos tienen resoluciones muy dispares: desde los 1125 x 2436 px del iPhone X hasta los 1440 x 2960 px del Samsung Galaxy S8, pasando por el 768 x 1280 px del Microsoft Lumia 1020.

Cuando esta enorme diversidad se superpone con la densa jungla de clientes de correo electrónico, significa que no tenemos el control total de la pantalla DEM, porque no existe un código definitivo que se adapte a los píxeles en todos los casos. Entonces, si no puedes controlarlo mediante código debes intentar hacerlo de forma indirecta, alterando las otras partes que componen un correo electrónico, como la longitud de los textos o el tamaño de las imágenes.

Nuestras recomendaciones:

• Definir todas las partes de la plantilla.
• Mantente constante entre las diferentes partes de la comunicación.
• Respeta las reglas que te has dado a ti mismo
• Las reglas se pueden romper, pero esto debe hacerse con plena conciencia.
• Si la plantilla no se ajusta a sus necesidades, puede empezar a pensar en definir una nueva.

Error 4. Obtener direcciones y números de teléfono interactivos incorrectos

A veces, los remitentes de correo electrónico agregan su información de contacto, especialmente en el pie de página. Esto generalmente incluye una dirección y un número de teléfono.

Si bien un número de teléfono y una dirección pueden ser información estándar para los correos electrónicos de los clientes de escritorio, aunque rara vez se usan, estos elementos son particularmente importantes cuando se trata del lado móvil.

Esto ocurre principalmente por dos razones:

• Puede abrir una aplicación que gestiona los datos con un clic (calendario, teléfono, navegador)
• El espacio de visualización se reduce y, como tal, cada pieza de información tiene una mayor visibilidad, incluso si se encuentra en el pie de página.

Por tanto, es importante no olvidar también estos detalles a la hora de desarrollar la comunicación, ya que su comportamiento varía entre los diferentes dispositivos.

Tomemos un momento para considerar un ejemplo creado ad hoc a través de una simulación. Ambos ejemplos se muestran en iPhone 6+ iOS 9.

La imagen de la izquierda muestra la newsletter recibida por el usuario con el texto introducido directamente, sin ningún formato.

Todo es correcto desde el punto de vista técnico, pero hay que tener en cuenta que el código es interpretado por la propia aplicación de correo electrónico en el móvil. “Lee” el texto del correo electrónico y cuando reconoce el texto en forma de fecha, dirección o número de teléfono, vincula automáticamente el enlace activo a la aplicación respectiva, es decir, el Calendario, el Mapa o el teléfono.

Todo esto es muy conveniente, ya que un solo clic le permite hacer una llamada telefónica, programar un evento o abrir el mapa para establecer una ruta. Los únicos que pueden estar tristes son el arte y el desarrollador, a quienes no les gusta ver los enlaces azules y el subrayado. ¿Entonces, qué debemos hacer? ¿Cómo debemos proceder?

Puede utilizar una pequeña solución alternativa o un truco para que las cosas vuelvan a la normalidad. Seamos claros: aunque rompen las reglas del HTML bien formateado, las soluciones alternativas son indispensables en el vasto océano de clientes de correo electrónico.

Si el objetivo principal de un desarrollador es hacer que la comunicación sea visible en tantos clientes como sea posible, entonces debe comprometerse y adoptar las soluciones.

Así que veamos cómo se modificó el código.

Cuando se trata del teléfono, es simple: dado que la etiqueta de anclaje permite definir un número de teléfono usando tel en la propiedad href , agregamos el número de teléfono sin espacios ni líneas de separación.

Sin embargo, debemos actuar de una manera diferente para una dirección o fecha. Para estos, es necesario definir una clase (.address) que imponga la etiqueta de anclaje que insertará automáticamente el color dentro del cliente (color: #ffffff;). Sobre todo, debería eliminar el subrayado, que es una característica predeterminada de cada enlace (text-decoration: none;).

Tenga en cuenta que ambos atributos de la clase de dirección tienen ! Important , que debe ser aplicado por el cliente independientemente de la propiedad. Sin él, no hay garantía de que la solución alternativa funcione.

Nuestras recomendaciones:

• Siempre preste atención a cómo se puede mostrar la comunicación en los móviles (es decir, haciendo pruebas)
• Siempre que sea posible, utilice micro-arreglos para que las comunicaciones sean amigables con los dispositivos móviles.
• No asuma que lo que es bueno para el escritorio también lo es para el móvil.
• Conoce a tu audiencia: ¿qué tecnología utilizan? ¿Qué dispositivos? ¿Qué medios?
• Utilice pruebas internas para experimentar con sus propias comunicaciones, especialmente cuando hay actualizaciones sustanciales en las aplicaciones de los clientes de correo electrónico.

Error 5. No limpiar etiquetas vacías o abandonadas

Continuando con el objetivo de intentar mantener al mínimo el peso general de la comunicación, debemos prestar atención a las partes del código existente que se han vaciado de su contenido natural.

Demos un ejemplo concreto de inmediato: una etiqueta <font> , quizás con una serie de estilos en línea, que no contiene ningún texto. Obviamente, el lado del correo electrónico no podrá leer nada, pero la etiqueta de formato <font> continúa existiendo y ocupando espacio físico en el correo electrónico.

Otro ejemplo clásico son las <a> etiquetas de anclaje que no tienen ningún objeto vinculado, así que algo como: <a href=”http://www.mailup.com” style=”color:#00000;text-decoration:none”> </a>.

Por lo general, estos “errores” están presentes en ese código que ha sido reelaborado o utilizado muchas veces, por lo que se han insertado, modificado o eliminado diferentes partes, como imágenes, enlaces y textos. Alternativamente, podría ser una indicación de un uso incorrecto de un editor WYSIWYG. De hecho, si se usan mal o imprudentemente, estos editores tienen el defecto de agregar código al código, ya que cada elemento predefinido normalmente tiene una parte del código definida desde el momento en que se creó el propio editor.

El programa aplica el modelo de forma acrítica cada vez que se inserta el elemento seleccionado y, como resultado, este problema puede surgir cuando reescribe la misma parte del correo electrónico una cantidad suficiente de veces.

Nuestro consejo:

• Al escribir el código, siempre verifique que no haya etiquetas abandonadas o vacías
• Si utiliza un editor WYSIWYG y es posible acceder al código, realice una verificación para asegurarse de que todo esté en orden y que no haya ninguno de estos tipos de errores.

Error 6. Uso de HTML no validado

Hablar de la validación del código de correo electrónico es un tema espinoso.

“La mayoría de las páginas de la World Wide Web están escritas en lenguajes informáticos (como HTML) que permiten a los autores de la Web estructurar texto, agregar contenido multimedia y especificar qué apariencia o estilo debe tener el resultado.

Como para todos los idiomas, estos tienen su propia gramática , vocabulario y sintaxis , y se supone que cada documento escrito con estos lenguajes de computadora debe seguir estas reglas. Los lenguajes (X) HTML, para todas las versiones hasta XHTML 1.1, utilizan gramáticas legibles por máquina llamadas DTD, un mecanismo heredado de SGML.

Sin embargo, así como los textos en un lenguaje natural pueden incluir errores ortográficos o gramaticales, los documentos que utilizan lenguajes de marcado pueden (por varias razones) no seguir estas reglas. El proceso de verificar si un documento sigue realmente las reglas para el idioma (s) que usa se llama validación , y la herramienta utilizada para eso es un validador. Un documento que supera este proceso con éxito se denomina válido .

Con estos conceptos en mente, podemos definir la “validación de marcado” como el proceso de comparar un documento web con la gramática (generalmente una DTD) que afirma estar usando ”.

Definición W3C

W3C nos ayuda como guardián y garante del código al proporcionar una herramienta de validación de código cuyo análisis indica errores y sugiere formas de corregirlos. Gracias a esta herramienta, es posible identificar y corregir errores estructurales mayores.

Vale la pena recordar que el marketing por correo electrónico tiene una doble situación:

• Por un lado, HTML es un lenguaje estandarizado con reglas y estructuras muy precisas
• Por otro lado, una serie de soluciones que no son estándar y que a menudo están mal vistas, pero que funcionan bien si desea tener una visualización correcta en los clientes de correo electrónico.

Estos dos aspectos son como una vieja pareja casada, donde la pasión hace tiempo que se desvaneció. No saben por qué viven juntos, pero se ven obligados a hacerlo mediante compromisos.

Entonces, ¿por qué hablar de validación de código? ¿Tiene sentido? ¿Cuáles son los compromisos?

Tiene sentido hablar de validación de código cuando se coloca en una perspectiva más amplia, sin ir demasiado lejos en los detalles. Por lo tanto, cuando se trata de la estructura, los módulos a partir de los cuales se compone el correo electrónico y las tablas que constituyen la columna vertebral de la comunicación, tiene mucho sentido tener un código tan limpio y cercano al estándar dictado por el W3C. como sea posible.

Sin embargo, tenemos que ser conscientes de la realidad, por lo que el compromiso consiste en la creación de una estructura sólida y funcional, a la que se añaden las soluciones como una especie de puesta a punto para extender la visualización correcta al mayor número de clientes posible.

Ya sabemos que las soluciones provisionales no son más que excepciones a la regla, o técnicas no perfectamente ortodoxas, derivadas del conocimiento acumulado a través de la experiencia, pero su existencia solo tiene sentido porque permiten visualizar correctamente el código, sin ninguna depaginación.

Nuestro consejo:

• Si tiene dudas sobre el código, la validación puede servir como una herramienta de análisis rápida y eficaz
• La validación de código puede ser una buena herramienta para identificar rápidamente los errores más grandes en una lista de códigos.
• El código validado es siempre un excelente punto de partida para la posterior evolución y adaptación de la comunicación con soluciones alternativas, para que sea lo más universal posible.
• La validación puede verse como un "servicio" para el código, especialmente en modelos que se han manipulado y reelaborado con frecuencia.
• A medida que gane experiencia, cree una pequeña biblioteca de soluciones ad hoc para varios clientes con el fin de ahorrar tiempo en la resolución de problemas.