Esperar. ¿Qué acaba de pasar con mi correo electrónico? Grabación de seminarios web

Casi todos los diseñadores y desarrolladores tienen que crear correos electrónicos en algún momento de sus carreras, lo quieran o no. Pero la gran cantidad de clientes de correo electrónico, cada uno con sus propios problemas de representación, hace que muchos muevan la cabeza en la derrota, desconcertados por la avalancha de problemas de diseño de correo electrónico.

Habiendo vivido muchos de estos escenarios, unimos fuerzas con Alex Mohr de Sendwithus para arrojar algo de luz sobre los problemas más comunes que enfrentan las personas nuevas en el correo electrónico y, lo que es más importante, algunas soluciones a esos problemas.

Si no tuvo la oportunidad de asistir al seminario web, “Espere. ¿Qué le acaba de pasar a mi correo electrónico? ”, No se preocupe. Puede descargar las diapositivas y ver la grabación a continuación.

Visualización de diapositivas y grabación →

Por más que lo intentáramos, no pudimos responder a todas las preguntas formuladas durante el seminario web. Y hubo algunos geniales. Por lo tanto, estoy aprovechando esta oportunidad para responder algunas de las preguntas más frecuentes de aquellos que simplemente se dedican al diseño y al marketing por correo electrónico.

¿Por qué Google y Microsoft son tan malos procesando correos electrónicos?

Todos los clientes de correo electrónico tienen problemas para reproducir HTML y CSS, los dos lenguajes que se utilizan para codificar campañas de correo electrónico. Esto se debe a que todos utilizan diferentes motores de renderizado. Los motores de representación son las partes subyacentes de la aplicación de correo electrónico que determinan qué código se representa en la pantalla y cómo se representa realmente.

En el caso de Gmail de Google, se utiliza un preprocesador para eliminar partes específicas del código de un correo electrónico por razones de seguridad. Si bien casi todos los demás clientes de correo web ya lo han descubierto, Gmail esencialmente elimina los estilos CSS incrustados en el <encabezado> de un correo electrónico. Y, dado que muchos diseñadores usan esos estilos para determinar cómo se ve su campaña, esos correos electrónicos sufren en Gmail.

Esto puede ser especialmente notable en los clientes móviles de Gmail, ya que las consultas de medios (los activadores de CSS utilizados en el diseño receptivo tradicional) se encuentran en esa sección. Es por eso que se desarrollaron técnicas como la codificación híbrida (o esponjosa), como una solución directa a las deficientes capacidades de renderizado de Gmail.

En el caso de los clientes de Outlook de Microsoft, el problema radica en el hecho de que Outlook realmente usa Microsoft Word como motor de renderizado. Así es, un editor de texto enriquecido utilizado por estudiantes y gente de negocios por igual se usa para renderizar código HTML y CSS (o al menos lo intenta). Si bien las versiones anteriores de Outlook usaban la versión instalada del navegador web de Microsoft, Internet Explorer, para representar el código de correo electrónico, a partir de Outlook 2007, Word se ha utilizado para facilitar la edición de texto enriquecido a los usuarios de Outlook.

Desafortunadamente para los diseñadores de correo electrónico, Word tiene un soporte muy limitado para HTML y CSS que se usa comúnmente en la web y en campañas de correo electrónico. Este soporte limitado para los estándares web da como resultado campañas de correo electrónico que parecen rotas en Outlook. Comprender que el soporte es el primer paso para que los correos electrónicos se vean bien en Outlook o en cualquier cliente de correo electrónico.

A continuación, se muestran algunos recursos para comenzar a comprender mejor el soporte del cliente de correo electrónico para HTML y CSS:

• La guía definitiva de Campaign Monitor para CSS
• Comprensión de Gmail y CSS: parte 1 y parte 2
• Una guía para representar las diferencias en los clientes de Microsoft Outlook
• Cómo afectan los dispositivos, los sistemas operativos, las aplicaciones y los motores al renderizado
• ¿Problemas con la representación del escritorio? Enfoque las pruebas iniciales en un puñado de motores de renderizado
• Explicación de la representación de correo web: por qué los preprocesadores son el enemigo

¿Cómo maneja Outlook que no muestra las fuentes adecuadas cuando usa fuentes web?

Las fuentes web, fuentes servidas a través de la web en lugar de instalarse en el dispositivo de un usuario, están ganando popularidad. Dado que permiten que las empresas se mantengan en la marca con su tipografía y fomentan el texto en vivo, son una herramienta ideal para los especialistas en marketing por correo electrónico. Desafortunadamente, no todos los clientes de correo electrónico los admiten. Y, en el caso de Outlook, la falta de soporte conduce a situaciones en las que se muestra Times New Roman en lugar de cualquier fuente alternativa declarada en su HTML.

Hemos abordado este problema antes con una solución que requiere una clase HTML en el texto afectado y algo de CSS específico de Outlook. Si bien esta solución todavía funciona bien, una solución más limpia y más fácil de mantener ha ido ganando terreno. Originalmente propuesta por la gente de Action Rocket, esta solución requiere el uso de reglas @ font-face para servir fuentes y envolverlas en una consulta de medios en el encabezado de su correo electrónico.

 <style type="text/css"> @media screen { @font-face { font-family: 'Family Name'; font-style: normal; font-weight: 400; src: local(), local(), url() format(); } } </style>

Esta solución es un enfoque excelente, ya que no requiere atributos de clase HTML que contaminen su código y, al mismo tiempo, garantiza que Outlook vuelva a su pila de fuentes declarada. Consulte el artículo original de Action Rocket para obtener más información sobre la técnica.

¿Cómo se puede evitar que se produzcan enlaces azules en dispositivos móviles?

Los dispositivos móviles son herramientas útiles. Para hacerlos aún más útiles, empresas como Apple han agregado una función a su cliente de correo electrónico que permite a los usuarios agregar información rápidamente a sus contactos, calendario o aplicaciones de mapas. Es muy probable que hayas visto algo como esto en un correo electrónico:

Las direcciones, fechas, horas y números de teléfono específicos en forma de texto se resaltan como enlaces azules subrayados para mostrar que se puede interactuar con ellos. Desafortunadamente, estos enlaces azules a veces causan problemas tanto desde la perspectiva del diseño como desde la accesibilidad. Cuando el texto claro sobre un fondo oscuro se vuelve azul, esos enlaces ahora son difíciles (si no imposibles) de leer, y mucho menos interactuar con ellos.

Hemos escrito antes sobre una solución a este problema que le permite mantener estilos en ese texto pero, nuevamente, una nueva solución está ganando popularidad. Resulta que incluir el siguiente fragmento elimina los enlaces azules en iOS sin la necesidad de un marcado adicional en su HTML. Solo inclúyalo en el encabezado de su correo electrónico y envíelo.

 a[x-apple-data-detectors] { color: inherit !important; text-decoration: none !important; font-size: inherit !important; font-family: inherit !important; font-weight: inherit !important; line-height: inherit !important; }

Algunos asistentes al seminario web señalaron astutamente que el CSS anterior se dirige específicamente a los dispositivos Apple. Si bien mis pruebas recientes han demostrado que los enlaces azules no han sido un problema en Android, algunos miembros de la comunidad Litmus han tenido problemas con Android y Gmail para vincular cosas como números de teléfono. Consulte el debate de la comunidad para ver algunas de las soluciones inteligentes.

¿Cuál es la mejor manera de manejar imágenes receptivas? ¿Qué hay de las imágenes de la retina?

A medida que más personas adoptan un diseño de correo electrónico receptivo, ha aumentado la necesidad de imágenes receptivas. Mi mejor consejo para manejar imágenes receptivas es una técnica que aprendí para Julie Ng, la desarrolladora detrás del increíble Boletín de desarrollo de correo electrónico.

Básicamente, declaras las dimensiones de tu imagen de varias formas dentro de tu etiqueta img. Para evitar que algunos clientes de correo electrónico muestren imágenes retina más grandes en su tamaño completo, declare el ancho utilizando el atributo de ancho. Esto proporciona un buen ancho de línea de base en píxeles. Para los correos electrónicos receptivos, declare el ancho, el ancho máximo y el ancho mínimo de la imagen como CSS en línea. He aquí un ejemplo:

 <img alt="Hello" src="http://example.com/image.png" width="600" border="0">

Naturalmente, querrá proporcionar algo de texto ALT para cuando las imágenes estén deshabilitadas y declare display: block; para evitar espacios en blanco innecesarios alrededor de la imagen. Si necesita control adicional sobre la imagen, puede orientarla con una clase y CSS en el encabezado de su correo electrónico. Solo recuerde, CSS incrustado no es compatible en todas partes.

Cuando se trata de imágenes retina, su mejor opción es simplemente crear sus imágenes al doble del tamaño de visualización previsto para la imagen en su correo electrónico. Por ejemplo, si tiene una imagen de 600 px por 200 px, debe crearla y guardarla como una imagen de 1200 px x 400 px. Inclúyalo normalmente en su correo electrónico. El atributo de ancho que mencioné anteriormente evitará que se muestre como una imagen absurdamente enorme en clientes como Outlook y sus imágenes se verán agradables y nítidas en dispositivos con pantallas retina.

¿Algún consejo para alguien que quiera usar GIF animados en un correo electrónico?

¡Ve a por ello! Los GIF animados son una forma fantástica de agregar movimiento e interés a sus campañas de correo electrónico. Amamos tanto la técnica que escribimos una guía extensa sobre el uso de GIF animados en el correo electrónico.

Simplemente ingrese con el entendimiento de que no son compatibles en todas partes, más notable en Microsoft Outlook, que solo muestra el primer fotograma de la animación. Es una buena idea asegurarse de que las imágenes del GIF se utilicen con fines ilustrativos, no para transmitir información vital a los suscriptores. Ese tipo de información siempre debe mostrarse como texto en vivo en el correo electrónico para que los suscriptores puedan leerlo incluso cuando cosas como GIF e imágenes están deshabilitadas.

Si bien mucha gente piensa que los GIF son solo para divertirse, un montón de empresas de productos están utilizando GIF animados para mostrar las interacciones con sus productos y, esencialmente, enseñar a las personas cómo usar los productos incluso antes de tocarlos. Aquí hay un gran ejemplo de MailChimp:

Los GIF son una gran adición a la caja de herramientas de cualquier vendedor de correo electrónico. Sin embargo, un consejo sería usarlos con moderación. Si cada campaña contiene un montón de GIF, rápidamente pierden la sensación de sorpresa. Úselos ocasionalmente cuando realmente quiera llamar la atención sobre una campaña o programa de algo interesante.

¿Cuál es tu opinión sobre el uso de videos en el correo electrónico?

Al igual que los GIF animados, los videos pueden ser una excelente manera de captar la atención de un suscriptor. Desafortunadamente, los videos en sí mismos tienen incluso menos soporte en los clientes de correo electrónico. Si bien alguna vez pudimos usar un fondo de video en un correo electrónico, solo era compatible con Apple Mail y Outlook para Mac.

Sin embargo, eso no debería disuadirlo de usar videos junto con el correo electrónico. A la gente le encantan los vídeos y las empresas utilizan cada vez más el marketing por vídeo como una forma de aumentar la participación de los usuarios. La mejor manera de utilizar el video en el correo electrónico es incluir una imagen fija del video con un botón de reproducción en la campaña de correo electrónico que enlaza con una página de destino. Los usuarios entienden inmediatamente que es un video y pueden ver el video en la página de destino.

Si bien el video incrustado en el correo electrónico permitiría una experiencia de usuario agradable, nuestros amigos de Wistia señalaron algunos buenos puntos sobre por qué las páginas de destino son una mejor solución.

• El video en una página de destino se puede reutilizar en otro lugar. Es un recurso de contenido permanente.
• Las páginas de destino facilitan más interacciones. Una vez que haya terminado de ver un video en su bandeja de entrada, ¿qué le queda por hacer?
• Las personas pueden compartir videos más fácilmente en las páginas de destino.

Entonces, definitivamente use videos en sus campañas de correo electrónico, pero, al menos por ahora, acepte el hecho de que eso no significa ver videos en un correo electrónico.

¿Recomiendas algún marco de correo electrónico receptivo?

Mencionamos algunos recursos para crear mejores campañas de correo electrónico en el seminario web, pero definitivamente vale la pena repetirlos y ampliarlos aquí.

En lo que respecta a las plantillas y los marcos de trabajo de correo electrónico receptivos, hay varios disponibles:

• Cerberus de Ted Goas
• Planos de correo electrónico de MailChimp
• Fundación de Zurb para correos electrónicos
• MJML de Mailjet

Uno de nuestros favoritos es nuestro propio Slate, que incluye cinco plantillas receptivas para una variedad de escenarios de envío. Cualquiera que sea la opción que elija, asegúrese de probarlas en los clientes de correo electrónico para asegurarse de que sus suscriptores no se llevarán sorpresas.

Ver las diapositivas y la grabación

Cubrimos mucho terreno en, “Espera. ¿Qué le acaba de pasar a mi correo electrónico? " Además de identificar los problemas de correo electrónico más comunes y sus soluciones, abordamos la importancia de probar cada correo electrónico e incluso analizamos cómo probar los correos electrónicos transaccionales con Sendwithus. Si se lo perdió la primera vez, puede descargar las diapositivas y ver la grabación a continuación.

Visualización de diapositivas y grabación →