La evolución de los usos se está orientando cada vez más hacia los dispositivos móviles y las tabletas. La web es (y será) cada vez más móvil y accesible desde cualquier lugar, bajo condiciones heterogéneas. Ahora, no podemos basarnos en las stadísticas de visitas de los sitios para saber para cual configuración particular de hardware y software un site debe estar diseñado, ya que no hay más un modelo de usuario ideal (de hecho, eso nunca existió).
Si la tendencia del marketing es de orientarse hacia sitios específicamente dedicados al iPhone o al iPad considerando su tasa de penetración, es inconcebible cerrarse a todos los demás dispositivos actuales y futuros cuyas características difieren y diferirán cada vez más.
Ahora tenemos que adaptarnos a un panorama tecnológico cambiante, tanto en términos de los dispositivos utilizados (me refiero específicamente a las tabletas ya bien establecidas) que en las condiciones de uso (couch surfing viendo la televisión para las tabletas, en cualquier lugar para los móviles, y cada vez menos de computadoras de escritorio en proporciones relativas).
Para seguir esta evolución, es hora de repensar la del contenido y de su arquitectura para publicar el mismo contenido en todos los dispositivos. Y en primer lugar, romper los prejuicios: la web móvil no existe, solamente hay contenido que se visualiza de forma diferente de acuerdo con los dispositivos utilizados (y ya lo sabemos desde hace algún tiempo).
Del mismo modo, es difícil prejuzgar del contexto de uso de los móviles. El usuario móvil no es como nos pareció hacia poco una persona que se mueve y que busca una información específica con alguna emergencia, al contrario.
El diseño web adaptativo (o responsive web design) le permite a su contenido ser accesible cualquiera que sea la situación de uso. A medida que se aplica en su organización, de la simple adaptación del diseño de su sitio a la refondición completa de su gestión de contenido, usted verá el valor de significado central de su sitio llegar a la superficie: el contenido y el servicio.
Ante todo, veamos rápidamente dos definiciones.
Con el advenimiento del HTML5 y del CSS3, y la lenta adaptación de los navegadores en el mercado (y de su actualización por los usuarios), dos palabras aparecieron en nuestro vocabulario: los shims y los polyfills.
Un shim es una aplicación de solución de compatibilidad para la compatibilidad regresiva (como simular el DOS bajo Windows).
Un polyfill es un shim que imita una API futura proporcionando una funcionalidad todavía no soportada por los navegadores más antiguos (definición de Paul Irish).
Por lo general, un polyfill es un plugin javascript que permite a un navegador antiguo o que todavía no soporta una norma actual o futura de soportarla (dado que no existía en su tiempo). Esto incluye, por ejemplo, el soporte de los bordes redondeados (border-radius) para IE6-9 (CSS3 Pie).
Aquí es una lista de polyfills HTML5 y CSS3/4.
Las media queries del CSS3 permiten la adaptación del contenido mostrado dependiendo del tamaño de las pantallas (y de su orientación). Plantean directamente la pregunta de la arquitectura del contenido (que mostrar en que pantallas para concentrarse en la información la más útil cuando el espacio no es suficiente y, por lo tanto, eliminar el superfluo o rechazarle más bajo), pero también la de la ergonomía.
Por ejemplo, el tipo de menú puede variar en función del dispositivo: pestañas o enlaces textuales en pantallas grandes, reemplazados por una caja de selección en las pantallas más pequeñas (ver la solución de CSS Tricks). También, datos tabulares pueden ser empujadas en una pantalla secundaria disponible bajo petición (como en este ejemplo).
Respond.js es un polyfill para las media queries min/max-width (IE6-8 y otros).
En el siguiente ejemplo, el contenido se reduce al mismo tiempo que la anchura de la ventana: imagen, después el menú, y finalmente la superficie útil, hasta la minimización del diseño para concentrarse en el contenido propiamente dicho. Se desvanece el superfluo y da paso al contenido.
Una solución ideal de diseño web adaptativo debería ajustarse a todos los tamaños de pantalla siendo completamente fluido (piense porcentajes en todos los pisos). Sin embargo, es común soportar los teléfonos pequeños (240x320), el iPhone (320x480), las tabletas pequeñas (480x600), el iPad (768x1024) y las pantallas de ordenador (o de televisión) mayores, que sea en el modo vertical o horizontal.
Se obtiene la serie de media queries siguiente, que podríamos seguir para soportar pantallas más grandes:
El enfoque RESS, para Responsive Web Design with Server Side Components, va más allá trabajando también en el lado del servidor. Se trata de ajustar la visualización según los dispositivos utilizados, sino también su rendimiento (velocidad de descarga, tamaño de las imágenes, soporte video) y la experiencia de usuario, dependiente en parte del modelo de interacción (pantalla táctil, mouse, rueda de control). La detección del dispositivo se hace a través de una base de datos (por ejemplo wurfl), y las diferentes variables del dispositivo se almacenan en un cookie. Sólo los contenidos soportados y adaptados se envían al cliente. Esta presentación de Anders Andersen hace una breve presentación de esto.
En el enfoque del lado del cliente, todo el contenido es enviado, y el javascript (estoy pensando aquí en Modernizr) maneja la interacción y la visualización.
Si el cambio de tamaño en CSS es una solución viable, se va como el cambio de tamaño en HTML con los atributos width y height de la marca img: la imagen enviada sigue siendo tan pesada. El enfoque es por lo tanto de enviar imágenes de tamaños diferentes según el dispositivo utilizado (su área de visualización útil, o viewport), pero también la velocidad de la red, la orientación de la pantalla, la densidad de píxel (dpi)…
El WhatWG (Web Hypertext Application Technology Working Group) trabaja actualmente sobre el atributo srcset que lista una serie de imágenes según el tamaño de la pantalla.
En paralelo, el RICG (Responsive Images Community Group) del W3C trabaja en otras propuestas posibles, incluyendo el tag <picture> por lo cual algunos polyfills ya han sido desarrollados (ver el artículo Responsive Images and Web Standards at the Turning Point de Mat Marquis en A list apart).
Aunque todavía es demasiado pronto para dicer qué implementación será propuesta como estándar y soportada por los navegadores, el tag <picture> ya es viable para la comunidad. Observamos también que el HTML evoluciona desde todos los lados al mismo tiempo: el W3C para los estándares (y su parcialidad para el XHTML), el WhatWG (Apple, Mozilla, Opera, o los «fabricantes») con su propia visión del HTML, y la comunidad que ya no parece querer estar dictada sus herramientas (de donde los polyfills basados en jQuery).
Estas son algunas de las herramientas de pruebas en línea:
Si la tendencia del marketing es de orientarse hacia sitios específicamente dedicados al iPhone o al iPad considerando su tasa de penetración, es inconcebible cerrarse a todos los demás dispositivos actuales y futuros cuyas características difieren y diferirán cada vez más.
Ahora tenemos que adaptarnos a un panorama tecnológico cambiante, tanto en términos de los dispositivos utilizados (me refiero específicamente a las tabletas ya bien establecidas) que en las condiciones de uso (couch surfing viendo la televisión para las tabletas, en cualquier lugar para los móviles, y cada vez menos de computadoras de escritorio en proporciones relativas).
Para seguir esta evolución, es hora de repensar la del contenido y de su arquitectura para publicar el mismo contenido en todos los dispositivos. Y en primer lugar, romper los prejuicios: la web móvil no existe, solamente hay contenido que se visualiza de forma diferente de acuerdo con los dispositivos utilizados (y ya lo sabemos desde hace algún tiempo).
Del mismo modo, es difícil prejuzgar del contexto de uso de los móviles. El usuario móvil no es como nos pareció hacia poco una persona que se mueve y que busca una información específica con alguna emergencia, al contrario.
¿Qué se puede hacer para adaptarse a este cambiante panorama?
El diseño web adaptativo (o responsive web design) le permite a su contenido ser accesible cualquiera que sea la situación de uso. A medida que se aplica en su organización, de la simple adaptación del diseño de su sitio a la refondición completa de su gestión de contenido, usted verá el valor de significado central de su sitio llegar a la superficie: el contenido y el servicio.
Definiciones
Ante todo, veamos rápidamente dos definiciones.
Con el advenimiento del HTML5 y del CSS3, y la lenta adaptación de los navegadores en el mercado (y de su actualización por los usuarios), dos palabras aparecieron en nuestro vocabulario: los shims y los polyfills.
Un shim es una aplicación de solución de compatibilidad para la compatibilidad regresiva (como simular el DOS bajo Windows).
Un polyfill es un shim que imita una API futura proporcionando una funcionalidad todavía no soportada por los navegadores más antiguos (definición de Paul Irish).
Por lo general, un polyfill es un plugin javascript que permite a un navegador antiguo o que todavía no soporta una norma actual o futura de soportarla (dado que no existía en su tiempo). Esto incluye, por ejemplo, el soporte de los bordes redondeados (border-radius) para IE6-9 (CSS3 Pie).
Aquí es una lista de polyfills HTML5 y CSS3/4.
CSS y media query
Las media queries del CSS3 permiten la adaptación del contenido mostrado dependiendo del tamaño de las pantallas (y de su orientación). Plantean directamente la pregunta de la arquitectura del contenido (que mostrar en que pantallas para concentrarse en la información la más útil cuando el espacio no es suficiente y, por lo tanto, eliminar el superfluo o rechazarle más bajo), pero también la de la ergonomía.
Por ejemplo, el tipo de menú puede variar en función del dispositivo: pestañas o enlaces textuales en pantallas grandes, reemplazados por una caja de selección en las pantallas más pequeñas (ver la solución de CSS Tricks). También, datos tabulares pueden ser empujadas en una pantalla secundaria disponible bajo petición (como en este ejemplo).
Respond.js es un polyfill para las media queries min/max-width (IE6-8 y otros).
Un ejemplo en imágen
En el siguiente ejemplo, el contenido se reduce al mismo tiempo que la anchura de la ventana: imagen, después el menú, y finalmente la superficie útil, hasta la minimización del diseño para concentrarse en el contenido propiamente dicho. Se desvanece el superfluo y da paso al contenido.
¿Qué ancho de pantalla debemos soportar?
Una solución ideal de diseño web adaptativo debería ajustarse a todos los tamaños de pantalla siendo completamente fluido (piense porcentajes en todos los pisos). Sin embargo, es común soportar los teléfonos pequeños (240x320), el iPhone (320x480), las tabletas pequeñas (480x600), el iPad (768x1024) y las pantallas de ordenador (o de televisión) mayores, que sea en el modo vertical o horizontal.
Se obtiene la serie de media queries siguiente, que podríamos seguir para soportar pantallas más grandes:
@media only screen and (min-width: 240px) and (max-width: 319px) {}
@media only screen and (min-width: 320px) and (max-width: 479px) {}
@media only screen and (min-width: 480px) and (max-width: 599px) {}
@media only screen and (min-width: 600px) and (max-width: 767px) {}
@media only screen and (min-width: 768px) and (max-width: 799px) {}
@media only screen and (min-width: 800px) and (max-width: 1023px) {}
@media only screen and (min-width: 1024px) {}
Para ir más lejos
RESS
El enfoque RESS, para Responsive Web Design with Server Side Components, va más allá trabajando también en el lado del servidor. Se trata de ajustar la visualización según los dispositivos utilizados, sino también su rendimiento (velocidad de descarga, tamaño de las imágenes, soporte video) y la experiencia de usuario, dependiente en parte del modelo de interacción (pantalla táctil, mouse, rueda de control). La detección del dispositivo se hace a través de una base de datos (por ejemplo wurfl), y las diferentes variables del dispositivo se almacenan en un cookie. Sólo los contenidos soportados y adaptados se envían al cliente. Esta presentación de Anders Andersen hace una breve presentación de esto.
En el enfoque del lado del cliente, todo el contenido es enviado, y el javascript (estoy pensando aquí en Modernizr) maneja la interacción y la visualización.
El desafío de las imágenes adaptativas
Si el cambio de tamaño en CSS es una solución viable, se va como el cambio de tamaño en HTML con los atributos width y height de la marca img: la imagen enviada sigue siendo tan pesada. El enfoque es por lo tanto de enviar imágenes de tamaños diferentes según el dispositivo utilizado (su área de visualización útil, o viewport), pero también la velocidad de la red, la orientación de la pantalla, la densidad de píxel (dpi)…
El WhatWG (Web Hypertext Application Technology Working Group) trabaja actualmente sobre el atributo srcset que lista una serie de imágenes según el tamaño de la pantalla.
En paralelo, el RICG (Responsive Images Community Group) del W3C trabaja en otras propuestas posibles, incluyendo el tag <picture> por lo cual algunos polyfills ya han sido desarrollados (ver el artículo Responsive Images and Web Standards at the Turning Point de Mat Marquis en A list apart).
Aunque todavía es demasiado pronto para dicer qué implementación será propuesta como estándar y soportada por los navegadores, el tag <picture> ya es viable para la comunidad. Observamos también que el HTML evoluciona desde todos los lados al mismo tiempo: el W3C para los estándares (y su parcialidad para el XHTML), el WhatWG (Apple, Mozilla, Opera, o los «fabricantes») con su propia visión del HTML, y la comunidad que ya no parece querer estar dictada sus herramientas (de donde los polyfills basados en jQuery).
Un poco de lectura
- Responsive Web Design (en inglés), por Ethan Marcotte, en las editoras A Book Apart, es un libro que todos deberían leer para ver el tema en profundidad.
- Mobile First (en inglés), por Luke Wroblewski, en la misma colección, lo completa bastante bien.
Marcadores
Estas son algunas de las herramientas de pruebas en línea:
Conception web adaptative (en francés)
Responsive web design (en inglés)
O web design responsivo (en portugués)
No hay comentarios:
Publicar un comentario