osom

Menu

Blog

Post Script!Lechugas y Ensaladas Eva

No me gustan las ensaladas, pero tengo que reconocer que las lechugas y ensaladas hidropónicas Eva son diferentes; lo suficiente para ser adoradas incluso por un carnívoro.

Uqwpkdj

Con un producto tan excepcional, los demás esfuerzos de mercadotecnia ganan fortaleza. Un gran producto requiere un gran sitio, uno que sea actual, consistente con lo que pensamos y hacemos, y que sea un reto que supere el trabajo que habíamos hecho en el pasado. El resultado es muy satisfactorio.

Planeación

Un sitio web moderno debe de considerar las tecnologías más recientes de navegadores, pero no dejar atrás otros más viejos; tener una buena experiencia en smartphones —la forma de conectarse a Internet con más crecimiento en los últimos años—, considerar pantallas de alta resolución —que poco a poco se convertirán en el estándar—, aprovechar interacciones touch y tener un gran performance reduciendo el número de peticiones al servidor, así como el tamaño de descarga. Y aún no hablamos de los requerimientos del cliente, siquiera.

Tal vez el requisito más sobresaliente para el proyecto es un sitio hecho para dos idiomas. Una vez jerarquizado el contenido y el mapa del sitio, tuvimos que empezar a darle una identidad y una voz.

Mobile

A5c5ar0 Con la construcción de cada sección, comenzamos a transferir la experiencia a smartphones. El proceso es complicado, ya que se trata no sólo de cambiar el tamaño del lienzo, sino modificar el contexto en el que se está trabajando. El resultado, sin embargo, fue altamente satisfactorio. Incluso pienso que la versión para mobile se siente mejor que para escritorio.

Menú

El más importante de los elementos para mobile requiere no estar desplegado de inicio —u ocuparía gran parte del fold—, tener un tamaño suficiente para touch —45 pixeles como mínimo según la guía de interfaz humana de Apple— y no modificar el markup original. Tras algunas iteraciones y reposicionamientos con CSS, además de agregar el elemento de Menú que está oculto en escritorio, logramos un menú desplegable. Pero le faltaba algo.

8thkqho
Entra desde tu mobile a www.evamas.com para ver la transición
Gran parte de las horas dedicadas al menú fue a la animación de cuando este se desplegara. Tenía que ser fluída, sutil pero apantalladora y congruente con la marca. Son tres efectos los que logran esto:

  1. El despliegue del menú
  2. El movimiento diferido de cada elemento
  3. Un sutil fade-in

La combinación de estos elementos lo hacen ver vivo y limpio, sin estorbar ni retrasar la navegación del sitio. En lo personal, de mis partes favoritas del sitio. Va a ser difícil superar esto.

Home

La idea era utilizar el mismo banner principal, pero una vez redimensionándolo, era obvio que o se iba a cortar, o no se iba a ver nada. Requeríamos de otro diseño menos rectangular.

2plb9dx

Con capas separadas que se muestran o no dependiendo de si es para escritorio o no, los banners se cargan. Desafortunadamente, en las pruebas reales, vimos que a pesar de estar ocultos, los navegadores los seguían cargando. Un grave problema considerando las limitadas velocidades de las conexiones de datos para teléfonos. La solución fue evitar la carga de estas imagenes hasta asegurarnos que fueran necesarias. De no haber hecho esto, la carga del home se hubiera incrementado considerablemente —hasta 10 segundos, según pruebas!— y tomando en cuenta que posiblemente es el primer contacto con un consumidor, podría resultar catastrófico.

Swipe

Las interacciones touch son indispensables para que un sitio se sienta bien en smartphones. En este caso, decidimos que sería la forma ideal para navegar las recetas. Utilizamos swiper para simular el efecto de scroll con resistencia en iOS, inspirado por el menú superior de Polygon.

Después de implementarlo, la experiencia era maravillosa, pero de vuelta a la versión para escritorio, arrastrar con el mouse no se sentía bien para navegar. A veces no es necesario innovar, sino utilizar los paradigmas y convenciones, así que modificamos un poco el script y le pusimos flechas para poder navegar con clicks.
Considerando smartphones sin touch (y otros dispositivos de escritorio, como veremos más adelante), pusimos unas barras de scroll tradicionales.

Un importante reto de esta sección es cómo enseñarle a los usuarios que pueden hacer swipe. Consideramos poner un mini-tutorial, pero no hubiera sido lo ideal. Tenía que haber una forma más sutil de demostrarlo y creo la encontramos.
Primero, las imagenes aparecen cortadas en las pantallas más comunes, dando la impresión de que hay más contenido al que hay que darle scroll. En segundo lugar, cuando el usuario elige una receta —la segunda, en este caso—, tras cargar el sitio, puede ver que se hace scroll para centrar la que eligió en el carrusel. Pruebas de usabilidad con cinco usuarios de diversos niveles nos confirmó que aunque en un inicio es difícil entender que se puede hacer scroll horizontal, tras elegir otra receta y su posterior posicionamiento automático, el usuario aprende qué puede hacer en esa área.

Retina

Ver sitios que no están listos para retina en una pantalla de alta resolución es una experiencia terrible. Falta poco para que ya haya monitores de estas capacidades, así que hay que empezar a diseñar para estos.

El truco con esto es hacer imagenes del doble del tamaño y redimensionarlas a la mitad. Sin embargo, utilizar tags de imagenes incrementan las peticiones al servidor y hacen al sitio más lento (necesitamos utilizar sprites). La alternativa es ponerlo como imagenes de fondo a través de las hojas de estilo, el problema es que necesitamos redimensionarlas a la mitad, y esto requiere background-size (no disponible en navegadores viejos).
El enfoque es poner una imagen del tamaño real, y si el navegador es compatible con background-size, poner la versión para retina. Así es como funciona para todos los elementos del layout.

Para las imagenes de cada sección —banners del home, imagenes de las recetas y de productos—, es un poco más complicado. Primero, utilizar imagenes al doble de tamaño significa incrementar la carga del sitio en vano, pues a menos de que la pantalla del usuario sea retina, no se notará el cambio.
En segundo lugar, el ancho de banda de los smartphones es muy valioso, sacrificar segundos y descarga para que un sitio se vea bien es poner la estética sobre la funcionalidad. Si todas las imagenes fueran retina, muy probablemente la mayoría de los visitantes abandonaría el sitio antes de poder apreciarlo. En este aspecto, creemos que no lo vale.

Mientras no se cumplan las siguientes condiciones, servir imagenes para retina es un no-no:

  1. Que valga la pena cargar archivos más pesados (si no van a apreciar la retina, para qué). Esto es posible de detectar actualmente.
  2. Que esté conectado a WiFi (no es posible de detectar actualmente).
  3. Que su conexión tenga un mínimo de velocidad (posible a medias, pero no vale la pena).

Tan sólo detectar la velocidad de conexión sería insuficiente, pues con 4G definitivamente hay descarga rápida, pero también es limitada, por eso se requiere saber si está conectado a WiFi —y viceversa, si WiFi está lento, servir los assets normales—.

Es posible que la solución venga de forma nativa; en el markup se especifican otros tamaños y es el navegador quien decide si vale la pena descargar imágenes más grandes dependiendo de la conexión a Internet y las preferencias del usuario.

Inglés y Español

Hay muchas formas de trabajar la versión en otro idioma de un sitio; detectando el lenguaje, por subdominios, por un namespace, con cookies, entre otras. Pero, cuál es la mejor forma? Antes que eso, cómo definimos «mejor»?

Tres consideraciones:

  1. Contextualizando el lenguaje del navegador
  2. Simplificando la transición de un idioma a otro
  3. Enfocado a SEO

Estos tres lineamientos establecen que la parte del idioma de la URL debe ser diferente, pero el resto debe ser el mismo, tenemos que detectar el idioma preferido por el navegador y debemos usar cookies con cautela —los bots no aceptan cookies—.

Definimos que www.evamas.com sería el sitio para español y en.evamas.com la versión para inglés. Para cambiar idioma simplemente tendríamos que intercambiar los subdominios y mantener el path en el que estamos. De esta forma, si entramos a www.evamas.com/marca y cambiamos de idioma, estaremos en en.evamas.com/marca. Lo obvio es que si está en inglés debería ser /brand, pero añadiría un nivel de complejidad que posiblemente no lo valga.
La otra opción era no mantener el path y cuando se cambie de idioma llegue siempre al home, y así empezar a trazar rutas personalizadas, pero la experiencia se degradaría demasiado.

Lo interesante es la redirección. Si entran a la versión en inglés y su navegador está en español —o viceversa—, serán redireccionados a la versión de su idioma preferido. Esto funciona sólo la primera vez que visitan el sitio (pueden probarlo abriendo una sesión privada y pegando la dirección del sitio en inglés). La redirección se hace con javascript por dos motivos: se puede detectar si tiene cookies o no (si no tiene, no hacemos nada) y dado a que los bots no aceptan cookies, el sitio no podría ser rastreable.
Ya posteriores ocasiones no hay cambio de dominio.

Performance

Gracias a la magia de Rails, todos los archivos externos están minificados y comprimidos, además de ser servidos a través de Amazon S3. Las imagenes que forman parte del menú y elementos reutilizables son sprites para sus versiones normal y retina, generados automáticamente con Compass. Esto asegura que el layout sea de los primeros elementos en cargar completamente —logo, iconos de social media—.

Gziwjuk
El mapa de sprites utilizado para el layout
Resulta complicado hacer un benchmark real de los tiempos de carga, por las diferencias en las redes 3G y su baja estabilidad, pero medimos tiempos de 5 segundos o menos antes de que el sitio cargue por completo, dependiendo de la sección. Aparentemente es demasiado considerando los estudios de Google y Amazon de los tiempos de respuesta, pero en una conexión 3G el usuario seguramente debe tener más paciencia.

SEO & Open Graph

Aún es muy pronto para evaluar el impacto en SEO, pero además de lo que debería ser un estándar —semántica, peso del sitio, calidad del contenido—, hemos implementado los schemas que ayudan a aumentar la visibildad en motores de búsqueda.

Además, con la implementación del Open Graph, cuando se comparte una URL de Eva en Facebook, aparece la foto de la receta o el producto en cuestión.

Conclusiones

Construir un sitio en el 2013 es complicado. Muy atrás quedó la guerra de los navegadores como nuestra única preocupación. Con una cada vez más amplia variedad de formas de consumir contenido a través de Internet, debemos pensar en cada uno de las variantes para entregar una experiencia más contextualizada.

Las optimizaciones parecerían estar de más con conexiones cada vez más rápidas —incluso en redes móviles—, pero mientras tanto, los usuarios lo agradecerán.
Son otras consideraciones adicionales que no incluimos en este artículo, como por ejemplo los favicons —que requieren un post a parte— o la forma en la que hicimos los sprites. El punto que tenemos que entender es que no es tan fácil hacer un sitio web —al menos si se quiere hacer bien—, y que si pensábamos que con el decremento de los navegadores viejos nuestros problemas acababan, estamos muy equivocados.

Pero uno se da cuenta que cuando el trabajo está bien hecho se ve decente incluso en Internet Explorer 7.