Elección de un marco de correo electrónico responsivo: MJML frente a Foundation for Emails

Implementar un diseño de correo electrónico responsivo puede resultar un poco complicado. Crear correos electrónicos responsivos no es nada sencillo, es como viajar en una máquina del tiempo en el año 2001, cuando todos estábamos codificando diseños de sitios web en tablas usando Dreamweaver y Fireworks.

¡Pero hay esperanza! Tenemos herramientas disponibles que pueden hacer que la creación de correo electrónico sea mucho más fácil y más parecida a la codificación de un sitio moderno. Echemos un vistazo a un par de marcos diferentes que pretenden simplificarnos las cosas.

Primero, la situación

Tienes que ser compatible con muchos clientes de correo electrónico antiguos, muchos de los cuales ni siquiera son compatibles con los estándares web más básicos (¿alguien flota?). También tiene que lidiar con todo tipo de clientes de correo web que, por razones técnicas o de seguridad, han tomado sus propias decisiones sobre cómo mostrar su valioso correo electrónico.

Además, ahora los correos electrónicos se leen desde diferentes dispositivos, con ventanas de visualización y requisitos muy diferentes.

La mejor solución, como suele ser el caso, sería mantener las cosas simples y ceñirse a diseños básicos de una columna, usando múltiples columnas solo para menús o elementos de interfaz simples de ancho conocido. Después de todo, puedes producir diseños fantásticos y eficaces utilizando una sola columna.

Sin embargo, los usuarios finales y los clientes, que están acostumbrados a la web “normal” basada en navegador, pueden mantener su experiencia de visualización de correo electrónico con los mismos altos estándares que mantienen para ver páginas web en términos de gráficos y capacidad de respuesta. Por lo tanto, se esperan diseños complejos: múltiples columnas, diferentes comportamientos en dispositivos móviles en comparación con computadoras de escritorio, muchas imágenes, etc., todo lo cual debe implementarse de manera consistente y con píxeles perfectos en todos los clientes de correo electrónico. ¿Qué opciones están disponibles para que todo eso suceda?

Opción 1: construir desde cero

Una opción que puedes elegir es codificar cada correo electrónico a mano, mantenerlo simple y probarlo sobre la marcha. Esta es una opción viable sólo si:

1. Tienes un diseño muy sencillo de implementar.
2. Tienes control directo del diseño, por lo que eventualmente puedes simplificar las cosas si no puedes encontrar una solución consistente para lo que pretendías hacer.
3. Puedes aceptar cierto grado de degradación en algunos clientes más antiguos: no te importa si tu correo electrónico no se verá exactamente igual (o incluso simplemente mal) en clientes Outlook antiguos, por ejemplo.
4. Tienes mucho tiempo libre.

Obviamente, necesitas probar mucho tu diseño. Campaign Monitor tiene una excelente guía de CSS a la que puede consultar durante el proceso de compilación y es algo así como ¿Puedo usarla, pero para correo electrónico? Después de eso, recomiendo utilizar conjuntos de pruebas automatizadas como Litmus o Email on Acid. Ambos le ofrecen un conjunto de pruebas completas y vistas previas de cómo se verá su correo electrónico en una gran variedad de clientes de correo electrónico. Sin embargo, espere algunas sorpresas, porque a menudo el mismo diseño no se ve correcto incluso en el mismo cliente de correo electrónico, si se ve en diferentes navegadores o sistemas operativos diferentes. Las fuentes se representarán de forma diferente, los márgenes cambiarán, etc.

Opción 2: utilizar una plantilla repetitiva

Otra opción es utilizar uno de los diversos textos estándar disponibles, como el de Sean Powelll, que puedes encontrar aquí. Los textos estándar ya abordan muchas de las peculiaridades de los diferentes clientes y plataformas de correo electrónico. Esto tiene sentido si:

1. Estás trabajando solo o en un equipo pequeño.
2. Tienes mucha experiencia, por lo que ya conoces la mayoría de las peculiaridades del formato del correo electrónico porque las conoces antes.
3. Ha configurado sus propias herramientas para administrar componentes (para diferentes boletines que comparten algunas piezas de diseño), incorporar estilos (y sí, debe seguir incorporando sus estilos si sus correos electrónicos se dirigen a una audiencia internacional) y tiene algún tipo de kit de herramientas de desarrollo. en su lugar (ya sea Gulp, Grunt o algo similar) que automatizará todo eso por usted.
4. Tiene el tipo de enfoque en el que le gustaría controlar todo el código que produce y no le gusta depender de herramientas externas.
5. Prefiere solucionar tus propios errores en lugar de tener que solucionar posibles errores provocados por la herramienta que estás utilizando.

Opción 3: utilizar un marco

Sin embargo, si alguno de los siguientes puntos es válido para usted:

1. Tienes que producir muchas plantillas de correo electrónico con componentes compartidos.
2. El trabajo debe ser realizado por un equipo de desarrolladores, que pueden cambiar y/o tener un grado variable de competencia y experiencia con la implementación del correo electrónico.
3. Tienes poco o ningún control sobre el diseño original.

…entonces probablemente se beneficiará mucho del uso de un marco.

Actualmente, dos de los frameworks más interesantes y populares disponibles son MJML y Foundation for Emails. La mayor ventaja de utilizar cualquiera de los marcos es que ya han resuelto la mayoría de las peculiaridades de los clientes de correo electrónico. También le proporcionará un flujo de trabajo establecido que puede seguir, tanto solo como en equipo. También manejan muy bien el diseño responsivo, aunque de manera diferente entre sí.

Veamos una descripción general de ambos marcos y comparamos los mejores casos de uso para cada uno antes de sacar algunas conclusiones.

MJML

MJML es un proyecto que fue creado internamente por Mailjet, empresa especializada en herramientas de email marketing. Luego fue de código abierto. Funciona con su propio lenguaje de plantillas personalizado, similar a HTML, utilizando sus propias etiquetas. Por ejemplo:

mj-textYour text here/mj-text

Cuando compila el código final, MJML convierte sus etiquetas en HTML para todo, desde tablas hasta componentes personalizados que han creado para ti, todo utilizando su motor interno. Elimina el trabajo pesado de crear marcas complejas y todo ha sido probado.

MJML tiene un conjunto de componentes estándar. Incluyen secciones, columnas, grupos, botones, imágenes, enlaces sociales (que son muy fáciles de crear), tablas, acordeones, etc. Incluso incluyen un carrusel prediseñado, que debería funcionar en la mayoría de los clientes. Todos estos componentes se traducen bien en correos electrónicos responsivos, excepto el componente de “factura” que no pude hacer funcionar en mis pruebas. Todos estos componentes tienen parámetros que pueden pasar en su código para personalizar su apariencia.

Por ejemplo, el componente de enlaces sociales le permite apilar íconos vertical y horizontalmente y elegir colores de fondo para los íconos relacionados. En realidad, hay muchos más parámetros con los que puedes jugar, todos con la intención de permitir una mayor flexibilidad. Incluso los archivos de imagen del logotipo ya están incluidos en el paquete, lo cual es una gran ventaja.

Aquí hay una vista previa de una configuración simple del componente de enlaces sociales:

También puedes crear tus propios componentes personalizados o utilizar componentes creados por la comunidad. Sin embargo, por el momento sólo hay un componente comunitario disponible.

MJML maneja la capacidad de respuesta automáticamente, lo que significa que los componentes cambiarán de varias columnas (más elementos en la misma fila) a una sola columna (los elementos se colocan uno debajo del otro en lugar de uno al lado del otro) sin ninguna intervención activa por parte del desarrollador. Esta es una solución muy flexible y funciona bien en la mayoría de los casos, pero le da al desarrollador un poco menos de control sobre lo que sucede exactamente en la plantilla. Como mencionan los documentos, vale la pena tener en cuenta que:

Por motivos estéticos, MJML actualmente admite un máximo de 4 columnas por sección.

Lo más probable es que esto no se deba sólo a una preferencia estética, sino también a limitar los posibles inconvenientes de tener demasiadas columnas. Supongo que cuantas más columnas tengas, más impredecible será el resultado.

Cómo trabajar con MJML

MJML puede funcionar como una herramienta de línea de comandos, que puedes instalar con npm y generar tus archivos localmente, con comandos como:

$ mjml -r index.mjml -o index.html

Esto se puede integrar en su procedimiento de compilación a través de Gulp o similar, y en su trabajo de desarrollo usando un comando de vigilancia, que actualizará su vista previa cada vez que guarde:

$ mjml --watch index.mjml -o index.html

MJML tiene complementos para Atom y Sublime Text. En Atom, incluso proporciona una vista previa en tiempo real de su diseño, que se puede regenerar cada vez que se guarda. No lo he probado personalmente, pero parece muy interesante:

MJML también tiene su propia aplicación de escritorio sencilla y es gratuita. Puede configurar su código y componentes, hacer que cree sus diseños por usted y obtener una vista previa en tiempo real de los resultados, tanto para dispositivos móviles como para computadoras de escritorio. Creo que funciona bastante bien en Ubuntu, pero el único inconveniente que encontré es que nunca, nunca, nunca debes abrir tus archivos con otro editor mientras están abiertos en la aplicación, porque la aplicación falla y el contenido del archivo se pierde.

Aquí hay algunas capturas de pantalla de las vistas previas en funcionamiento:

La aplicación también se puede integrar con una cuenta gratuita de Mailjet, lo que le permite enviar correos electrónicos de prueba inmediatamente. Esto es muy útil para comprobar rápidamente los clientes problemáticos si los tiene disponibles directamente. (Sugeriría sacar esa vieja máquina con Windows que tiene en el almacén para verificar cosas en Outlook y hacerlo con la mayor frecuencia posible). Sin embargo, aún así recomendaría utilizar Litmus o Email on Acid para probar sus correos electrónicos. -cliente antes de implementarlos porque nunca se es demasiado cuidadoso y los estándares de correo electrónico pueden cambiar tal como lo hacen en los navegadores.

En general, MJML me parece muy fácil de usar. Sin embargo, cuando intenté crear una plantilla con píxeles perfectos que fuera idéntico al diseño que nuestro cliente solicitó, tuve algunas dificultades con los márgenes personalizados para algunas imágenes. No todos los parámetros de los componentes disponibles funcionaron como se esperaba según su descripción en la documentación. En particular, tuve algunos problemas para personalizar los márgenes de las imágenes y el relleno entre el escritorio y el móvil.

Ventaja

• Componentes prediseñados
• Integración con Mailjet
• Fácil de usar, con vista previa instantánea de su trabajo (en Atom y la aplicación de escritorio)

Desventajas

• Un poco menos confiable que Foundation for Emails si tienes que hacer diseños con píxeles perfectos
• Algunos componentes tienen parámetros que no funcionan como se esperaba
• La aplicación de escritorio no es perfectamente estable.
• No viene con un conjunto estructurado de carpetas para su contenido (consulte la Fundación a continuación)

Fundación para correos electrónicos

Foundation for Emails (antes conocido como Ink —inserte aquí la cita obligatoria de Prince) es un marco de Zurb, la misma gente que nos trajo el marco de interfaz de usuario responsivo, Foundation for Sites.

Cuando descarga el Starter Kit, obtiene un entorno de desarrollo completo, completo con comandos de Node.js para ejecutar su proyecto. Configurará una rutina de Nodo e incluso abrirá su navegador para brindarle una vista previa inmediata de su trabajo.

Los archivos que tienes que utilizar ya están organizados en carpetas y subcarpetas, con una indicación clara de dónde poner tus cosas. Por ejemplo, tiene directorios específicos para parciales, plantillas e imágenes. Esta característica me parece muy importante, porque es muy fácil terminar usando carpetas diferentes cuando trabajas en equipo, y esto lleva a perder mucho tiempo buscando cosas que no están donde esperas que estén. Hacer cumplir las convenciones no es una limitación; cuando trabajas en equipo es indispensable.

Foundation for Emails viene con una plantilla repetitiva, que es el punto de partida para su código. Está completamente anotado, por lo que sabes cómo ampliarlo con tu código. Viene con soporte SASS/SCSS, lo cual es muy útil para proyectos complejos. También viene con su propio inserto, por lo que no tienes que preocuparte por convertir todo tu CSS (o SASS/SCSS) en estilos en línea.

Detrás de este framework hay un motor de plantillas llamado Inky. Y, al igual que MJML, tiene etiquetas personalizadas que se convertirán automáticamente a HTML cuando se compile. Hay etiquetas como container, row, column, que se utilizarán para crear la cuadrícula. La cuadrícula se basa en un sistema de 12 columnas, que permite subdividir el diseño con mucha precisión. ¿Por qué 12? Porque es divisible por 2, 3, 4 y 6, lo que hace que sea muy fácil crear un diseño de 2, 3, 4 o 6 columnas.

Foundation for Emails utiliza Panini para compilar el código. Panini es una biblioteca personalizada que compila páginas HTML utilizando diseños. Admite la sintaxis Handlebars y hay varios asistentes que puedes utilizar para personalizar el comportamiento de los componentes según dónde se utilicen. También puedes crear tus propios asistentes si lo necesitas y configurar las variables personalizadas de cada plantilla con datos personalizados. Esto es muy útil si tienes varias plantillas que comparten los mismos componentes.

Hay varias plantillas de correo electrónico prediseñadas que puedes descargar y que cubren muchos de los casos de uso estándar del correo electrónico, como boletines informativos y anuncios. También hay algunos componentes prediseñados (con sus propias etiquetas personalizadas), incluidos botones, menús y llamadas (que, debo admitir, no veo un propósito para los correos electrónicos, pero no importa).

La principal diferencia entre Foundation for Emails y MJML es que Foundation for Emails tiene como opción predeterminada la vista de escritorio y luego se adapta a pantallas más pequeñas. Según los documentos, esto se debe a que muchos clientes de escritorio no admiten consultas de medios y la opción predeterminada de diseño de pantalla grande lo hace más compatible con todos los clientes de correo electrónico. Dicho esto, solo administra un punto de interrupción. Crea la versión de escritorio y la versión móvil, y la versión móvil cambia según una determinada cantidad de píxeles, que se puede configurar.

Puedes decidir si algunos componentes serán visibles solo en pantallas grandes o pequeñas mediante prácticas clases predefinidas como .hide-for-largey .show-for-large(aunque .hide-for-largees posible que no sean compatibles con todos los clientes). También puedes decidir cuánto espacio ocupará una columna mediante el uso de clases específicas. Por ejemplo, una clase de .large-6y .small-12en un div creará una columna que ocupará la mitad de la pantalla en una computadora de escritorio y todo el ancho de la pantalla en un dispositivo móvil. Esto permite obtener resultados de diseño muy específicos y predecibles.

En mi opinión, Foundation for Emails es un poco más complicado de usar que MJML, pero permite un control mucho más estricto del diseño. Eso lo hace ideal para proyectos en los que se necesita reproducir diseños con una calidad de píxeles perfecta, con diferencias muy específicas entre los diseños para dispositivos móviles y de escritorio.

Ventajas

• Un control más preciso sobre los resultados finales
• Plantillas predefinidas
• Apoyo descarado
• Excelente documentación

Desventajas

• El tamaño del archivo del proyecto es pesado y ocupa mucho espacio en disco.
• Un poco menos intuitivo de usar que los parámetros predefinidos de MJML en los componentes.
• Menos componentes disponibles para diseños personalizados

Conclusiones

Producir plantillas de correo electrónico, incluso menos que el desarrollo front-end, no es una ciencia exacta. Requiere mucha prueba y error y MUCHAS pruebas. Cualquiera que sea la herramienta que utilice, si necesita brindar soporte a clientes antiguos, entonces debe probar sus diseños a fondo, especialmente si tienen incluso el más mínimo grado de complejidad. Por ejemplo, si tiene texto que debe ubicarse junto a una imagen, le recomiendo probar con contenido de diferentes longitudes y ver qué sucede en todos los clientes. Si tiene texto que necesita superponerse a una imagen, puede ser una pesadilla.

Cuanto más complejo sea el diseño y menos control tenga sobre él, más útil será utilizar un marco en lugar de codificar manualmente sus propios correos electrónicos, especialmente si el diseño se lo entrega un tercero y debe implementarse tal como está.

No diría que un framework es mejor que el otro y ese no es el objetivo de esta publicación. En cambio, recomendaría MJML y Foundation for Emails para diferentes casos de uso:

• MJML para proyectos que tienen una respuesta rápida y hay flexibilidad en el diseño.
• Fundación para correos electrónicos para proyectos que requieren un control más estricto sobre el diseño y donde éste es súper específico.

Recursos y enlaces

• El sitio web de MJML
• El sitio web de la Fundación para los correos electrónicos
• Prueba de correo electrónico de fuego
• Correo electrónico sobre la prueba ácida
• Una conversación interesante en el foro Litmus, que en cierto modo fue el punto de partida de este artículo.
• Otro artículo de James Luterek que compara estos marcos