Capítulo 7. Retos

La cuarta conferencia anual sobre hipertexto tuvo lugar en San Antonio, Texas, en diciembre de 1991. El proyecto de Tim Berners-Lee de la World Wide Web estaba tomando forma entonces. Pensando que los organizadores y asistentes de la conferencia apreciarían el proyecto, envió una propuesta a Hypertext’91 95. La propuesta fue rechazada.

Retos

La comunidad del hipertexto sentía que el proyecto World Wide Web era demasiado simplista. Casi cualquier otro sistema de hipertexto incluia el concepto de vínculo bidireccional. Si un recurso cambiaba, cualquier enlace apuntando a dicho recurso se actualizaría automáticamente. La web no daba tales garantías. Su sistema de vínculos era mucho más simple – simplemente enlazas a algo y ya está. Para los organizadores de Hypertext’91, esto les parecía increíblemente ingenuo. No entendían que la simplicidad de la web era su fortaleza. Porque enlazar era tan sencillo, cualquiera podía hacerlo. Esto sería crucial en la adopción y éxito de la World Wide Web.

Es muy tentador declarar rápidamente que un enfoque es ingenuo, demasiado simplista y poco realista. La idea de que un sitio web puede simultáneamente ofrecer acceso universal a todo el mundo, al mismo tiempo que proporciona una rica experiencia de inmersión para dispositivos más capaces… eso también parece irremediablemente ingenuo.

Esta sentencia ha sido dicha muchas veces a lo largo de la historia de la web.

 

“Es demasiado simple”

Cuando el Proyecto de Estandares Web hizo su campaña animando a los diseñadores a cambiar de las TABLAS de diseño a CSS, se encontró con resistencia. Una y otra vez fueron criticados por su ingenuidad. “Claro, un diseño basado en CSS podría estar bien para un simple sitio personal, pero no hay manera de que pudiera escalar a un proyecto grande y complejo”.

Luego Doug Bowman encabezó el rediseño basado en CSS de Wired.com y Mike Davidson 96 dirigió el rediseño basado en CSS de ESPN.com. Después se abrieron las compuertas.

Cuando Ethan Marcotte 49 demostró el poder del diseño adaptativo, se encontró con resistencia. “Claro, un diseño de respuesta podría funcionar para un simple sitio personal, pero no hay manera de que pudiera escalar a un proyecto grande y complejo”.

Entonces el Boston Globe lanzó su sitio adaptativo. Microsoft hizo su página de inicio adaptativa. Las compuertas volvieron a abrirse.

Es una historia similar hoy. “Claro, la mejora progresiva podría funcionar para un sitio personal simple, pero no hay manera de que pudiera escalar a un proyecto grande y complejo”.

Las compuertas están listas para abrirse. Sólo necesitamos que usted cree el niño del cartel 97 para el diseño web flexible.

 

“Es demasiado difícil”

Construir sitios web flexibles es un desafío. Se necesita tiempo para aplicar la funcionalidad y las características de una manera considerada por capas. La recompensa es un sitio web que puede reaccionar mejor ante circunstancias inesperadas: navegadores inusuales, conexiones de red escamosas, dispositivos anticuados. Sin embargo, para muchos diseñadores web, el costo en el tiempo parece ser demasiado alto.

Vale la pena recordar que construir con una mejora progresiva no significa que todo debe estar disponible para todos. En su lugar, es la funcionalidad principal lo que cuenta. Si cada característica necesitaba estar disponible para cada navegador en cada dispositivo, de hecho sería un proceso increíblemente arduo. Esto es por lo que la priorización es tan importante. Siempre y cuando la funcionalidad básica esté disponible utilizando la tecnología más simple posible, puede -con una conciencia clara- añadir capas de características más avanzadas.

Sin embargo, es completamente posible que este enfoque acabe en trabajo duplicado. Si crea un proceso de envío de formularios de cliente-servidor pasados ​​de moda y luego lo mejora con JavaScript, puede terminar repitiendo el procesamiento de formularios en el cliente, así como en el servidor. Eso se puede mitigar si también está usando JavaScript en el servidor. Teóricamente es posible escribir JavaScript universal para que el servidor y el navegador compartan una sola base de código. Incluso sin JavaScript universal, sigo pensando que vale la pena dedicar tiempo a crear crédito técnico.

El manual de diseño del Servicio de Gobierno del Reino Unido proporciona una forma aún más corta del proceso de tres pasos que he descrito:

  1. Primero, solo haz que funcione
  2. En segundo lugar, hacer que funcione mejor

El manual de diseño también explica por qué:

Si crea páginas con la idea de que las otras partes aparte de HTML son opcionales, creará una página web mejor y más fuerte.

Este tipo de resiliencia (flexibilidad) significa que el tiempo que gasta por adelantado está bien invertido. También puede notar una tendencia interesante; cuanto más utilice este proceso, menos tiempo tardará.

Pasar de TABLE a CSS parecía una meta imposible idealista. Los diseñadores se sentían cómodos utilizando los elementos TABLE y FONT para el diseño. ¿Por qué querrían aprender una nueva manera de trabajar? Recuerdo lo difícil que fue hacer mis primeros diseños basados ​​en CSS después de años usando hacks. Me tomó bastante tiempo. Pero mi segundo diseño basado en CSS no tomó tanto tiempo. Después de un tiempo, se volvió normal.

Diseñadores acomodados con diseños de ancho fijo tuvo un tiempo difícil con un diseño adaptativo. Ese primer diseño flexible inevitablemente iba a tomar bastante tiempo para construirlo. Pero el segundo diseño flexible no tomó tanto tiempo. Después de un tiempo, se volvió normal.

No es diferente con el enfoque en capas necesario para la construcción de sitios web flexibles. Si no estás acostumbrado a trabajar de esta manera, la primera vez que lo hagas tomará bastante tiempo. Pero la segunda vez no tomará tanto tiempo. Después de un tiempo, se convertirá en normal.

Puede haber situaciones en las que el enfoque de tres pasos no funcionará, pero no son tan comunes como se podría pensar. Si está construyendo un juego en 3D en un navegador web, la tecnología más simple capaz de proporcionar la funcionalidad principal seguirá siendo bastante compleja. Dicho esto, me encantaría ver un juego de aventuras solo de texto mejorado en un shooter en primera persona.

 

¿Cómo convencer… ?

La brillante informática Grace Hopper tenía un reloj inusual en su pared. Corría en sentido contrario a las agujas del reloj. Cuando le preguntaron sobre esto, señaló que era una convención arbitraria, diciendo:

Los seres humanos son alérgicos al cambio. Les encanta decir, “Siempre lo hemos hecho de esta manera.” Trato de luchar contra eso. Es por eso que tengo un reloj en mi pared que va en sentido contrario a las agujas del reloj.

El cambio de comportamiento es difícil. Incluso si está convencido de los beneficios de un enfoque resiliente para el diseño web, puede encontrarse luchando para convencer a sus colegas, su jefe o sus clientes. Siempre fue así. Disfrute de la historia de los estándares de la web y del diseño adaptativo. Estos enfoques fueron finalmente adoptados por personas que fueron inicialmente resistentes.

Demostrar los beneficios de la mejora progresiva puede ser difícil. Debido a que el pago ocurre en circunstancias inesperadas, el enfoque por capas es difícil de vender. La mayoría de la gente ni siquiera sabrá si un sitio se ha construido de una manera flexible. Es una marca de calidad oculta que pasará desapercibida para personas con navegadores modernos en nuevos dispositivos con conexiones de red rápidas.

Por esa misma razón, puede comenzar a implementar este enfoque por capas sin tener que convencer a sus colegas, a su jefe o a sus clientes. Si no les importa, entonces tampoco lo notarán. Como Grace Hopper también dijo, “es más fácil pedir perdón que obtener permiso”.

 

Herramientas

Cambiar un flujo de trabajo o un proceso puede ser particularmente difícil si se opone a las herramientas que se utilizan. Se supone que una herramienta ayuda a las personas a realizar su trabajo de una manera más eficiente. La herramienta debe estar subordinada al flujo de trabajo. Con demasiada frecuencia, las herramientas en su lugar dictan una forma preferida de trabajar. Ya se trate de editores WYSIWYG, programas de diseño gráfico, sistemas de gestión de contenido o marcos de JavaScript, las herramientas influyen inevitablemente en los flujos de trabajo.

Si usted es consciente de esa influencia, y usted puede reconocerla, entonces usted está en una mejor posición para escoger y elegir las herramientas que funcionarán mejor para usted. Hay muchos factores que juegan en la elección de los marcos, por ejemplo: “¿Está bien escrito?”, “¿Tiene una comunidad activa detrás de ella?”, “¿Tiene documentación clara?”. Pero quizás la pregunta más importante que se haga es: “¿Su enfoque coincide con mi propia filosofía?”

Cada marco tiene una filosofía porque cada marco fue escrito por la gente. Si su filosofía se alinea con la del marco, entonces le ayudará a trabajar más eficientemente. Pero si su filosofía choca con la del marco, lo combatirá a cada paso del camino. Incluso podría ser tentador simplemente renunciar y dejar que el marco dicte su flujo de trabajo. Entonces la cola estaría meneando al perro.

Elija sus herramientas sabiamente. Sería una vergüenza terrible si usted abandonó el acercamiento resiliente al diseño web debido a una diferencia de opinión con un pedazo de software.

Las diferencias de opinión a menudo se reducen a un desajuste en las prioridades. En su esencia, el enfoque de mejora progresiva prioriza las necesidades de las personas, independientemente de su tecnología. Herramientas, marcos y bibliotecas de código, por otro lado, a menudo se construyen para priorizar las necesidades de los diseñadores y desarrolladores. Eso no es malo. La comodidad del desarrollador es muy valiosa. Pero hablando personalmente, creo que las necesidades de los usuarios deberían superar la conveniencia de los desarrolladores.

Cuando me enfrento a un problema, y ​​tengo la opción de hacerlo, el problema del usuario o mi problema, lo haré mi problema cada vez. Ese es mi trabajo.

 

Futuro amistoso

En septiembre de 2011, estaba hablando en una conferencia en Tennessee, junto con algunas personas mucho más inteligentes que yo. Una vez que se realizó el evento oficial, nos dirigimos hacia el campo donde habíamos alquilado una casa por unos días. Nos reuníamos para tratar de averiguar hacia dónde se dirigía la web.

Francamente, estábamos asustados. La proliferación de dispositivos móviles lo había cambiado todo. Las tabletas estaban en aumento. La gente estaba hablando de televisiones de Internet. Estábamos esperando para averiguar cuál sería la próxima gran cosa. ¿Frigoríficos habilitados para Internet, tal vez?

Al final, lo único de lo que pudimos estar seguros era de la incertidumbre:

La interrupción sólo se acelerará. La cantidad y diversidad de dispositivos conectados -muchos de los cuales aún no hemos imaginado- explotarán, al igual que la cantidad y diversidad de personas alrededor del mundo que los utilizan.

Eso no es causa de desesperación; es motivo de celebración. Podríamos luchar contra este futuro o abrazarlo. Dándose cuenta de que era imposible ser especialistas del futuro, en su lugar resolvimos ser amigos del futuro:

  1. Reconocer y aceptar la imprevisibilidad.
  2. Piense y actúe de una manera amigable para el futuro.
  3. Ayudar a otros a hacer lo mismo.

Ese primer paso es el más importante: reconocer y abrazar la imprevisibilidad. Ésa es la fuerza impulsora detrás del diseño de la web resiliente. La mejor manera de ser amigable con el futuro es ser compatible con las versiones anteriores.

 

Suposiciones

“¡Exigimos áreas de duda e incertidumbre rígidamente definidas!”, Exclamaron los filósofos en la Guía de la Galaxia de Hitchhiker 99, de Douglas Adams.

Como máquinas de emparejamiento de patrones, somos rápidos en identificar tendencias y codificarlas en suposiciones. Aquí están algunas suposiciones que se hicieron sobre la historia del diseño web:

  • Todo el mundo tiene un monitor de 640 píxeles de ancho.
  • Todo el mundo tiene instalado el complemento de Flash.
  • Todo el mundo tiene un monitor de 800 píxeles de ancho.
  • Todo el mundo tiene un ratón y un teclado.
  • Todo el mundo tiene un monitor de 1024 píxeles de ancho.
  • Todo el mundo tiene una conexión rápida a Internet.

La proliferación de dispositivos móviles sopló esas suposiciones fuera del agua 100. El ascenso del móvil no creó nuevas incertidumbres, sino que puso de relieve las incertidumbres que ya existían.

Eso debería haber sido una lección valiosa. Pero antes de demasiado tiempo los supuestos antiguos fueron reemplazados por otros nuevos:

  • Hay algunas actividades que la gente nunca querrá hacer en sus teléfonos.
  • Cada teléfono tiene una pantalla táctil.
  • Todo el mundo con un teléfono tiene prisa.
  • Cada navegador en cada teléfono es compatible con JavaScript.

Este tipo de suposiciones siempre me recuerdan a los viejos chistes de físicos. “Asumir un navegador web perfectamente esférico …”

Los supuestos son seductores. Si sólo pudiéramos ponernos de acuerdo en ciertos límites, ¿entonces el diseño web no sería mucho más fácil de controlar?

Por más tentadora que sea esta llamada de sirena, ofusca la verdadera naturaleza de la incierta y cambiante tela. Carl Sagan lo puso mejor en su libro The Demon-Haunted World:

Es mucho mejor entender el universo como realmente es, que persistir en la ilusión, por más satisfactoria y tranquilizadora que sea.

 

El futuro

Ojalá pudiera predecir el futuro. Lo único que puedo predecir con seguridad es que las cosas van a cambiar.

No sé qué tipo de dispositivos la gente va a utilizar en la web. No sé qué tipo de software la gente va a utilizar en la web.

El futuro, como la web, es desconocido.

El futuro, como la web, será escrito por usted.

 

Referencias


Notas de traducción

(49) Ethan Marcotte. Visto en el capítulo 3.

(95) Hypertext ACM Conference. Conferencia anual sobre Hipertexto y Social Media.

(96) Mike Davidson.

(97) Niño del cartel (poster child). Persona cuyos atributos o características son emblemáticos para una causa. Por ejemplo, Bobbi Campbell fue “chico del cartel” del SIDA, en los primeros años de la enfermedad.

(98) Grace Murray Hopper. A menudo, se le atribuye erróneamente la invención del término bug para referirse a un error o fallo en un programa. Trabajando con un Mark II en la universidad de Harvard el 9 de septiembre de 1947, los ingenieros encontraron una mariposilla enganchada a uno de los relés del ordenador y que impedía el funcionamiento del mismo. Dicho lepidóptero pasó a la historia de la informática por ser pegado al libro de registro de actividad del ordenador con el comentario «First actual case of bug being found», en español «Primer caso real de bug encontrado» (el término bug no se traduce al castellano por considerarse una palabra técnica). Como ella misma reconoció, no fue ella la que encontró el insecto.

(99) Guía del autoestopista galáctico, libro de Douglas Adams.

(100) Soplar fuera del agua (blow out of water). Dominar totalmente a un oponente en una competición.

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 *