Por qué es inútil diseñar para móviles: Diseño responsivo y experiencias recientes

A menos que estés tratando de hacer una aplicación nativa para smartphones o tablets, pensar en una versión exclusiva para móviles de tu sitio web es, por decirlo de una manera amable, una completa pérdida de tiempo. Saco esta conclusión de dos caminos bien separados: el primero, el artículo There Is No Mobile Internet (Smashing Magazine), donde explican que la experiencia -y las expectativas- de Internet es una sola para el usuario, casi por completo con independencia del lugar, dispositivo o intención en el momento de buscar algo en la red; y la experiencia que tuve en mi último proyecto grande de desarrollo web.

Versiones móviles y de escritorio

Así se ve la versión móvil en el celular.

Empecemos con Smashing. El artículo parte refiriendo a una nota del blog para webmasters de Google. Para el motor de búsqueda por excelencia, así como para el usuario de a pie, la clave está en que un contenido particular debe estar en una sola URL o dirección tanto para móviles o equipos de escritorio. Usando diferentes métodos (el texto de Google arroja luces sobre los diseños responsivos, que abordaré luego, y sitios dinámicos que ofrecen diferente HTML/CSS para cada dispositivo). De esta manera, cuando tú compartes una noticia desde el celular a Facebook, cuando tus amigos la abren en sus computadoras deberían verla lista para la pantalla grande, en lugar de encontrarse con la misma versión que leíste en la pantalla de 3,5 pulgadas en sus pantallas de 20:

Así se ve cuando accedes desde el sitio web del diario.

Pero así se ve cuando accedes desde el enlace publicado a Facebook con el celular.

Lo que ocurre aquí es que Correo usa «diariocorreo.pe/ultimas/noticias/…» para todas sus notas en el sitio estándar. Pero todas sus direcciones para celulares empiezan por «diariocorreo.pe/movil/ultimas/notiicias…«, lo que significa suficiente diferencia para que tanto el navegador del teléfono, Facebook, el servidor y el navegador de escritorio los consideren como páginas diferentes. En consecuencia, terminas con la versión móvil hasta a 4 ó 5 veces el ancho de lo previsto, con el consecuente espacio desaprovechado, imágenes reventadas, y otras fallas estéticas.

Versión móvil.

En contraste, El Comercio usa URLs similares, pero en su caso «elcomercio.pe/movil/noticia/1545356» sí se convierte en «elcomercio.pe/gastronomia/1545356/…«. Este es un reemplazo de URL que se realiza en el servidor, y sin prestar atención al método, es más práctica a este nivel para el medio y para el lector. Debido a que la edición móvil de este diario está optimizada casi exclusivamente para la lectura (fotos pequeñas, cero publicidad y diseño minimalista), todo parece funcionar bien, con formatos que se corresponden a las posibilidades de cada soporte. Lo que no me termina de quedar claro es cuánto daño puede hacer esta separación a los ránkings de reputación y confiabilidad que tuviera Google sobre la noticia.

Versión de escritorio.

Preparados para crecer

Hasta aquí hemos visto modelos bastante funcionales y obstáculos salvables en el desarrollo de sitios web aptos para diferentes pantallas. Pero, como indica Smashing, “los usuarios móviles harán cualquier cosa y todo lo que hagan los usuarios de escritorio, siempre y cuando se presente de una forma utilizable”. O en otras palabras, no usamos más características -ni es posible registrar un no-uso en las analíticas web- de los sitios móviles porque no las tenemos ahí. Y hasta ahora, con el estado de los medios en Internet del país, no parece haber  problema.

Pero la experiencia al tratar de plantear formas diferentes de usabilidad y rentabilizar productos basados completamente en la red pueden obligar a los medios nuevos y tradicionales a abordar el otro enfoque recomendado por Google: la navegación responsiva.

Pongo como ejemplo el caso de PCWorld Perú, un sitio web que desarrollamos entre agosto y setiembre de 2011 como sucesor de la revista/suplemento tecnológico de El Comercio. La idea, actuando ahora como independientes y en consecuencia limitados en presupuesto y personal, fue simplificar procesos. La suerte permitió que casi al mismo tiempo apareciera Yoko, una de las primeras plantillas responsivas de WordPress, como una solución bastante interesante que pasé un buen tiempo estudiando.

Versión de escritorio. Noten los banners publicitarios, botones sociales y el slider de noticias destacadas.

Con Yoko (y varias otras plantillas similares), echas mano de la etiqueta meta viewport y la consulta @media screen en la hoja de estilos, definiendo cómo va a reaccionar cada elemento a determinado tamaño de pantalla en píxeles. Así, puedes deshacerte de algunos márgenes, reacomodar cabeceras, menús, optimizar el tamaño de las fotos, y cualquier otro cambio que mejore la experiencia en el móvil. Sin embargo, el dolor de cabeza más grande vino cuando nos encontramos con elementos que no eran susceptibles de modificación vía CSS.

Probamos muchos plugins antes de optar por  FA Lite, muy amigable con CSS.

Los botones de «Compartir» en redes sociales no son afectados por el diseño responsivo.

Independiente de que la gran mayoría de sliders o carruseles de imágenes para las notas destacadas están realizados en Flash, JavaScript, AJAX o cualquier otro lenguaje que no sea muy compatible con el uso de hojas de estilos, el verdadero aprieto apareció cuando debíamos «correr» elementos básicos para la estrategia comercial inicial, como los banners de AdSense en las barras laterales y el formulario de suscripción rápida. Aunque con el tiempo los primeros dejaron de depender de Flash, gracias a previsiones de Google -aunque el problema resurgía cuando se trataban de anunciantes locales con piezas en SWF-, la tendencia a priorizar contenidos nos llevó a relegar a tres de cuatro elementos publicitarios y un formulario de registro al fondo de la página.

En un diseño responsivo, los sidebars pueden enviarse al fondo del sitio. ¿Pero deberían?

Considerando que hablamos de pantallas táctiles de 3,5 a 4 pulgadas, esto significa que el usuario no ve a nuestros anunciantes o no puede suscribirse a nuestro newsletter hasta no dar siete desplazamientos en vertical y pasar por todas las noticias de portada. Y aún entonces, los formato con los que están pensados los banners y los widgets de WordPress no se lucen muy bien en una pantalla de celular.

Hoy en día, la suscripción y la publicidad son elementos clave en el desarrollo de cualquier emprendimiento en línea. Aunque los medios masivos no lo sufren aún, empresas que utilicen sus sitios web con una intención más comercial deberían considerar de qué manera reconciliar piezas en lenguajes de programación distintos a HTML/CSS con las técnicas responsivas, o incluso tomar precauciones antes de probar soluciones en nuevos métodos, como HTML 5.

Dándole la vuelta al problema, Smashing destaca la necesidad de una «comunicación aguda y enfocada«, concentrando esfuerzos y contenidos para librarnos del lastre que solemos arrastrar al adaptar versiones de escritorio a móviles (como una nube de etiquetas o una línea de tiempo de Twitter). De hecho, muchos elementos como widgets, extractos y menús fueron reducidos y simplificados con el paso del tiempo en PCWorld para mejorar la experiencia móvil en la medida que nos era posible hacer la distinción. Y aún así, la complejidad de la página de inicio nos hizo expandir cada vez más el umbral de tolerancia, dejando en mi salida la versión para móviles sólo visible en pantallas de menos de 360 píxeles de ancho (de manera que el smartphone en horizontal pudiera mostrar la versión «completa»).

Es tan importante desde una perspectiva de comunicaciones de marketing como de negocio que saquemos un máximo provecho de los recursos, y en este rumbo el «screen real state», o espacio en pantalla, es un nuevo elemento de valor e impondrá nuevos filtros al ruido que los diseñadores y clientes hemos arrojado sobre nuestros sitios web.

Efectivamente, el medio vuelve a modificar la forma en que presentamos el mensaje. Esperemos que el resultado sea para bien.