No sé si me sorprende, o no la cantidad, pero el número de websites, portales importantes que consulto semanalmente que no son adaptativos es significativo. Sea adaptativo lo correspondiente a responsive en inglés y no a adaptative que es un otro concepto. Hay un debate importante en la comunidad virtual sobre como traducir  responsive web design al castellano.

Un site diseñado con el diseño web adaptativo  “responde” de forma diferente a cada dispositivo desde el cual se accede, teniendo en cuenta el comportamiento del usuario, el tamaño de la pantalla y la orientación, utilizando una mistura de Layouts flexibles mediante HTML5, CSS3 y Media Queries.

Lo cierto es que desde que el 2010  Ethan Marcotte creó la técnica de diseño web adaptativo, divulgándola en A list Apart, la práctica se extendió tan rápido que Mashable, con un buen ejemplo de diseño web adaptativo en su página web, declaró  el 2013 como el Año del Diseño Web Adaptativo y Google lo recomienda como una de las opciones a la hora de abordar los sitios web para multidispositivos.

Lo interesante del RWD, entonces, es que puedes utilizar la misma plantilla para multidispositivos, utilizando estas variaciones en el CSS, o JS, significando esto menos recursos, menos ficheros en el servidor, menos tiempo de carga, más usuarios contentos.

Concepto interesante, pero con problemas por solucionar

A la hora de proyectar el diseño de la web, el maquetador agradecerá que se solucionen algunas situaciones antes de que le sea concedido el trabajo.

Navegación

Dependiendo del tipo de arquitectura existente, o contenido del site  en que estemos trabajado, la navegación, o el tipo de navegación puede realmente ser uno de los problemas más importantes. La clásica barra de menú superior, con submenús infinitos necesitará una estrategia de diseño consistente y adaptada al tipo de información. Michael Mesker tiene un artículo interesante sobre este tema en:

Imágenes

Con el creciente número de dispositivos móviles, cada vez más específicos en sus características, como por ejemplo los que tienen pantalla de alta densidad de píxeles, las imágenes necesitan la mayor flexibilidad posible de modo que los gráficos no se vean “borrosos” en estos dispositivos. Lo mismo pasa con los iconos. Existen diferentes soluciones para este problema que se pueden utilizar con buenos resultados. Para los iconos es buena idea utilizar las fuentes de iconos. Para las demás imágenes, utilizar el formato SVG, si posible  y aplicable, si no algún script externo PHP, por ejemplo. Adaptive images es una buena herramienta para ello.

Tablas

Las tablas son realmente problemáticas, hablando por experiencia, una vez más. ¿Cómo cuadrar, o adaptar aquella información técnica, compleja en un número tremendo de columnas y líneas, y que “responda”, a un dispositivo de pantalla ‘pequeña’? Hay diferentes opciones, entre ellas la de esconder la información “menos importante” a los usuarios, pero utilizar el script de zurb, que es una combinación simple de JavaScript y CSS, una vez más,  me parece una buena opción. El único tema es que no funciona en Android 2.3, de momento.

Herramientas de test

En todo este proceso, normalmente, no se tienen todos los dispositivos, de diferentes  resoluciones y formatos de forma física. Así que utilizar herramientas virtuales gana enteros a la hora de maquetar, debugging, emular, simular o testar. Firefox y Chrome, por ejemplo, tienen plugins que permiten testar las resoluciones más populares. De hecho, hay una distribución de Chrome, Chrome Canary muy interesante para desarrolladores, que tiene un emulador que permite obtener resultados muy fidedignos para multidispositivos. Vale la pena experimentar. www.quirktools.com también es una opción a considerar.

Sería necesario  también discutir la necesidad de convertir a aquellas webs de ancho fijo a responsivas. En mi opinión es más fácil reconstruir desde cero, permite mayor control,  o utilizar algún framework (timesaver), aunque sea posible hacer lo contrario, teniendo en cuenta, obviamente,  la estructura y dimensión de la plataforma existente, y discutir también qué hacer con versiones antiguas de navegadores, el tiempo y coste, se está desarrollando un website o una aplicación web, etc…
Lo fundamental puede que sea, como dice Jeremy Keith, “dejar de pensar en páginas y empezar a pensar en sistemas”.

Fuentes consultadas:


Do you want more posts like this?