La ilusión del Control en Diseño Web
Por Aaron Gustafson. Original en inglés, traducción al español por Mariana Ramírez
Todos queremos construir experiencias web robustas y atractivas. Examinamos cada pequeño detalle de una interacción. Pasamos horas consiguiendo que la oscilación de la animación sea perfecta. Reformamos nuestro JavaScript para reducir fracciones diminutas de segundos de tiempo de descarga. Controlamos absolutamente todo lo que podemos, pero la dura realidad es que controlamos menos de lo que pensamos.
La semana pasada¹, dos eventos nos recordaron, una vez más, cuánta razón tenía Douglas Crockford cuando declaró que la web era “el entorno de ingeniería de software más hostil imaginable”. Ambos eran lo suficientemente serios para derribar un sitio entero — de hecho cientos de sitios enteros, como sucedió. Y ambos eran inevitables.
Al comprender lo que controlamos (y lo que no), construimos productos resistentes, atractivos para nuestros usuarios.
¿Qué pasó?
El primero de estos incidentes involucró el lanzamiento de Chrome 66. Con esa versión, Google implementó un parche de seguridad con serias repercusiones para quienes no estaban prestando atención. Tal vez recuerdes que un buen número de certificados SSL cuestionables emitidos por KPI de la Corporación Symantec comenzaron a aparecer a principios del año pasado. Por lo visto, Symantec había subcontratado la creación de certificados sin proporcionar mucha supervisión. En pocas palabras, el equipo de Chrome decidió que el mejor curso de acción con respecto a estos certificados SSL fraudulentos (y potencialmente peligrosos) era establecer un “fin de vida” para aceptarlos como seguros. Establecieron Chrome 66 como punto límite.
Así que, cuando Chrome 66 salió al mercado (una actualización automática, transparente para casi todo el mundo), de repente cualquier sitio que ejecutara HTTPS en uno de esos certificados no sería considerado seguro. Ese es un problema importante si el certificado en cuestión es para nuestro dominio principal, pero también es un problema si es para una CDN que estamos usando. Verás, mi servidor puede estar corriendo con un certificado SSL válido, pero si tengo mis activos — imágenes, CSS, JavaScript — alojados en una CDN que no es segura, los navegadores bloquearán esos recursos. Es como el Día CSS Desnudo otra vez.
Para ser completamente honesto, no estaba prestando mucha atención a esto hasta que Michael Spellacy me puso al tanto en Twitter. Doscientos sitios de su empleador se redujeron instantáneamente a simple HTML semántico. Sin CSS. Sin imágenes. Sin JavaScript.
El segundo incidente fue bastante similar en el sentido que involucraba SSL, y específicamente la expiración de un certificado SSL usado por la CDN de jQuery. Si un sitio dependía de esa CDN para servir una versión de jQuery alojada en HTTPS, sus usuarios no la habrían recibido. Y si ese sitio dependía de jQuery para ser utilizable… bueno, ¡ay!
Si sirve de algo, esta no es la primera vez que ocurren incidentes como estos. Hace sólo unos pocos años, el filtro parental de Sky Broadband clasificó incorrectamente la CDN de jQuery como una fuente de malware. Con esa designación, pasaron la mayor parte del día bloqueando todas las solicitudes de recursos de ese dominio, afectando a casi todos sus clientes.
Puede ser fácil encogerse de hombros ante noticias como esta. Seguro tomaríamos decisiones de implementación más inteligentes si estuviéramos a cargo. Ciertamente habríamos incluido una copia local de jQuery como el buen Boilerplate nos dice. La cuestión es, que incluso con esa protección extra, estamos cayendo en una de las falacias más atractivas cuando se trata de construir para la web: que tenemos el control.
¿Perdido en el tránsito?
Hay algunas cosas que sí controlamos en la web, pero pueden ser menos de las que piensas. Como un desarrollador individual o líder de equipo, tenemos un control considerable sobre el código HTML, CSS y JavaScript que a fin de cuentas construye nuestros sitios. Lo mismo en lo que respecta a las herramientas que usamos y las soluciones de alojamiento que elegimos. Por supuesto, ese control disminuye en equipos grandes o cuando otros están tomando las decisiones, aunque en esas ocasiones todavía tenemos conocimiento de las convenciones de codificación, herramientas y entornos de alojamiento con los que estamos trabajando. Sin embargo, una vez que nuestro código cuidadosamente elaborado abandona nuestros servidores, todas las apuestas se cancelan.
En primer lugar, no controlamos — al menos en la gran mayoría de los casos — la red por la que pasa nuestro código para llegar a nuestros usuarios. Idealmente nuestro código toma una ruta optimizada para llegar a su destino rápidamente, pero cualquiera de los servidores a lo largo de esa ruta puede leer y manipular el código. Si has oído hablar de los ataques del “intermediario”, así es como suceden.
Por ejemplo, ciertos proveedores no tienen escrúpulos para insertar su propia publicidad en tus páginas. Asqueroso, ¿verdad? HTTPS es una forma de evitar que esto pase (y de evitar que los servidores puedan husmear en nuestro tráfico), pero algunos proveedores han encontrando incluso una forma de evitarlo.
¿Perdido en la traducción?
Asumiendo que nadie toque nuestro código en tránsito, lo siguiente que se interpone entre nuestros usuarios y nuestro código es el navegador. Estas aplicaciones son las puertas de entrada (y los guardianes) de las experiencias que construimos en la web. Y, aunque en la última década los proveedores de navegadores se han unido en torno a los estándares web, todavía hay diferencias por considerar. Esas diferencias son otro factor que hará o romperá la experiencia que nuestros usuarios tengan.
Mientras que cada proveedor de navegador apoya la idea y el desarrollo continuo de estándares, lo hacen a su propio ritmo y en gran medida de acuerdo a sus intereses empresariales. Priorizan características que les ayudan a alcanzar sus propios objetivos y en ocasiones pueden ser reacios o lentos para implementar nuevas características. Ocasionalmente, como sucedió con CSS Grid, todo el mundo se adhiere relativamente rápido, y podemos ver que una nueva especificación pasa del borrador a la implementación en un solo año calendario. Otros, como Service Worker, pueden arraigarse rápidamente en un puñado de navegadores pero tomar más tiempo para desplegarse en otros. Otros, como Pointer Events, podrían ser implementados ampliamente, sólo para ser socavados por la indiferencia de un navegador.
Todo esto quiere decir que el paisaje de los navegadores se parece mucho a las Grandes Llanuras del Medio Oeste americano: desde lejos se ve muy uniforme, pero caminando a través de él estamos destinados a tropezarnos con una o dos madrigueras de perros de la pradera. Y para navegar con éxito los desafíos que plantea el entorno del navegador, vale la pena familiarizarse con la ubicación de esas madrigueras para no perder el equilibrio. Detección de objetos …. font stacks … media queries … detección de características… estas herramientas (y más) nos ayudan a asegurarnos que nuestro trabajo no caiga en situaciones menos que ideales.
Más allá del soporte de estándares, es importante reconocer que algunos navegadores incluyen optimizaciones que pueden afectar la entrega de tu código. Opera Mini y Silk de Amazon son ejemplos de la clase de navegadores generalmente referidos como navegadores proxy. Los navegadores proxy, como su nombre lo indica, sitúan sus propios servidores proxy entre nuestros dominios y el usuario final. Usan estos servidores para hacer cosas como optimizar imágenes, simplificar el markup, y desechar JavaScript no soportado a fin de reducir el tamaño de descarga de nuestras páginas. Los navegadores proxy pueden ser una ayuda tremenda para los usuarios que pagan por las descargas por bit, especialmente dada nuestra tendencia a aumentar el tamaño de las páginas web año tras año.
Si no consideramos cómo estos navegadores pueden afectar nuestras páginas, nuestro sitio puede simplemente colapsar y quedar patas arriba como una cabra desmayada. Considera este JavaScript tomado de un ejemplo que tiré en Codepen:
document.body.innerHTML += ‘<p>¿Puedo contar hasta cuatro?</p>’;for (let i=1; i<=4; i++) {document.body.innerHTML += ‘<p>’ + i + ‘</p>’;}document.body.innerHTML += ‘<p>Éxito!</p>’;
Este código está diseñado para insertar varios párrafos en el documento actual, cuando se ejecuta, produce esto:
¿Puedo contar hasta cuatro?1234Éxito!
Bastante simple, ¿verdad? Bueno, sí y no. Verás, este código usa la palabra clave let, que fue introducida en ECMAScript 2015 (también conocida como ES6) para permitir la delimitación de variables a nivel de bloque. Funcionará como una delicia en los navegadores que entienden let. Sin embargo, cualquier navegador que no entienda let no tendrá idea qué hacer con él y no ejecutará ninguno de los JavaScript — ni siquiera las partes que sí entienda — porque no sabe cómo interpretar el programa. Los usuarios de Opera Mini, Internet Explorer 10, QQ, y Safari 9 no obtendrían nada.
Este es un ejemplo relativamente simplista, pero subraya la fragilidad de JavaScript. La GDS del Reino Unido realizó un estudio para determinar cuántos de sus usuarios no obtuvieron mejoras de JavaScript y descubrió que el 0.9% de sus usuarios que deberían haberlas recibido — en otras palabras, su navegador soportaba JavaScript y no lo habían desactivado — no las recibieron por alguna razón. Si se añade el 0.2% de los usuarios cuyos navegadores no soportan JavaScript o que lo habían desactivado, el número total de usuarios que no utilizan JavaScript es del 1.1%, es decir, 1 cada 93 personas que visitan su sitio.
Vale la pena tener en cuenta que los navegadores deben entender la totalidad de nuestro JavaScript antes que puedan ejecutarlo. Esto puede no ser un gran problema si escribimos todo nuestro JavaScript (aunque todos ocasionalmente cometemos errores), pero se vuelve un gran problema cuando incluimos código de terceros como librerías de JavaScript, código publicitario, o botones de redes sociales. Los errores en cualquiera de esas bases de código pueden causar problemas a nuestros usuarios.
Los plugins del navegador son otra forma de código de terceros que puede afectar negativamente nuestros sitios. Y son los que a menudo no consideramos. A principios de los 2000, recuerdo pasar horas tratando de diagnosticar un error reportado en un sitio por uno de mis clientes, sólo para descubrir que sólo ocurría cuando se usaba un plugin en particular. La ira y la falta de confianza en mí mismo estaban causando estragos, ya que fallaba una y otra vez en reproducir el error que mi cliente estaba experimentando. Me tomó dos horas viajar a su oficina y sentarme en su escritorio para notar la diferencia entre su configuración y la mía: una barra de herramientas de terceros en un navegador.
No tenemos el lujo de viajar a los hogares y oficinas de nuestros usuarios para determinar si y cuándo un plugin de un navegador está dañando nuestras creaciones. En su lugar, la mejor defensa contra las incógnitas del entorno de navegación es diseñar siempre tus sitios con una base de referencia universalmente utilizable.
¿Perdido en la interpretación?
Independientemente de todo lo discutido hasta ahora, cuando nuestro sitio web cuidadosamente diseñado finalmente llega a su destino, tiene otra barrera potencial para el éxito: nosotros. Específicamente, nuestros usuarios. Más en general, la gente. A menos que nuestro producto esté creado únicamente para el consumo de alguna otra forma de vida o máquina, tenemos que considerar la pérdida de control final cuando lo cedemos a alguien más.
A lo largo de mis veinte años construyendo sitios web para clientes, siempre he tenido la quejumbrosa voz de Randal Graves de Clerk en mi cabeza: “Este trabajo sería genial si no fuera por los p — s clientes.” No estoy contento con eso. Es una posición arrogante (seguramente), pero es fácil caer en ella.
La gente es tan demandante. ¿No sería genial si pudiéramos enfocarnos sólo en nosotros?
No, eso no sería bueno en absoluto.
Cuando diseñamos y construimos para gente como nosotros, excluimos a todos los que no son como nosotros. Y esa es la mayoría de la gente. Me voy a poner mi sombrero de negocios aquí — ¿Fedora? ¿Bowler? ¿Sombrero de copa? — y a decir que limitar artificialmente nuestra base de clientes probablemente no sea lo mejor para nuestra compañía. No sólo limitará el crecimiento potencial de nuestras ganancias, podría de hecho reducir nuestros ingresos si nos convertimos en objeto de un reclamo legal por parte de una parte excluida.
Nuestros esfuerzos para construir experiencias robustas en la web deben tener en cuenta las personas que las utilizan (o que pueden querer utilizarlas). Eso significa asegurarnos que nuestros sitios funcionen para gente con discapacidades motrices, visuales, auditivas, vestibulares, y otras cosas que agregamos bajo el título de “accesibilidad”. También significa asegurarnos que nuestros sitios funcionen bien para los usuarios en una variedad de contextos: en pantallas grandes, pequeñas, incluso entre pantallas. A través del mouse, el teclado, el lápiz táctil, el dedo, e incluso la voz. En oficinas oscuras y sin ventanas, en salas de conferencias con paredes de cristal, y afuera en el sol del mediodía. Sobre conexiones de banda ancha increíblemente rápidas y conexiones móviles dolorosamente lentas. Dondequiera que estén las personas, independientemente de cómo accedan a la web, cualesquiera que sean las consideraciones especiales que haya que tener en cuenta para acomodarlas… deberíamos construir nuestros productos para que sean compatibles con ellas.
Esto puede parecer una tarea difícil, pero considera esto: eliminar las barreras de acceso para un grupo tiene un efecto dominó de largo alcance que beneficia a otros. La rampa de las aceras es un ejemplo que citamos con frecuencia. Originalmente fue diseñada para el acceso con silla de ruedas, pero los padres que empujan cochecitos, los niños en bicicletas, e incluso el repartidor de UPS que transporta una torre de cajas de Amazon por la Séptima Avenida se benefician de esa consideración bastante simple.
A lo mejor eres más una persona de números. Si es así, considera diseñar tu interfaz de manera que sea más fácil de usar por alguien que tiene un solo brazo. Cada año, cerca de 26,000 personas en los Estados Unidos pierden permanentemente el uso de una extremidad superior. Es una gota en el balde comparado con una población total de casi 326 millones de personas. Pero es una discapacidad permanente. Hay otras dos formas de discapacidad por considerar: temporal y situacional. Romperte el brazo puede significar que pierdas el uso de esa mano — quizás tu mano dominante — por algunas semanas. Cerca de 13 millones de estadounidenses sufren una lesión en el brazo como esta cada año. Sostener un bebé es un impedimento situacional el cual puedes dejar y recuperar el uso de tu brazo, pero la viabilidad de esto puede depender en gran medida del temperamento del bebé y su horario de descanso. Alrededor de 8 millones de estadounidenses acogen con agrado este tipo de impedimento — por dulce y tierno que sea — en sus hogares cada año, y este impedimento en particular puede durar más de un año. Todo esto es para decir que diseñar una interfaz que pueda usarse con una sola mano (o a través de la voz) puede ayudar a más de 21 millones de estadounidenses (cerca del 6% de la población) a utilizar tu servicio de forma efectiva.
Finalmente, y cerrando el círculo de muchas maneras, está el texto que empleamos. Un texto claro, bien escrito y apropiado es la base fundamental de grandes experiencias en la web. Cuando redactamos el borrador, deberíamos hacerlo con un buen sentido de la forma en que nuestros usuarios se comunican entre sí. Eso no significa que debamos sazonar términos legales con jerga, pero sí significa que debemos escribir un texto que sea fácilmente comprensible. Debe estar escrito a un nivel de lectura apropiado, sin jerga ni expresiones idiomáticas innecesarias, y debe ser accesible tanto para hablantes nativos como no nativos. Anidado en el suave abrazo de nuestro (esperemos) semántico, HTML renderizado en el servidor, el texto que escribimos es una de las únicas experiencias de nuestros sitios que podemos garantizar que nuestros usuarios tendrán.
Un viejo consejo, aún relevante
Reconocer todas las formas en que nuestras experiencias cuidadosamente elaboradas pueden volverse inutilizables puede ser algo más que un poco descorazonador. A nadie le gusta pasar su tiempo pensando en el fracaso. Así que no lo hagas. No te concentres en todas las cosas malas que no puedes controlar. Concéntrate en lo que puedes controlar.
Empieza de forma simple. Escribe código a la defensiva. Haz pruebas de usuario hasta el cansancio. Reconoce el caos. Acéptalo. Y construye experiencias web resistentes que funcionarán sin importar lo que el internet les depare.
Nota
[1] En referencia a la fecha original de publicación del artículo, corresponde a la semana del 16 al 22 de abril de 2018.
