Economía 102 » Ruido blanco

En la anterior entrada exponía la teoría que, si bien es posible que todos los fallos de un software deberían poder ser arreglados, no es beneficioso arreglar todos ellos, por lo que algunos se quedarían sin arreglar, al destinarse todos los recursos a los fallos que produjeran mayor beneficio.

Voy a avisar antes de empezar que después de leer esta entrada quizá acabe siendo la persona más impopular, cabrona, insensible, desaprensiva e insolidaria que hayáis conocido. No os equivoquéis, lo soy.

Lo que voy a intentar hacer es un análisis de mercado para una página web en español y dirigida al público hispanohablante. No voy a empezar bien, porque no soy capaz de encontrar estadísticas sobre navegadores web “en español”, por lo que utilizaré las estadísticas globales.

Según que estadística mires (que, como los pacientes de House, siempre mienten) puedes encontrarte shares para el Internet Explorer de entre el 65% y el 80%; el sistema operativo por excelencia es Windows en sus diferentes variantes con un 95% del mercado (85% si sólo consideramos Windows XP), mientras que las resoluciones de pantallas mayores de 1024×768 son más del 85% mientras que las pantallas de 800×600 son un 10%.

Así que un usuario medio de la web podríamos decir que es un usuario de Windows (con mucha posibilidad XP), utilizando Internet Explorer en una pantalla de 1024×768 (o más). Traduciendo: el usuario pesadilla del diseñador web.

Y ese es el problema principal de los diseñadores web: ellos no utilizan Internet Explorer (ni de coña), no utilizan (ni de coña) una pantalla de menos de 1024×768 (y normalmente será mucho más grande, incluso multimonitor). Lo de Windows XP sigue siendo cierto, principalmente porque se dispone de 3 de los 4 importantes motores de navegadores web actuales (Trident, el motor de Internet Explorer; Gecko, el de Mozilla; y Presto, el de Opera; mientras que no conozco navegador relativamente estable en Windows con motor KHTML/WebCore, el de Konqueror/Safari).

A estos dos grupos (usuarios medios y diseñadores web) se les une un tercer grupo: los “sabios” de la web (no es un insulto). Los “sabios” vieron que un medio como Internet sin el uso de estándares se convertiría en el reino de la incompatibilidad si cada navegador interpretaba el HTML como le viniera en gana y se iba inventado “añadidos” que solo su navegador entendía. Muchos de esos “añadidos” se convierten en estándares de facto y posteriormente son adoptados (por ejemplo el objeto XMLHttpRequest introducido por Microsoft en el Internet Explorer 5.0 y que es una de las bases de AJAX o el elemento canvas introducido por Apple hace un par de años y que permite dibujos y animaciones dinámicas mediante JavaScript).

Uno de los estándares más importantes defendidos por el W3C es CSS que pretende cumplir el noble propósito de separar contenido de presentación. Hay una mala idea rondando por la cabeza de un montón de gente sobre el CSS: se habla muchas veces de CSS2 (y se empieza a hablar de CSS3) y, a pesar de que lo parezcan, esos números no son “versiones”, sino “niveles”, es decir, CSS2 se basa en lo establecido por CSS1 (existe alguna excepción), y el CSS nivel 3 se basa en lo dicho por CSS nivel 2.

Ningún motor de navegador (que yo sepa) soporta CSS nivel 2 completo. Actualmente todos los navegadores soportan CSS nivel 1 (aunque IE6 seguía teniendo problemas con los atributos !important), un gran soporte para CSS nivel 2 (muy desigual dependiendo del navegador y con muchas diferencias), y algunos navegadores implementan parte del nivel 3 de CSS (muchos utilizando vendor attributtes hasta que los borradores del nivel 3 sean definitivos). Así que los diseñadores web se tienen que conformar con utilizar CSS1 si quieren que su página se vea en todos los navegadores por igual. A pesar de que CSS2 fue publicado como recomendación final en Mayo de 1999 (existe un revisión CSS2.1 en progreso, y eso sí que es una versión de CSS2) los creadores de navegadores no se han podido poner de acuerdo en implementar un subconjunto correctamente, principalmente porque el navegador del usuario medio siempre ha sido bastante “rarito” sobre lo de seguir estándares.

El W3C no se puede quedar parado esperando a que todo el mundo implemente correctamente sus estándares, y mucho menos que al usuario medio les llegue la implementación de estos estándares. El W3C sigue definiendo estándares para las crecientes necesidades de Internet (protocolos, formatos, ideas…). En especial me interesan los guidelines (recomendaciones) del WAI. El WAI se dedica a proponer guías sobre el contenido, las herramientas, los navegadores, etcétera, para que la web sea accesible a todos los humanos, centrándose sobre todo en las discapacidades que puede tener algunos usuarios (problemas visuales y problemas motrices, sobre todo).

Así que un diseñador web cuando se pone a trabajar en una web tendrá delante de sí muchos problemas: el usuario medio, el mercado al que va dirigido la web, la primera impresión visual que quiere dar, elegir entre 3 o 4 “subestándares” de HTML, elegir qué aspectos de CSS2 y CSS3 podrá utilizar y que nivel de conformidad WAI quiere alcanzar (existe desde ninguno hasta el AAA).

Personalmente mi orden coste/beneficio de esos aspectos sería algo parecido al siguiente: el mercado/el usuario medio, validar XHTML, el diseño, validar CSS2 (con pizcas de CSS3, siempre degradando correctamente para navegadores que no lo soporten) y finalmente las directrices del WAI y la web semántica.

Sí, las cuestiones de accesibilidad son las últimas, pero eso no significa que no piense en ellas mientras diseño la página, significa que entre poder hacer un diseño elegante o uno accesible elegiré hacer el diseño elegante. ¿Por qué? Por el usuario medio. Es algo que casi no se ve en las estadísticas de navegación en Internet, pero se puede deducir fácilmente: alguien con deficiencias visuales o motrices no utilizará Internet Explorer, así que están fuera del grupo del “usuario medio”.

Internet Explorer hasta la versión 6 era un desastre proporcionando ayudas para la navegación por teclado (el mejor en este sentido es Opera) o para modificar el tamaño de representación de la página (de nuevo el mejor navegador es Opera). Hay gente que ni aumentando el texto de una página podría verla, por lo que disponen de “lectores de pantalla”. Creo que Windows viene con un lector de esos, pero está desactivado para todas las versiones no inglesas (creo que se llama Text2Speech), Mac OS X dispone de los servicios Speech, con únicamente voces inglesas, que no ofrecen mal resultado (excepto cuando leen textos en español), pero el navegador/lector de referencia siempre ha sido JAWS.

Normalmente cuando hago una página web las ayudas de teclado (implementadas de diferente forma y muy mal por los distintos navegadores) no son una prioridad, aunque la organización de la página (tal y como la leería un lector de pantalla) sí que lo es, colocando el contenido de la página lo más cercano al principio posible (excepto el título de la página y una pequeña barra de navegación). Esto es porque uno de los grupos más importantes en Internet son totalmente ciegos: los spiders de los buscadores. Podría parecer un desalmado por preocuparme de los buscadores y no de las personas con deficiencias visuales, pero son los buscadores los que proporcionan la mayor parte del tráfico a muchas páginas, y tráfico es igual a dinero.

Normalmente mi diseño ideal (como podéis ver en esta página) es un diseño de los que se llaman “elásticos”, es decir, definidos (en mi caso, en su mayor parte) utilizando como referencia el tamaño actual de la letra: si aumentáis o reducís la letra en vuestro navegador (tecla “Control” y las teclas “más” o “menos” para Firefox) el diseño de la página intentará mantenerse sin romperse un par de niveles hacia arriba y un par de niveles hacia abajo (el número de niveles que permite IE desde su menú de tamaño del texto). Así que si tenemos un ligero problema de visión o estamos cansados y queremos relajar la vista podemos ampliar el tamaño de letra sin perdernos el diseño y sobre todo sin perder contenido en los laterales de la ventana (siempre es desagradable tener que mover una barra de desplazamiento horizontal para leer una línea de texto). Siempre he pensado que si alguien necesitaba el texto más grande no le importaría tanto perder de vista el menú de navegación o incluso desactivar los estilos para poder ver el texto a un tamaño gigante. La otra ventaja del diseño de esta página es el ancho de la columna, que pretende ser lo suficientemente estrecho para que los ojos y la cabeza no se tengan que mover al “escanear” un texto (algo parecido a lo que hacen los diarios con sus columnas y LaTeX con sus márgenes de página por defecto).

Otro diseño muy popular es el diseño “fluido” o “líquido”. En este diseño los tamaños de las secciones de la página no se define según el tamaño de la letra sino del tamaño ventana del navegador (más bien el ancho de la ventana). Ese tipo de diseño permite aumentar el texto hasta niveles mucho mayores sin perder contenido (nunca aparecerán barras de desplazamiento horizontales). El problema de este diseño es que según aumentan las resoluciones de las pantallas las líneas se hacen cada vez más largas, lo que hace que tengas que mover ojos y cabeza para leer una línea y muchas veces la vista “saltará” de línea (al menos a mi me pasa). Es una solución “ideal”, porque evitas al usuario mover la mano para desplazar la pantalla horizontalmente pero le haces mover la cabeza.

Los defensores del diseño líquido (con defensores me refiero a los diseñadores web que lo utilizan) defiende que si te molesta el ancho de la línea siempre puedes reducir el tamaño de la ventana y el ancho de la línea se ajustará a tus preferencias. Otro hecho sobre el usuario medio: siempre navega con la pantalla del navegador totalmente maximizada (y muy pocos saben reducir reducen la pantalla de navegador para hacer su lectura más sencilla).

Así que tenemos que la ventaja del diseño elástico es que la mayor parte de los usuarios medios lo ven bien de primeras, mientras que en el diseño líquido todos los usuarios podrían verlo bien haciéndoles trabajar. Voy a incluir aquí el título de uno de los libros de cabecera de los expertos en usabilidad: Don’t Make Me Think (No Me Hagas Pensar).

Debo añadir que existe otro diseño, muy querido por los diseñadores de la vieja escuela, del que no hablaré mucho, pero que es muy utilizado por ofrecer control total al diseñador, muy fácil de implementar y que impide que las páginas se vean en todas las resoluciones menores a las que se diseñó. Desde luego no es la panacea de la usabilidad.

Según he visto en la web del INE en 1999 había en España un poco menos de un 1% de personas con problemas visuales (entre los que se incluyen cegueras totales y parciales, así como otros problemas visuales serios) y un poco más de un 1% de personas con problemas motrices (algunos de ellos no impedirían el uso normal de una página web).

Así que cuando diseñamos una página web debemos preguntarnos si es beneficioso arreglar cada uno de los fallos que obtenemos en los guidelines del WAI (y la mayoría no son analizables automáticamente) por ese 2% de la población. Sí, lo se, soy un cabrón capitalista desalmado.

Intento, siempre que sea posible, ampliar mi “mercado” hasta el 100%, pero si tengo que elegir entre un diseño elástico que un 90% de la gente verá bien a la primera y un diseño líquido que el 85% de la gente tendrá molestias después de utilizar durante un tiempo… qué queréis que os diga, utilizaré el que al 90% de la gente ven correctamente a la primera sin molestias, a pesar de que el 8% tenga que ampliar la letra y un 2% tengan que desactivar los estilos.

Todo depende del mercado, claro, y yo tengo un ejemplo claro, tengo un programa que simula diferentes tipos de daltonismo para comprobar que la combinación de colores no es totalmente desagradable o hace ilegible la página. Simplemente porque entre “mi mercado” hay una persona daltónica muy querida por todos nosotros (a la que siempre le pregunto qué que tal ve la página, sin importar que veo yo en el programa).

Así que ya veis, todo depende de con quién queráis comunicaros.

Ver entradas relacionadas

• Economía 101
• Pocos preservativos, muchas mujeres
• Azogue
• Si lo programadores hicieran aviones: ¿positivo o negativo?
• Don’t-pay-per-view