DÍA 7

Mails responsive, del papel a la pantalla

En web hay pocas cosas peores que enfrentarte a un banner de flash o a la búsqueda de logos vectoriales. Si no cuentas al mail como una de ellas, agárrate los machos: ¡mails responsive! Desde el monstruo de Frankenstein no se ha visto atrocidad mayor. Vamos a ver como plantearlos.


Los primeros mails son como de los años 70; ahora, cuarenta y pico años después nos escriben príncipes africanos en apuros, familiares con fabulosas presentaciones de gatitos y aplicaciones informándonos de que alguien ha visto nuesto perfil.

Realmente los años no han pasado como desearíamos sobre el mundo del correo electrónico y nos enfrentamos a un panorama complicado donde las reglas del pasado conviven con tablets, smartphones y relojes.

mobile-devices

Desde Space Nomads, nos gustaría tomarnos unos minutos para hablar de cómo plantear un mail responsive mañana.

Los clientes más fuertes de correo no aceptan media queries así que en el fondo desarrollas un producto que se va a ver principalmente en dispositivos apple, los pocos android que no tiren de gmail y algún despistado con windows phone. Y eso pensando en los clientes de correo “oficiales”, cualquier otra cosa es territorio desconocido.

Pero bueno, somos diseñadores y nos reímos del peligro, así que vamos al turrón. pensemos que estamos en un mundo ideal en el que tenemos el contenido y pasamos directamente al diseño. ¡Ey! ¡Quietos los ratones, fieras! Primero vamos a planificar el comportamiento de nuestra pequeña criatura.

Antes del papel

Todo el ecosistema “mail” es una versión reducida (y limitada) de la web; por limitaciones técnicas y por presupuesto necesitamos tener claras una serie de reglas y recursos para ser ágiles en el desarrollo de un producto que se consume en el momento y tiene una vida ciertamente corta.

Si habéis visto Gremlins (1984) sabéis cómo va esto:

  1. Nada de imágenes de fondo
  2. Sólo fuentes de sistema
  3. La funcionalidad más avanzada es el link.

Nuestra pequeña maravilla va a ser realmente pequeña, a pesar de los pantallones actuales, entre 500 y 600 pixels de ancho sigue siendo la mejor idea. ¿Quién decide esto? Pues es una mezcla de costumbre, limitaciones técnicas y, en menor medida, el contenido. Las pantallas eran pequeñas, los espacios de los clientes de correos no eran gran cosa, entraron las distribución en tres paneles (carpetas, listado de mails, detalle de mail)… Realmente puedes hacer un email del ancho que quieras. La recomendación sigue siendo que te ciñas a esos 500 / 600px.

Por cierto, esto no va a mobile first porque los clientes mayoritarios siguen sin aceptar media queries, así que la versión principal es la desktop. De hecho nuestra criatura va a tener dos posiciones:

  • Fija a 500px/600px
  • Fluida por debajo de nuestro ancho elegido.

¿Pero espera, no puedo meter media queries como si no hubiese mañana y hacer algo realmente responsive? Haciendo honor a la verdad sí puedes, lo que pasa es que no debes; por la propia naturaleza del mail te verás limitado a pequeños cambios de texto, estilo y posiciones que te consumirán demasiado tiempo para que salga rentable.

Recordemos que el objetivo de este mail es que se vea correctamente en la mayor parte de clientes, por supuesto, se verá mejor en los clientes más capacitados. Pero tened esto muy presente: existe Outlook.

Dicho esto, vamos a la estructura: nuestra vista principal se resolverá a base de tablas, algunas de ellas se comportarán como bloque y algunas se ocultarán. Todo lo que se puede hacer se puede resolver así.

Leyenda

Vamos a ver algunos ejemplos:

1 columna

Esta parece fácil pero es una forma sencilla de tener una imagen a nuestos 600px de ancho que en móvil se ajusta al ancho del dispositivo.

1-columna
Tiene truco: imagen a 100% de ancho y no le puedes poner alto (a outlook no le mola).

2 columnas

Las tenemos con y sin separadores, dependiendo del uso que se le vaya a dar. En móvil usamos clases con margin-bottom para resolver las separaciones que necesitemos.

2-columnas
Nota: Puedes ocultar elementos visibles pero no puedes mostrar elementos invisibles. Así es el año 2015.

3 columnas

3-columnas

Mismo ejemplo, con separadores, nada nuevo por aquí.

Vamos a dar un paso más

Combinando estas estructuras se puede montar casi cualquier diseño. La clave está en desgranar comportamientos y anidar como si no hubiese mañana (o como si no nos cobrasen por escribir tablas). Esto va a permitir construir una estructura lo suficientemente robusta para que la transición a móvil sea posible.

Por ejemplo:

gestion-de-espacios
Nota: recordemos que los colores representan comportamientos.
  1. La primera tabla actua de contenedor principal, marca el ancho en escritorio y actúa como bloque al 100% de ancho en móvil.
  2. El segundo contenedor es una tabla al 100% de ancho con una celda con padding horizontal de 20px. Esto es para que la tabla siempre sea del 100% pero en el td no quede especificado ningún ancho.
  3. La tercera tabla tiene ancho fijo: ancho de la primera tabla menos 40px (esos 20px de padding a cada lado) y en móvil será un bloque al ancho completo.

Al no poder cambiar el modelo de caja tenemos que separar anchos al 100% de elementos con padding que se vayan a comportar como bloque y así evitar un display:block con un ancho al 100% y, digamos, 20px de padding a cada lado.

La maquetación sin tablas que es práctica natural en web y que intentamos optimizar. Aquí simplemente no compensa por los ajustes que hay que hacer para que luego las vistas se mantengan consistentes entre los distintos clientes; siento ser pesado pero uno de esos clientes es MS Outlook.

¿Vemos un ejemplo “real” sencillito?

Diseño a una columna, el comportamiento es de ejemplo. Tenemos una cabecera de color plano a todo el ancho, una imagen principal a 600, unos márgenes de 15px y una columna de contenido de 570px (600px – 15px -15px).

mail-sample

Aunque es simple tiene un poco de truco y usaremos lo que hemos visto antes para resolverlo y conseguir que por debajo de 600px se dispare la versión móvil en el que la imagen de cabecera va a ancho completo, se mantienen los espacios verticales y el bloque de contenido se ajusta también al ancho pero manteniendo esos 15px.

Lo realmente complicado de todo esto es que se vea en un outlook 2011, en un 2013, en android, en gmail, en outlook.com, en tu iPhone y que le llegue a tu abuela a yahoo mail.

He preparado el esquema para identificar todos los elementos y se puede ver maquetado en Litmus.

¿No sabéis lo que es Litmus? Nada, ahora lo vemos.

Sobre todo interesa no ya la ejecución sino el ver que usando pequeños módulos se pueden plantear estructuras más complejas que lo mismo resuelven una presentación de producto, una newsletter de infojobs o una comunicación de tu banco.

Litmus

Una vez maquetada tu pequeña criatura responsive tenemos la mitad del trabajo; ahora queda probarlo.

litmus

Si no te suena de nada, Litmus es una herramienta que te genera envíos a una batería de diferentes clientes/dispositivos/sistemas operativos (tiene una hermana pequeña, putsmail, que se encarga de lanzar el envío).

En un mundo ideal tendríamos diferentes cuentas de prueba (esto es razonable), varios equipos y dispositivos con clientes diferentes al que enviaríamos pruebas sin fin desde el sistema de envío que vamos a usar (nosotros o nuestro cliente). Además contaríamos con unas estadísticas detalladas de nuestros usuarios o targets, de sus resoluciones, clientes de correo… Y tiempo para hacer todas estas pruebas.

Bien, esto no va a pasar nunca. Lo normal es ir totalmente a ciegas, sin datos reales ni un entorno de pruebas.

Un poco para terminar…

Mientras preparaba los ejemplos en Litmus he visto que en Android 4.4 (KitKat) han “eliminado” la posibilidad de aplicar un display:block a un <td>. Directamente significa que todo esto que planteo no va a funcionar en el cliente de correo por defecto de los dispositivos con este sistema operativo (por eso son tan importantes las analíticas).

Bueno, ¿y ahora qué haces? Porque a esta gente no les puedes hablar de multidispositivos y que lo que le planteas falle en el minuto uno. Por otra parte, es una oportunidad estupenda para ver cómo afrontar un revés como este porque hoy es Android 4.4 pero ayer fue Microsoft eliminando los margins, o Google con que GMail no acepta media queires, o los estilos propietarios de las versiones de Office que renderizan con Word. Esto puede y va a pasar en cualquier momento. Si hay suerte, una búsqueda rápida te mandará a los foros de Litmus o a StackOverflow y ya, si no, posiblemente haya que remaquetar y replantear como abordamos el problema.

En este caso bastó con cambiar los <td> que se van a comportar como bloque por <th>. Sí, así. En mails, las soluciones suelen ser rastreras y callejeras.

Os dejo el ejemplo de 3 columnas funcionando.

Recordad esto: si se muestra correctamente y no lanza una alerta de seguridad, está bien.