Capítulo 5. Las capas

En su clásico How Buildings Learn (“Cómo aprenden los edificios”), Stewart Brand destaca una idea del arquitecto británico Frank Duffy:

Un edificio adecuadamente concebido tiene varias capas de longevidad

Las capas

Duffy denominó esto corte por capas. Cada una de las capas se mueve en una escala temporal diferente. Brand profundizó en la idea, proponiendo seis capas superpuestas:

  1. Lugar la ubicación física de un edificio sólo cambia en una escala de tiempo geológica.
  2. Estructura el propio edificio puede permanecer durante siglos.
  3. Envolvente (piel) la superficie exterior puede tener una rehabilitación o una mano de pintura cada pocas decadas.
  4. Servicios las instalaciones de agua y luz necesitan actualizarse aproximadamente cada diez años.
  5. La distribución el diseño de paredes y puertas puede cambiar ocasionalmente.
  6. El mobiliario la distribución de la decoración de una habitación puede cambiar con cierta frecuencia.

La idea del corte por capas también se puede aplicar a nuestras creaciones en la web. Nuestros nombres de dominio son los sitios geológicos sobre los que construimos. En el otro extremo de la escala de tiempo, el contenido de la web – el mobiliario – se puede añadir y  actualizar cada hora, cada minuto, incluso cada segundo. Entre ambos extremos se encuentran las capas de la estructura, la presentación y el comportamiento: HTML, CSS, y JavaScript.

Dichas capas pueden estar débilmente acopladas, pero no son completamente independientes entre ellas. Así como un edificio no se puede decorar (o amueblar) sin paredes ni habitaciones, una hoja de estilos necesita un marcado sobre el que actuar. El acoplamiento entre estructura y presentación se gestiona mediante los selectores CSS 82: selectores de elemento, selectores de clase, y así. Con JavaScript, el acoplamiento se maneja a través del vocabulario del Document Object Model, o DOM 83.

En un libro posterior, The Clock Of The Long Now, Stewart Brand aplicó la idea de las capas de corte – o capas de paso – a la misma civilización. La capa con un desarrollo más lento es la naturaleza, a partir de la cual encontramos la cultura, el gobierno, la infraestructura y finalmente el comercio y la moda son las capas más cambiantes. En un sistema de acoplamiento débil, cada capa depende de la capa anterior. Por turno, la acumulación de cada capa sucesiva habilita una “adyacente posible” llena de oportunidades.

Igualmente, la expresividad de CSS y JavaScript sólo es posible con una base de HTML, la cual a su vez requiere una URL, que a su vez depende del protocolo TCP/IP.

Cada una de las capas de corte de la web se puede pelar hacia atrás para revelar una capa a continuación. Ejecutar ese proceso de inversión de cada capa es un principio del diseño web flexible.

 

Mejora progresiva

En 2003, el festival South by Southwest 84 de Austin, Texas, fue inicialmente un evento para músicos y productores de cine. Actualmente, los apartados de música y cine están eclipsados por el imparable avence de South by Southwest Interactive, dedicado a los temas digitales.  En 2003, South by Southwest Interactive era un pequeño encuentro, apartado en un rincón del Austin Convention Center. Era una oportunidad para unos pocos diseñadores web y bloggers para estar juntos y compartir ideas. Aquel año, Steven Champeon y Nick Finck presentaron una charla titulada Inclusive Web Design For The Future With Progressive Enhancement (“Diseño Web Inclusivo Para el Futuro con Mejoramiento Progresivo”). La abrieron con esta llamada a las armas:

El diseño web debe madurar y aceptar los desarrollos de los últimos años, abandonar las actitudes de exclusión formadas en la era de las dotcoms (punto com), conocer el futuro próximo de una amplia variedad de dispositivos y plataformas y separar el marcado semántico de la lógica y el comportamiento de la presentación.

Como Tim Berners-Lee, Steven Champeon tenía experiencia en el trabajo con SGML, el lenguaje de marcado del que derivó HTML. En la relación con documentos que necesitaban redefinirse para diferentes outputs, empezó a valorar la separación de la estructura y de la presentación. Un documento marcado por su significado se puede presentar de múltiples formas, gracias al añadido de CSS y JavaScript.

Este enfoque de la web por capas permite servir el mismo contenido a una gran variedad de personas. Pero esto no significa que todo el mundo tenga la misma experiencia. Champeon se dio cuenta de que una fuerte separación de los asuntos permitiría que las mejoras se aplicaran de acuerdo con las capacidades del dispositivo del usuario final.

Parafraseando a Karl Marx, la mejora progresiva permite a los diseñadores pedir a cada navegador sus habilidades, y enviar a cada dispositivo según sus necesidades.

 

¿Necesitan los sitios web verse exactamente igual en todos los navegadores?

Algunos diseñadores web estaban convencidos de que la mejora progresiva resultaría una camisa de fuerza creativa. Diseñar para el mínimo común denominador no sonaba como una receta para el progreso. Pero había un malentendido. La mejora progresiva invita a los diseñadores empezar desde el mínimo común denominador (un documento correctamente marcado), pero sin límite al que se pueda llegar.

De hecho, es la misma presencia de una sólida linea base de HTML la que permite a los diseñadores web experimentar con el último y más grande CSS. Gracias a la Ley de Postel y al modelo de gestión de errores de CSS, los diseñadores son libres de aplicar estilos que solo funcionan en los navegadores más modernos.

Esto significa que no todo el mundo experimentará el mismo diseño visual. Pero esto no es un error. Es una característica de la web. Nuevos navegadores y viejos navegadores; pantallas monocromo y pantallas multi-color; conexiones rápidas y conexiones lentas; grandes pantallas, pantallas pequeñas, dispositivos sin pantalla; cualquiera puede acceder a tu contenido. Ese contenido se podrá ver diferente en situaciones variadas. Si un sitio web se ve igual en un navegador de 10 años que en los dispositivos más modernos, entonces probablemente no estará aprovechando la gran flexibilidad que ofrece la web.

Para enfatizar esto, el diseñador Dan Cederholm creó un sitio web para responder a la pregunta, “¿Necesitan los sitios web verse exactamente igual en cualquier navegador?”. Puedes encontrar la pregunta a esta cuestión en la URL:

dowebsitesneedtolookexactlythesameineverybrowser.com

A riesgo de espoilearte la sorpresa, la respuesta es un rotundo “No!”. Si visitas el sitio, verás la respuesta orgullosamente mostrada. Pero dependiendo de las capacidades de tu navegador, podrás o no podrás ver algunas de las florituras estilísticas aplicadas a tan simple respuesta. Incluso si no tienes ninguno de los estilos, todavía tendrás el contenido marcado con la semántica HTML.

 

Cortar la mostaza (llegar a las expectativas) 85

Separar estructura y presentación es relativamente sencillo. Puedes declarar cualquier estilo que quieras, seguro de que los navegadores ignorarán lo que no entiendan. Separar la estructura y el funcionamiento no es tán fácil. Si le das a un navegador código JavaScript que no entiende, no sólo no aplicará el funcionamiento deseado, rechazará interpretar el resto del script.

Antes de que utilices una característica particular en JavaScript, vale la pena probar a ver si dicha característica es soportada. Este tipo de detección de característas puede salvar al visitante de tu sitio web de tener una mala experiencia debida a una característica no soportada. Si quieres utilizar AJAX, mira primero que el navegador soporta el objeto que estás a punto de usar para utilizar la funcionalidad de AJAX. Si quieres utilizar la API de geolocalización, averigua primero si el navegador la soporta.

Un grupo de de desarrolladores web que estaban trabajando en el sitio web de noticias de la BBC se refirió a este tipo de detección de características como cortar la mostaza. Los navegadores que alcanzan las expectativas tienen una experiencia mejorada. Los navegadores que no lo consiguen, aún tienen acceso al contenido, pero sin las mejoras de JavaScript.

La detección de características, alcanzar las expectativas, siempre que quieras utilizarla, es una técnica muy sencilla. Digamos que quieres cruzar el DOM utilizando querySelector y enlazar eventos a algunos nodos en el documento utilizando addEventListener. Tu código podría ser algo similar a esto:

Hay dos temas que puntualizar aquí:

  1. Esto es detección de características, no detección de navegador. En lugar de preguntar “¿qué navegador eres tú?” e intentar concluir qué soporte de características tiene, es más seguro preguntar simplemente “¿soportas esta característica?”.
  2. No hay una sentencia else.

 

Mejora agresiva

De vuelta a cuando los diseñadores web intentaban ejercer un control como el de la impresión a los navegadores web, un diseño correcto se medía por la perfección del pixel: ¿se veía el sitio web exactamente igual en cada navegador?

A no ser que cada navegador soporte una característica particular – como, digamos, esquinas redondeadas en CSS – entonces dicha característica estaba fuera de la tabla. Sin embargo, los diseñadores lo falseaban con marcado extra e imágenes. Los sitios web resultantes carecían de honestidad estructural. No sólo era un desperdicio de talento y energía por parte de los diseñadores, era un desperdicio de las capacidades de los navegadores web modernos.

El incremento de dispositivos móviles, y el diseño adaptativo, ayudaron a perder este pensamiento restrictivo. Ya no es realista pretender la perfección del pixel a través de los dispositivos y los navegadores. Pero todavía encuentras diseñadores web lamentando el hecho de que tienen que soportar un navegador desfasado porque una porción de su audiencia todavía lo utiliza.

Están en lo cierto.  Cualquiera que utilice un navegador antiguo puede acceder al mismo contenido que alguien que utilice el navegador más moderno. Pero eso no significa que deban tener la misma experiencia. Como dijo Brad Frost 86:

Hay una diferencia entre soporte y optimización.

Soportar cada navegador.. pero optimizar para ninguno.

Algunos diseñadores han confundido que la mejora progresiva significa que se debe proveer todas las funcionalidades a todo el mundo. Es lo contrario. La mejora progresiva significa proveer una funcionalidad del núcleo a todo el mundo. Después de esto, su navegador para cada uno. Lejos de restringir qué características puedes utilizar, la mejora progresiva provee a los diseñadores web con un camino para utilizar con seguridad las últimas y más grandes características sin preocuparse de los navegadores antiguos. Scott Jehl 87 de la agencia Filament Group, dijo sucíntamente:

La mejora progresiva nos libera de centrarnos en los costos de la construcción de características para los navegadores modernos, sin preocuparse mucho por dejar a nadie fuera. Con una base de código fuertemente calificada, el soporte de navegador más antiguo viene casi gratis.

Si un sitio web se construye con mejora progresiva entonces es correcto si una característica particular no es soportada o falla en la carga: Ajax, geolocalización, cualquiera. Mientras la funcionalidad del núcleo esté disponible, los diseñadores web no necesitan volver hacia atrás intentando soportar nuevas características en navegadores antiguos.

También tienes un sitio web que es más flexible al modelo de gestión de errores de JavaScript. Mat Marquis trabajó junto a Scott Jehl en el sitio web adaptativo para el Boston Globe. Él anotó:

Un montón de características interesantes en el Boston Globe no funcionan cuando se rompe JS; “Leer las noticias” no es una de ellas.

La cuestión es identificar qué es considerada una funcionalidad del núcleo y qué es considerada una mejora.

 

REFERENCIAS


Notas de traducción

(82) Selector CSS. Elemento básico de CSS, con el que indicamos sobre qué elemento ejecutamos las declaraciones. Los selectores pueden ser básicos o avanzados.

(83) DOM Document Object Model (Modelo de objetos del documento). Es, básicamente, la estructura de una página web, mediante la cual JavaScript puede acceder y modificar el contenido, estructura y estilo de los documentos HTML.

(84) South by Southwest (Al sur del suroeste). También se escribe SXSW. Evento que congrega congresos y conferencias de películas, medios interactivos y música.

(85) Cortar la mostaza (Cutting the mustard). No resulta fácil traducir expresiones hechas del inglés. Desgraciadamente, el traductor de Google te traduce las expresiones literalmente, por lo que, cuando encuentras una, debes preguntar su significado en inglés. Lo mismo me pasó con la expresión teaching grandmother to suck eggs (“enseñar a la abuela a chupar huevos”) en el capítulo 2.

(86) Brad Frost. En su página web (enlace), se encuentra toda su producción, que no es poca. Recomendado.

(87) Scott Jehl.

Derechos

Este libro ( Resilient Web Design ) ha sido escrito y producido por Jeremy Keith. Bajo licencia Creative Commons Attribution-ShareAlike 4.0 International License. Yo me he limitado a traducirlo, y, en todo caso, añadirle unas notas de traducción para enriquecerlo ( aunque no fuera necesario enriquecerlo ). Esta traducción, a su vez, también está bajo la licencia Creative Commons Attribution-ShareAlike 4.0 International License.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *