Pioneros y hacedores.

Fundamentos y Casos de Diseño de interacción con estándares de Accesibilidad y Usabilidad

Lorena Paz (Compiladora) y Víctor Malumián (Editor)

Ediciones Godot

Crearon este eBook accesible:

Julio Incarbone (Coordinador de DIEAU y Co-fundador de IAcoop) con el asesoramiento de Olga Carreras Montoto y Carlos Benavidez.

Notas legales sobre esta edición Epub.

Paz, Lorena (Comp) Pioneros y hacedores: fundamentos y casos de diseño de interacción con estándares de accesibilidad y usabilidad . - 1a ed. - Ciudad Autónoma de Buenos Aires: EGodot Argentina, 2013. 290 p.; 20x13 cm. ISBN 978-987-1489-72-5 1. Informática. 2. Gestión Informática. 3. Sitios Web. I. Título CDD 005.3

Pioneros y Hacedores.Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad. Lorena Paz (Comp.) y Víctor Malumián (ed.)

Corrección: Hernán López Winne

Traducciones: Sebastián Betti y Mariana Inés Calcagno

Diseño de tapa e interiores: Víctor Malumián

Editorial: Ediciones Godot

Mail editorial: Enviar mail

Facebook editorial: Ingresar a Facebook

Twitter editorial: Ingresar a Twitter

Lugar y año de creación: Buenos Aires, Argentina, 2013

Índice de contenidos

Introducción

Capítulo 1: El botón de los $300 millones.

Capítulo 2: Cómo usamos la web realmente.

Capítulo 3: Mobile Site vs. Full Site.

Capítulo 4: ¿Qué se mueve?

Capítulo 5: Diseño de interacción, prácticas de investigación y diseño en materiales digitales.

Capítulo 6: Diseño participativo para la inclusión digital.

Capítulo 7: Introducción a la Interacción Persona-Computadora.

Capítulo 8: Entre la Arquitectura y la Información.

Capítulo 9: Accesibilidad Web y SEO.

Capítulo 10: Desarrollo de un videojuego accesible.

Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad y usabilidad.

Capítulo 12: Ergonomía física y cognitiva.

Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking.

Capítulo 14: Accesibilidad de un recurso educativo.

Capítulo 15: Elaboración de una Normativa de Usabilidad y Accesibilidad Web.

Capítulo 16: Internacionalización Web.

Capítulo 17: Prácticas participativas en el Diseño de Interacción.

Capítulo 18: Diseño y desarrollo de un editor de texto accesible open-source.

Capítulo 19: Las métricas de accesibilidad desde una perspectiva práctica.

Glosario

Introducción, por Lorena Paz

Mini biografía del autor

Socióloga especializada en Tecnologías de la Información y la Comunicación. Dirige la Especialización en Diseño de Interacción con estándares de accesibilidad y usabilidad en la Universidad Tecnológica Nacional DIEAU . Miembro de la Asociación Civil: Laboratorio de Ideas Cooperativas LabID.org . Co-fundadora de "Interacción Accesible” Cooperativa de Trabajo Tecnológico IAcoop.

Más información:

Ingresar al sitio web del autor

Twitter: @lorenapaz

Notas Introductorias

“...es necesario aceptar que existen múltiples órdenes de la verdad, múltiples modos de existencia, cuyas condiciones de felicidad o infelicidad deberán ser establecidas, con sumo cuidado, por el investigador.” Bruno Latour

Esta selección de textos surge marcada por una presencia casi invisible pero abarcativa: la sociología, el campo de estudio por excelencia de las interacciones sociales. Pioneros y Hacedores es material de reflexión para la investigación contemporánea de los procesos del comportamiento humano en la interacción. El asunto es de larga data: pionero y hacedor fue el primer Homo habilis que creó una herramienta para interactuar con él mismo, con sus pares y con su medio. Lo hizo seguramente haciendo diseño centrado en él, en el usuario... Pero el foco aquí está dado por el tipo particular de interacción y de comportamiento que provoca el ambiente digital con la presencia de interfaces, pantallas, consolas, computadoras, cajeros, videojuegos, móviles, controles remotos, etc. Las nuevas disciplinas que emergen al ritmo de los transistores y de los microchips no pueden ser completamente mensurables; sin embargo, ejercen conocimiento científico: describen, prueban, cuantifican. Y producen innovación semántica con la aparición de nuevos términos como: “hipervínculo”, “usabilidad”, “narración transmedia”. Tienen su propio método, uno cíclico, iterativo, que como una espiral pretende descubrir la complejidad más absoluta: los comportamientos, los motivos de las personas. Todo un gran esfuerzo para dilucidar, a veces, un click en una interfaz gráfica…

El origen de esta selección de textos nace como una necesidad académica: contar con material bibliográfico para formar en diseño de interacción con estándares de accesibilidad y usabilidad. Por lo tanto, el trabajo editorial se justifica por la ausencia o falta de sistematización de fundamentos y casos de experiencias de investigación, diseño y desarrollo de diseño de Interacción en nuestro idioma. Colateralmente, al estar las Tecnologías de la Información y el Conocimiento (TIC) presentes en casi todos los ámbitos de la existencia humana, se torna ineludible el estudio de su impacto, y representa un aporte al campo de la Etnografía Digital.

En esta primera edición se publican trabajos oriundos de Centroamérica, Sudamérica, Norteamérica, Australia y Europa de algunos pioneros y hacedores en Arquitectura de la Información, Diseño Centrado en el Usuario, Usabilidad y Accesibilidad, Ergonomía, Psicología, Diseño participativo y Co-desarrollo.

Los capítulos, mediante casos o fundamentos, tratan temas que pretendimos amplios, y que van desde ergonomía física y cognitiva, al desarrollo de un videojuego y de un recurso educativo accesible, de métodos y dispositivos para evaluar la interacción con la nueva televisión interactiva a las técnicas de inspección e indagación heurística, a la Internacionalización de la web y las normativas gubernamentales para hacer web accesibles y usables. Se presentan así casos de diseño participativo y co-desarrollo tanto con niños como con excluidos de la Sociedad de la Información y el Conocimiento, como lo son algunos Pueblos Originarios o los adultos mayores. Con la compilación de Pioneros y Hacedores se buscó brindar material para poder comprender accesibilidad sin saber de programación y a su vez profundizar en lenguajes y codificación. Iniciarse en Human Computer Interaction y en Investigación de Usuarios, conocer el origen del diseño de interacción, tanto como debatir su futuro. Pero también, y desde el oficio sociológico de develar, se busca poner sombra al resplandor de las TIC ya que estas muchas veces no informan ni comunican, no producen interacción, y por lo tanto no propician la generación de conocimiento. Hoy, que estamos insertos en un contexto de multiplataformas y se nos incita a creer en el sueño dorado de vidas interactivas, pero en los hechos, la actual sociedad que se auto proclama de ser de la información y el conocimiento, info-intoxica e info-excluye. Comparto la idea de Jorge Arango cuando dice que “(...) las personas que diseñamos artefactos digitales tenemos un compromiso ético de lograr que la información que publicamos sea fácil de encontrar y entender”. No queda duda acerca de que la accesibilidad web es un derecho humano que permite la equidad ante el fenómeno del uso masivo de dispositivos digitales. Asumiendo que la inclusión social hoy requiere de inclusión digital, ¿no tendrán los ingenieros de sistemas y los diseñadores una responsabilidad social mayor? ¿Y no tendrán los centros educativos la responsabilidad de profundizar conocimiento en el procesamiento humano de la información? Claramente, como lo apuntan Yusef Hassan Montero y Sergio Ortega Santamaría en su capítulo introductorio a la Interacción Persona Computadora, este campo se nutre de una gran variedad de teorías y evidencias empíricas tomadas de diferentes disciplinas, como la sociología, la antropología y el corpus teórico de la psicología cognitiva fusionadas con la informática. Si la conducta humana siempre ha sido un enigma y un desafío, las interfaces se nos presentan como un constructo metodológico que, a la par que devela, oculta. Para poder iluminar es necesario profundizar en métodos formales de investigación en diseño de interacción, como lo hace Jonas Löwgren. Y, asumiendo que los aspectos técnicos como poder comprender código y estándares de la WC3 (World Wide Web Consortium) presentan tanto gran complejidad como simpleza, hay una doble apuesta en este libro: asumir la necesidad de profundizar conocimiento complejo y a la vez reconocer, como lo señala Emmanuelle Gutiérrez y Restrepo que “no hacen falta conocimientos que no sean aplicables a otros órdenes de nuestra vida, y sus requisitos son todos de puro sentido común para dar la oportunidad a todos los humanos de participar en la Sociedad de la Información y del Conocimiento de manera equitativa”. Pero, cuando el respeto por los Derechos Humanos no convoca, ni la obligación legal constriñe, se incita a los hacedores de negocios en la web al respeto por los estándares de accesibilidad como una ventaja; a tal fin, Olga Carreras Montoto describe las buenas prácticas que pueden realizar los profesionales SEO (Search Engine Optimization) para lograr posicionamiento en motores de búsqueda.

En el núcleo de pensamiento de este proyecto editorial está presente el Diseño Universal, una apuesta política y económica porque materializa la unión natural entre el Diseño Centrado en el Usuario y la sostenibilidad. Por eso, la compilación de Fundamentos y Casos de Diseño de Interacción con estándares de accesibilidad y usabilidad es material de lectura para personas interesadas en diseño centrado en el usuario en particular y también para personas comprometidas con el impacto de las tecnologías de la información y la comunicación en general. Finalmente, en el kernel de estos textos sobre tecnología está la emoción y la rigurosidad, porque estuvieron presentes en quienes aunaron la casuística necesaria para crear un método y difundirlo: Don Norman, Jakob Nielsen, Steve Krug, y Jared Spool. Un legado de los pioneros que es buena expectativa para que las interacciones mediadas por artefactos vehiculicen la interacción entre humanos.

Lorena Paz, octubre 2013

Agradecimientos

A los autores que han cedido sus derechos, reescrito y escrito especialmente para este libro.

Hernán Thomas por introducirme en la sociología de la tecnología.

Julio Incarbone, por infalible compañero de ruta en DIEAU .

Sebastian Betti por el compromiso con el proyecto desde sus inicios.

Lilibeth Valdés Payo por su colaboración en la corrección entre pares.

Martín Szyszlican, por compañero de aventuras tecno-etnográficas.

Al Equipo de Investigación-Acción Sinapsis , un espacio abierto en construcción.

todas las personas comprometidas en los usos sociales de las TIC para el Desarrollo Humano.

Victor Malumían, de Ediciones Godot , que un día en un taxi cuando le conté que quería hacer este libro, exclamó entusiasta: ¡yo lo edito! y lo hizo.

Capítulo 1: El botón de los $300 millones, por Jared M. Spool

Mini biografía del autor

Desarrollador y programador y experto en técnicas de prototipado de baja fidelidad. Es un miembro histórico del Special Interest Group on COMPUTER-HUMAN INTERACTION (SIGCHI). Profesor en la Escuela de Ingeniería de lnstituto Gordon de la Universidad de Tufts. Es considerado un referente en estas disciplinas por haber fundado en los años ochenta la consultora líder en investigación y desarrollo de productos web “User Interface Engineering” y por haber escrito este famosísimo artículo.

Más información:

Ingresar al sitio web del autor

Twitter: @jmspool

Publicado originalmente el 14 de enero de 2009

Traducción: Mariana Inés Calcagno

Texto original: Ingresar al texto original del capítulo.

El botón de los $300 millones

Cuando Luke Wrableski estaba escribiendo su famoso libro Web Form Design: Filling the blanks (Diseño Web de Formularios: Llenando los espacios en blanco) me preguntó si podía pensar un ejemplo en el que un cambio en el diseño de un formulario pudiera lograr una diferencia importante en los resultados de un negocio. “¿Quieres decir algo así como 300 millones en nuevas ganancias?”, respondí. “Sí, algo así”, dijo Luke. Entonces fue cuando escribí este artículo, que luego publicó en su libro.

Es difícil pensar en un formulario que sea más simple que éste: dos campos, dos botones y un link. Sin embargo, resulta que este formulario estaba impidiendo a los clientes hacer compras en un importante sitio de E-commerce, con una ganancia calculada en $300.000.000 al año. Y lo que era peor: los diseñadores del sitio no tenían ni idea de que esto estuviera pasando. El formulario era simple. Los campos eran “Dirección de correo electrónico” y “Contraseña”. Se trataba del ingreso al sitio, un tipo de formulario que los usuarios llenan todo el tiempo. Los botones eran “Ingresar” y “Registrarse”; el link, “¿Olvidó su contraseña?” ¿Cómo podrían tener problemas con él?

El problema no estaba tanto en la disposición de los elementos del formulario (layout) sino en el lugar en el que se ubicaba. Los usuarios lo encontraban luego de haber llenado su carrito de compras y después de haber presionado el botón “Comprar” (Checkout button), pero antes de ingresar la información para pagar. El equipo vio que este formulario les impedía a los usuarios frecuentes comprar más rápido. A los clientes que compraban por primera vez no les importaría tomarse algo de tiempo extra para registrarse porque, después de todo, volverían en otra ocasión y apreciarían la rapidez en las compras subsiguientes. Todos ganaban, ¿no es cierto?

“No estoy acá para iniciar una relación”

Realizamos pruebas de usabilidad con usuarios que necesitaran comprar productos del sitio. Les pedimos que trajeran sus listas de compras y les dimos el dinero para realizarlas. Lo único que debían hacer era completar la transacción.

Estábamos equivocados acerca de los clientes que compraban por primera vez. Sí les importaba la registración. En general, no les gustaba tener que hacerlo. Como nos dijo uno de ellos, “No estoy aquí para empezar una relación. Sólo quiero comprar algo”.

Algunos de ellos no podían recordar si era realmente la primera vez que compraban, molestándose cada vez que las distintas combinaciones de correo y contraseña que ingresaban fallaban. Nos sorprendió tal resistencia al registro. Sin saber incluso lo que implicaba el proceso de registro, todos los usuarios que clickeaban el botón lo hacían con un gesto negativo. Algunos expresaban verbalmente cómo los comerciantes sólo querían los datos para infectarles las casillas con spam que no querían. Algunos imaginaban otros nefastos propósitos de la evidente intención de invadirles la privacidad. (En realidad, el sitio no pedía ningún dato que no fuera necesario para la compra: nombre, dirección de envío, domicilio fiscal y modo de pago.)

No tan bueno para usuarios frecuentes tampoco

Los usuarios frecuentes no estaban mucho más contentos tampoco. Salvo por algunos que recordaban la información de registro, la mayoría dudaba frente al formulario. No podían recordar la dirección de correo que usaban o la contraseña. Olvidar la dirección de correo correspondiente era problemático, muchos tenían varias casillas o las habían cambiado a lo largo de los años.

Cuando un comprador no podía recordar la dirección o contraseña, ingresaba diferentes opciones varias veces. Estos intentos rara vez funcionaban. Algunos le pedían al sitio que les enviara la contraseña por correo electrónico, lo cual es un problema en el caso de no recordar la dirección ingresada inicialmente el registro.

(Más tarde hicimos un análisis en la base de datos, y resultó que el 45% de todos los clientes se había registrado más de una vez en el sistema, algunos hasta 10 veces. También analizamos cuánta gente había solicitado la contraseña por correo, para descubrir que el número llegaba hasta aproximadamente a 160.000 por día. El 75% de estas personas nunca había tratado de completar la compra que habían comenzado.)

El formulario, diseñado para favorecer el proceso de compra, terminaba por ayudar sólo a un pequeño porcentaje de clientes. (Incluso muchos de ellos tampoco eran ayudados, ya que les tomaba el mismo esfuerzo actualizar cualquier dato incorrecto, como cambiar las direcciones o ingresar nuevas tarjetas de crédito). Contrario a su intención inicial, el formulario impedía ventas, muchas ventas.

La solución de los $300 millones

Los diseñadores resolvieron el problema de una manera muy simple: sacaron el botón “Registrarse”. En su lugar, pusieron un botón nuevo: “Continuar”, con un simple mensaje. “No es necesario crear una cuenta para hacer una compra en este sitio. Cliquee “Continuar” para terminar su compra. Para acelerar el proceso de sus futuras compras, puede crear una cuenta durante el proceso”.

Los resultados: el número de clientes que concretaba las compras subió un 45%. El primer mes se produjeron unos 15 millones de ganancia adicional. El primer año, el sitio produjo un extra de 300 millones.

En mi contestador automático está el mensaje que recibí del CEO del vendedor de los 25 billones, la primera semana en la que vieron los números de las ventas luego del rediseño. Es un mensaje muy simple: “¡Spool, sos el mejor!”. No necesitaba un mensaje más complejo. Lo único que hicimos fue cambiar un botón.

Capítulo 2: Cómo usamos la web realmente, por Steve Krug

Mini biografía del autor

Steve Krug es especialista en Experiencia de Usuarios, ha pasado más de veinte años haciendo test de usabilidad. Ha escrito los dos libros más referenciados en este campo: Don’t Make Me Think: A Common Sense Approach to Web Usability y Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems. Es mundialmente famoso por las charlas y workshops que tres veces al año dicta, muchas veces en compañía del famoso Arquitecto de la Información Lou Rosenfeld.

Más información:

Ingresar al sitio web del autor

Título Original del libro: Don’t Make Me Think

Ver libro en Amazon.

Traducción: Mariana Inés Calcagno

Cómo usamos la Web realmente

¿Por qué las cosas están en el último lugar en el que buscamos? Porque cuando las encontramos dejamos de buscarlas. Adivinanza infantil

En los últimos cinco años he pasado mucho tiempo observando a la gente usar la Web, y lo que más me ha sorprendido es la diferencia que existe entre el modo en que creemos que la gente usa los sitios y la manera en la que realmente sucede.

Cuando creamos sitios, actuamos como si los usuarios fueran a estudiar atentamente cada página, leyendo minuciosamente el texto que construimos con detalle, descubriendo la forma en la que organizamos la información y evaluando las opciones antes de decidir qué botón apretar.

Lo que en realidad suelen hacer los usuarios la mayoría de las veces (si tenemos suerte) es echar un vistazo general a cada nueva página, ojear o “escanear” rápidamente partes del texto y cliquear en el primer enlace que capte su interés o se parezca vagamente a lo que están buscando. Incluso hay grandes sectores de la página que ni se miran.

Pensamos “literatura de calidad” (o al menos “folleto de producto”), cuando la realidad del usuario está mucho más cercana a “cartel publicitario que pasa a 100 kilómetros por hora”.

Como se podrán imaginar, es un poco más complicado que esto, y depende del tipo de página, lo que el usuario pretenda hacer, cuán apurado esté, etcétera. Pero esta visión simplificada es mucho más cercana a la realidad de lo que podemos suponer.

Es lógico que visualicemos un usuario más racional y atento al diseñar nuestros sitios. Resulta natural asumir que todo el mundo usa la web del mismo que nosotros lo hacemos, y –al igual que todos- tendemos a pensar que nuestro comportamiento es mucho más ordenado y sensato de lo que realmente es.

Sin embargo, si lo que quieren es diseñar páginas efectivas, deberán aprender a lidiar con estos tres hechos sobre el uso real de la web.

Hecho de la realidad #1 Las páginas no se leen, se hojean.

Uno de los pocos hechos bien documentados de la web es que los usuarios suelen dedicar muy poco tiempo a la lectura en la mayoría de los sitios 1. En lugar de ello, se tiende a “escanear” o leer por encima, buscando palabras o frases que llamen la atención.

La excepción, por supuesto, son las páginas que contienen noticias, informes, o descripciones de productos. Pero incluso en esos casos, si el documento tiene más de unos pocos párrafos, es posible que sean impresos, dado que es más fácil y rápido leer desde papel que desde la pantalla. ¿Por qué hojeamos?

Normalmente estamos apurados. Gran parte de nuestro uso de la Web está motivado por un deseo de ahorrar tiempo. Como consecuencia de esto, los usuarios suelen actuar como tiburones: necesitan estar en movimiento, o se mueren. Simplemente no cuentan con el tiempo para leer más de lo necesario.

Sabemos que no necesitamos leer todo. En la mayoría de las páginas, estamos interesados únicamente en una porción de lo que hay en ella. Sólo buscamos las partes que se ajustan a nuestros intereses o a la tarea que tenemos entre manos; el resto es simplemente, irrelevante. Hojeando es como encontramos las porciones relevantes.

Somos buenos haciéndolo. Hemos estado hojeando diarios, revistas y libros toda la vida para encontrar las cosas que nos interesan, y sabemos que funciona.

El efecto red es muy similar al clásico dibujo de Gary Larson, Far Side, sobre las diferencias entre lo que suele decirse a los perros y lo que ellos realmente oyen. En la historieta, el perro (llamado Ginger) parece estar escuchando atentamente a su amo mientras este le da una charla seria sobre no hurgar más en la basura. Pero desde el punto de vista del perro, lo único que el dueño dice es “bla bla GINGER, bla bla bla GINGER bla bla bla”.

Lo que vemos cuando miramos una página web depende de lo que tengamos en mente, que usualmente implica una pequeña porción de lo hay en ella.

Al igual que Ginger, tendemos a focalizar en las palabras y las frases que parecen ajustarse a) a la tarea que tenemos que realizar, b) nuestros intereses del momento o de las circunstancias, y, desde luego c) las palabras clave disparadoras de reacciones, programadas ya en nuestro sistema nervioso, como “gratis”, “liquidación” y “sexy”.

Hecho de la realidad #2 No tomamos óptimas decisiones. Nos conformamos con lo suficiente.

Al diseñar nuestros sitios, solemos asumir que los usuarios van a echar un vistazo general, considerar todas las opciones disponibles y optar por la mejor.

Sin embargo, lo que en realidad sucede la mayoría de las veces es que no se elige la mejor opción, sino la primera opción razonable, una estrategia conocida como “satisficing” 2. En cuanto encontramos un enlace que en apariencia puede llevarnos hacia lo que buscamos, hay una gran chance de que lo hagamos click sobre él.

Había notado este comportamiento durante años, pero su significado no me resultó del todo claro hasta que leí el libro de Gary Klein, Sources of power: How People Make Decisions [Fuentes de Poder: cómo la gente toma sus decisiones] 3. Klein pasó quince años estudiando la forma natural de toma de decisiones: el modo en que bomberos, pilotos, maestros del ajedrez u operadores de plantas de energía nuclear toman importantes decisiones en situaciones reales, presionados por el tiempo, sin objetivos precisos, con información limitada y condiciones cambiantes.

El equipo de observadores de Klein trabajaron en el primer estudio (con comandantes del cuerpo de bomberos en escenas reales de incendios) desde el modelo generalmente aceptado sobre la toma racional de decisiones: frente a un determinado problema, las personas suelen reunir la información necesaria, identifican posibles soluciones y eligen la más adecuada. Partieron de la hipótesis de que debido al alto nivel de riesgo y la extrema presión del tiempo, los capitanes serían capaces de comparar sólo dos opciones, una presunción que consideraban prudente. Finalmente, sucedió que los comandantes no compararon ninguna opción. Tomaron el primer plan razonable que se les vino a la mente y evaluaron rápidamente los problemas. Si no encontraban ninguno, ya tenían resuelto su plan de acción.

Entonces, ¿por qué los usuarios de la Web no buscan la mejor opción posible?

Normalmente estamos apurados. Y como plantea Klein “la optimización es difícil y lleva tiempo. Satisficing (tomar la primera decisión razonable) es más eficiente”.

No hay consecuencias graves en caso de error. A diferencia de lo que deben enfrentar los bomberos, las consecuencias de tomar decisiones equivocadas en la web se solucionan presionando una o dos veces el botón de “volver”, haciendo del satisficing una estrategia efectiva. Asumimos, claro, que la página carga rápidamente; si esto no fuera así, deberemos decidir con más cuidado, una de las tantas razones por las que a la mayoría de los usuarios web no les gustan las páginas que tardan en cargar.

Evaluar las opciones no siempre implica una mejora de las oportunidades. En los sitios mal diseñados, esforzarse en tomar la decisión correcta no ayuda demasiado. Normalmente resulta mejor seguir el primer instinto y recurrir al botón “Volver” si no funciona.

Adivinar es más divertido. Implica menos trabajo que evaluar las opciones, y si la suposición es correcta, resulta muy rápida. Además le otorga un elemento de suerte –la posibilidad placentera de encontrarse con algo bueno y sorprendente.

Sin embargo, esto no significa que no haya usuarios que evalúen y comparen las opciones antes de hacer click. Depende de factores como su estado de ánimo, cuan apurados estén, y el nivel de confianza que le tengan al sitio.

Hecho de la realidad #3 No nos interesa averiguar el funcionamiento de las cosas. Nos las arreglamos.

Una de las cosas que resultan más evidentes al hacer cualquier prueba de usabilidad, ya sea que se estén testeando sitios web, software o electrodomésticos, es el grado en el que la gente hace uso de las cosas todo el tiempo sin entender cómo funcionan, o con ideas incorrectas acerca de ello.

Frente a cualquier tipo de tecnología, muy pocas personas se toman el tiempo de leer las instrucciones. En lugar de eso, seguimos adelante y nos las arreglamos, inventando historias propias y vagamente verosímiles de lo que estamos haciendo y por qué funcionan.

Normalmente me recuerda a la escena final de “El príncipe y el mendigo”, cuando el verdadero príncipe descubre que su doble ha estado usando el Sello Real de Inglaterra como un cascanueces durante su ausencia. (Es lógico: para él, el sello es sólo un grande y pesado pedazo de metal.)

Y el hecho es que, esta es el modo en que hacemos las cosas. He visto a mucha gente usar software y sitios web de manera eficiente en formas que no se parecen en nada a lo que los diseñadores pensaron.

Mi ejemplo favorito es la gente (y he visto docenas de ellos yo mismo) que escribe la URL completa de un sitio en el buscador de Yahoo, no para buscar el sitio por primera vez, sino cada vez que quieren visitarlo, incluso varias veces por día en algunos casos. Si se les pregunta, resulta evidente que para muchos de ellos, Yahoo es Internet, y que esa es la forma correcta de usarla. 4

Lo interesante es que esta estrategia de “arreglárselas sobre la marcha” no es exclusiva de los principiantes. Incluso los usuarios con conocimiento técnico tienen a veces huecos inesperados en su comprensión sobre el funcionamiento de las cosas. (No me sorprendería saber que el mismísimo Bill Gates manejara algún aparato tecnológico utilizando este recurso.) ¿Y por qué ocurre esto?

No nos parece importante. A la mayoría de nosotros no nos importa entender cómo funcionan las cosas siempre y cuando las podamos usar. No es por falta de inteligencia, sino por falta de interés. En nuestro esquema de prioridades, simplemente no es importante. 5

Si encontramos un método que funciona, nos quedamos con él. Cuando encontramos una estrategia que funciona -no importa si bien o mal- no solemos buscar otra mejor. Usaríamos un mejor método si nos trabáramos con algo, pero casi nunca nos dedicamos a buscarlo.

Siempre resulta interesante ver a los diseñadores y desarrolladores web mientras observan su primera prueba de usabilidad. Se sorprenden la primera vez que ven a un usuario cliquear sobre algo completamente inapropiado. (Por ejemplo, cuando ignoran un botón precioso, grande y gordo que dice “Software” en el menú, que dice al algo así como “Bueno, estoy buscando software, entonces me parece que voy a cliquear en ‘cosas baratas’ porque lo barato siempre es una buena opción”). El usuario podrá encontrar, eventualmente, lo que está buscando pero entonces los observadores no van a saber si deberían estar satisfechos o no.

La segunda vez que pasa, se lo verá gritando: “¡Sólo haga click en ‘software’! La tercera, pensarán: ¿para qué hacemos esto? Y es una pregunta: si la gente logra arreglárselas tan bien, ¿importa realmente si lo “entendieron”? La respuesta es que sí importa, y mucho, porque aunque arreglárselas funcione a veces, tiende a ser ineficaz y propenso a errores. Por otro lado, si los usuarios “entienden”: Hay muchas más chances que encuentren lo que están buscando, lo que es bueno para ellos y para nosotros. Hay una mayor posibilidad de que comprendan todo lo que el sitio tiene para ofrecer y no sólo las partes con las que se tropiezan en el camino. Se aumenta la oportunidad de guiar a los usuarios hacia las partes que más queremos que vean.

Se sentirán mejor y más seguros usando el sitio, lo que los hará regresar. Podemos convencerlos con un sitio en el que puedan arreglárselas hasta que alguien desarrolle otro que logre hacerlos sentir bien y confiados Si la vida te da limones…

A esta altura deben estar pensando (dada esta pálida imagen de los usuarios de la web): “¿Por qué no me dedico a vender detrás de un mostrador todo el día? Al menos mis esfuerzos serían reconocidos.” ¿Entonces qué deberíamos hacer?

La respuesta es que si su público se comporta como si le estuvieran diseñando carteles de ruta, entonces diseñen geniales carteles de ruta.

Referencias

1. Consultar Nielsen, Jakob, “How users read on the web”, octubre, 1997, disponible en www.useit.com.

2. El economista Herbert Simon acuñó el término (una fusión entre “satisfacer” y “ser suficiente”) en Models of Man: Social and Rational Wiley, 1957.

3. En el MIT Press, 1998.

4. De la misma manera, he conocido a muchos usuarios de AOL que piensan que AOL es Internet. Buenas noticias para Yahoo y AOL.

5. A los desarrolladores web les cuesta normalmente entender, incluso creer, que la gente sienta esto, porque generalmente son personas particularmente interesadas en saber el funcionamiento de las cosas.

Capítulo 3: Mobile Site vs. Full Site, por Jakob Nielsen

Mini biografía del autor

Ingeniero de interfaces, se doctoró en diseño de interfaces de usuario y ciencias de la computación en la Universidad Técnica de Dinamarca. Ha trabajado en usabilidad para Bellcore, IBM y Sun Microsystems. Ha escrito numerosos libros en la materia, entre los que se destacan: Hypertext and Hypermedia, Usability Engineering, Designing Web Usability, E-Commerce User Experience, Homepage Usability: 50 Websites Deconstructed, Prioritizing Web Usability, Mobile Usability.

Jakob Nielsen es mundialmente reconocido por autodenominarse el padre de la palabra usabilidad y por seguir escribiendo este tipo de textos cortos, simples y efectivos en la materia.

Más información:

Ingresar al sitio web del autor

Ver capítulo original.

Traducción: Mariana Inés Calcagno

Corrección Técnica: Sebastián Betti

Mobile Site vs. Full Site 1

Basados en pruebas de usabilidad realizadas en cientos de sitios, quedan claras las siguientes pautas para realizar sus versiones mobile:

"Si cuenta con el presupuesto necesario para hacerlo, construya la versión mobile de su sitio por separado. Cuando los usuarios acceden a los sitios en sus dispositivos móviles, el nivel de usabilidad medido es mucho más alto que para las versiones web."

Una aplicación mobile puede resultar aún mejor – al menos por ahora.

Si un usuario móvil llega a la URL de la versión web de su sitio, redirecciónelo automáticamente a la versión mobile. Lamentablemente, algunos buscadores no rankean los sitios mobile lo suficientemente alto, por lo que a menudo los usuarios son guiados hacia las versiones web, que ofrecen una experiencia de usuario altamente superior.

Ofrezca un enlace claro que lleve a los usuarios de la versión web a la versión mobile, además del redireccionamiento mencionado.

Ofrezca un enlace claro de la versión mobile a la versión web para aquellos (pocos) usuarios que necesiten acceder a funciones especiales que sólo se encuentren en la versión completa.

Hemos realizado pruebas en cientos de sitios en sus versiones mobile y web en todas las plataformas actualmente populares (incluyendo iPhone, Android, Windows Phone y Blackberry). Los resultados encontrados fueron los mismos para todos los tipos de teléfonos, por lo que no hablaremos de dispositivos en particular.

Las pautas son diferentes para las tablets grandes (10 pulgadas, como la Apple iPad, Lenovo IdeaPad, Samsung Galaxy, etc.), en las que las versiones web funcionan razonablemente bien. Para las tabletas pequeñas (de 7 pulgadas, como la Amazon Kindle Fire) lo ideal sería crear un tercer diseño para dispositivos de tamaño mediano, aunque las mayorías de las compañías pueden arreglárselas haciendo que el servidor les entregue la versión mobile a los usuarios del Kindle Fire.

Sitios Mobile

Para exponer por completo las pautas para la realización de sitios mobile necesitaríamos 300 páginas, por lo que es imposible abarcarlas aquí. Las ideas básicas son:

Cortar funcionalidades, para eliminar aquellos elementos que no sean fundamentales en el uso del dispositivo móvil.

Cortar contenido, para reducir el conteo de palabras y derivar la información secundaria hacia páginas secundarias; y

Agrandar los elementos de la interfaz, para resolver el problema del “dedo gordo”

El desafío es eliminar funciones y reducir la cantidad de palabras sin limitar la selección de productos. Un sitio mobile debería tener menos información sobre cada producto y menos cosas que los usuarios pueden hacer con ellos, pero el rango de items debería permanecer igual al de la versión web. Si los usuarios no pueden encontrar un producto en un sitio mobile, asumen que la compañía no lo vende y lo buscan en otro lado.

Entonces, por ejemplo, el sitio mobile de una empresa inmobiliaria debería mostrar todas las casas en venta de un barrio determinado, no sólo las que despiertan mayor interés. (Aunque podría ofrecer como atajo una pequeña lista de las propiedades más populares para que los usuarios puedan acceder de un solo click.). Pero el sitio mobile podría eliminar funcionalidades “esotéricas” – como el historial de venta de propiedades– y ofrecer a los usuarios que quieran acceder a esa información un enlace al sitio web en su versión completa.

¿Por qué las versiones web de los sitios no sirven para el uso de dispositivos móviles?

Es común hoy en día escuchar a la gente sostener lo siguiente: los usuarios mobile tienen cada vez mayores expectativas respecto de lo que deberían poder hacer con sus dispositivos, por lo tanto, la eliminación de cierto contenido o funcionalidades inevitablemente desilusionará a algunos. De esta manera, continúa (erróneamente) el argumento, es mejor entregarles el sitio en su versión completa a todos, incluso a los usuarios mobile.

Este análisis es erróneo porque asume que la elección está entre la versión completa del sitio web y la versión mobile recortada. Sin embargo, cualquier sitio mobile que cumpla con las pautas de usabilidad proporcionará los enlaces hacia el sitio web donde sea necesario, de modo que los usuarios tengan acceso a todo el contenido y las funcionalidades en caso de que lo requieran.

El desafío del diseño es hacer los recortes de tal manera que el sitio mobile satisfaga casi todas las necesidades de los usuarios. Si se cumple esta meta, el esfuerzo adicional de interacción de clickear en el enlace al sitio web, ocurrirá muy raramente.

Es cierto, hemos visto algunos sitios mobile diseñados pobremente que difícilmente podrían satisfacer las necesidades mobile de cualquiera. Pero un mal diseño no es razón suficiente para tirar todo por la borda y abandonar una pauta correctamente documentada. (De hecho, si malas interfaces fueran razones suficientes para rechazar una categoría de diseño entera, no tendríamos Internet en absoluto. Hay montones de sitios poco usables dando vueltas por ahí. Pero esto no significa que no podamos diseñar buenos sitios siguiendo las normas que los malos sitios violan)

El correcto análisis sería el siguiente:

Para la gran mayoría de la tareas, los usuarios mobile obtendrán una mejor experiencia de usuario a través de un sitio mobile bien diseñado que de su versión web.

Para una pequeña cantidad de tareas, los usuarios mobile serán apenas retrasados al clickear sobre el enlace a la versión web.

Una gran ganancia que se experimenta frecuentemente compensará cómodamente a un pequeño esfuerzo adicional que ocurre raramente.

Un segundo argumento en contra de los sitios mobile es que se podría simplemente optimizar el sitio web para su uso mobile en primer lugar. Por lo tanto, darles a los usuarios la versión completa no debería causarles ninguna molestia. Aunque es cierto, este análisis no tiene en cuenta la sanción impuesta a los usuarios web cuando se les da un diseño que es menos óptimo para pantallas más grandes y mejores dispositivos de entrada. Si los usuarios web fueran una pequeña minoría sería aceptable, pero casi todas los sitios web reciben sustancialmente más tráfico (y más transacciones) de sus usuarios web que de los usuarios mobile. Por lo tanto, aunque queramos atender las necesidades de estos últimos, no podemos dejar de lado a los usuarios “de escritorio”, quienes, después de todo, pagan la mayor parte de nuestros salarios.

¿Lo básico? La interfaz de la plataforma de los usuarios de escritorio difiere de la interfaz de la plataforma de los usuarios mobile en muchos aspectos, incluídos las técnicas de interacción, cómo la gente lee, el contexto de uso y el número de cosas que pueden ser captadas a simple vista. La desigualdad es simétrica: los usuarios mobile necesitan un diseño diferente al de los de escritorio. De la misma manera, estos últimos necesitan un diseño diferente al de los primeros.

Referencias

1. Llamamos Mobile Site a la versión de un sitio web diseñada para ser vista en dispositivos móviles y Full Site a su versión web o “de pantalla completa”.

Capítulo 4: ¿Qué se mueve?, por Don Norman

Mini biografía del autor

Donald A. Norman es profesor emérito de ciencia cognitiva en la Universidad de California y profesor en Northwestern y en Stanford. Trabaja desde la ciencia cognitiva a la ingeniería de la usabilidad. Es mundialmente reconocido como un referente en usabilidad, ha escrito numerosos libros en la materia, entre los que se destacan: Direct manipulation interfaces, User Centered System Design, New Perspectives on Human-Computer Interaction, The Design of Everyday Things, The Psychology of Everyday Things, Emotional Design, The Design of Future Things. Cofundó el Nielsen Norman Group.

Más información:

Ingresar al sitio web del autor

Ver capítulo original.

Traducción: Mariana Inés Calcagno

¿Qué se mueve?

Estaba en Asia, dando una charla. Me habían dado un control remoto para pasar mis diapositivas. El aparato tenía dos botones, uno arriba del otro. No me gustan las presentaciones tradicionales con porciones largas de texto que el orador lee a la audiencia, así que tengo una sola regla: “Sin palabras”. La mayoría de mis diapositivas son fotografías. Estaba todo listo para la primera imagen, pero cuando apreté el botón de arriba para avanzar, fui engañado: en lugar de ir hacia adelante en la presentación, retrocedí.

¿Cómo pudo pasar esto?, me pregunté. “Arriba” siempre significa “hacia adelante” y “abajo”, “hacia atrás”. El mapping es claro y evidente. Si los botones hubieran estado uno al lado del otro, entonces sí el control habría sido ambiguo: ¿qué viene primero, derecha o izquierda? No queda claro. Pero este control estaba usando el mapping correcto de arriba y abajo. ¿Por qué estaba mal diseñado?

Decidí utilizar la situación como ejemplo para la audiencia. Les mostré el aparato y pregunté: “¿qué botón debería apretar para ir a mi próxima diapositiva?, ¿el de arriba o el de abajo?” Para mi gran sorpresa, las respuestas estaban muy divididas. Algunos pensaban que debía ser el de arriba, al igual que yo. Pero un gran número de personas opinaba lo contrario.

¿Cuál era la respuesta correcta? Al hacer esta pregunta alrededor del mundo descubrí que algunas personas defendían firmemente su postura sobre el botón de arriba, tan firmemente como lo hacían los que pensaban que la respuesta estaba en el de abajo. Todos se sorprenden al ver que otro pueda pensar diferente. ¿Quién tiene razón? Todos.

Al principio estaba desconcertado pero después me di cuenta de que se trataba de un problema de punto de vista: ¿es la persona la que avanza hacia la próxima diapositiva (botón de arriba) o son las diapositivas las que se mueven hacia el lector (botón de abajo)? Recordé que diferentes culturas perciben el tiempo de diferente manera: en algunas culturas, el tiempo es representado mentalmente como una especie de “estiramiento” de la persona hacia adelante mientras avanza a lo largo de la línea de tiempo. En otras culturas existe una representación similar, solo que en estos casos es la persona quien permanece fija, mientras es el tiempo el que se mueve: un evento futuro retrocede en dirección a la persona. La metáfora determina una percepción del mundo, y para los diseñadores, determina qué botón debería seleccionar la diapositiva siguiente: el de arriba si el lector es el que avanza, el de abajo si las diapositivas se mueven hacia él.

Resulta que la vida es un poco más compleja. Algunas culturas (como la China Mandarina, por ejemplo) a menudo representan la línea de tiempo verticalmente. Otras poseen una visión bastante diferente. Por ejemplo, ¿el futuro se encuentra hacia adelante o hacia atrás? Para la mayoría de nosotros esta pregunta no tiene sentido: obviamente, el futuro está adelante y el pasado detrás. Todos los que pensamos de esta manera debatimos sobre la llegada del futuro y nos alegramos de que ciertos eventos desafortunados del pasado hayan “quedado atrás”.

¿Pero por qué no podría el pasado estar delante nuestro y el futuro detrás? Consideren lo siguiente: podemos ver lo que está delante, pero no lo que está detrás nuestro, del mismo modo que podemos recordar lo que pasó, pero no podemos “recordar el futuro”. No solo eso, sino que además podemos recordar mucho mejor eventos recientes que aquellos que sucedieron largo tiempo atrás, capturados claramente por la metáfora visual en la que el pasado se alinea antes que nosotros, los eventos más recientes, ubicados más cerca, por lo que se pueden percibir (recordar) con mayor claridad, mientras que los sucesos anteriores se ubican más lejos, recordados y percibidos con mayor dificultad.

Si el tiempo se dispusiera en una línea horizontal, ¿iría de izquierda a derecha o de derecha a izquierda? Cualquiera de las dos opciones es correcta porque la elección es arbitraria, igual de arbitraria que la elección de si un texto debe escribirse en una página de izquierda a derecha o de derecha a izquierda. Sucede, sin embargo, que la elección de la dirección de un texto también se corresponde con su concepción del tiempo. Las personas cuyas lenguas nativas son árabe o hebreo suelen creer que el tiempo fluye de izquierda a derecha (estando el futuro hacia la derecha).

Escoger una alternativa de la metáfora o la otra va a determinar el diseño adecuado para la interacción. Cuestiones similares aparecen en otros dominios. Consideremos, por ejemplo, el problema típico del scrolling en una ventana. ¿El control del scrolling debería mover el texto o la ventana? Esto constituyó un debate casi religioso en los primeros años de display terminals, mucho tiempo antes del desarrollo delas computadoras modernas. Eventualmente, hubo un mutuo acuerdo en que el cursor arrow keys – y más adelante, el modo en el que el mouse movería las window scroll bars- seguirían el modelo de la ventana en movimiento. Al leer un texto, cuando el ojo alcanzaba el final de la pantalla, uno movía la ventana hacia abajo para continuar leyendo, pero como, de hecho, la ventana estaba firmemente fijada por el hardware, el display respondía moviendo el texto hacia arriba: la mano se movía hacia abajo, el texto hacia arriba.

En los casos donde la metáfora era “agarrar” la imagen visual, el movimiento era el contrario: “tome la imagen y muévala en la dirección que usted desee”. En este caso, para ver más texto por debajo de lo que se podía ver en la pantalla, había que agarrar el texto y moverlo hacia arriba. Uno mueve la mano hacia arriba para visualizar lo que está más abajo.

Los usuarios aceptaron estas convenciones casi naturalmente, razón por la cual se mantuvieron como tales por más de una década. Pero ahora estamos cambiando de nuevo, ahora que ya no movemos scroll bars pero usamos “gestos” para mover el texto.

Cuestionamientos similares surgieron en relación con las forma de exhibición de los aviones: ¿deberíamos mostrar las diferentes partes del avión como una aeronave que se mueve hacia un horizonte fijo o una aeronave fija que se traslada hacia un horizonte en movimiento? La primera opción es correcta si interpretamos la metáfora mirando el avión desde atrás, donde el horizonte se mantiene fijo mientras se traslada la aeronave, o desde el punto de vista del piloto, donde el avión se mantiene fijo siendo el horizonte el que se mueve.

En todos los casos, todos los puntos de vista son correctos. Todo depende de qué es lo que consideremos en movimiento. Pero esperen, que todavía no terminé. En algunas sociedades aborígenes australianas, la orientación por puntos cardinales aún es dominante, basándose en la dirección en la que sale y se pone el sol. Si le damos a alguien de estas comunidades un grupo de fotografías estructurado temporalmente (por ejemplo, imágenes de un hombre envejeciendo o un niño comiendo) y les pedimos que las ordenen, mientras una persona común de occidente las ordenaría de izquierda a derecha (la más nueva hacia la derecha), un miembro de estas comunidades aborígenes lo haría de este a oeste, ubicando la más nueva en el oeste. Si la persona estuviera mirando hacia el sur, colocaría la imagen de izquierda a derecha. Si, en cambio, mirara hacia el norte, lo haría de derecha a izquierda. Finalmente, si estuviera enfrentado al oeste, las ordenaría en una línea vertical extendida desde su cuerpo hacia afuera, siendo la más reciente la que esté más lejos de su cuerpo. Por lo tanto, ubicaría pegada a su cuerpo la más reciente si enfrentara el este. ¿Pero qué significa todo esto para el diseño? Buena pregunta.

Agradecimientos

Estoy en deuda con Lera Boroditsky, por su investigación sobre la concepción del tiempo (y por su voluntad de discutirla conmigo).

Capítulo 5: Diseño de interacción, prácticas de investigación y diseño en materiales digitales, por Jonas Löwgren

Mini biografía del autor

Creador de una de las maestrías en Diseño de Interacción en Europa y co-fundador de School of Arts and Communication. Es reconocido mundialmente por escribir textos clave en esta disciplina, que representan un aporte a la definición y a los métodos del Diseño de Interacción. Actualmente profundiza sobre cross-media y visualización interactiva. Es profesor de Diseño de Interacción en Malmö University, en Suecia.

Más información:

Traducción: Sebastián Betti

Diseño de interacción, prácticas de investigación y diseño en materiales digitales

En este ensayo presento el diseño de interacción, examino la naturaleza de la investigación actual en diseño de interacción y sus dilemas. Finalmente, desarrollo lo que podría (y quizá debería) ser el diseño de interacción.

Considero al diseño de interacción como el acto de dar forma a los productos y servicios digitales, lo que se considera como trabajo de diseño. La segunda parte de la frase es significativa dado que los productos y servicios digitales se han desarrollado durante muchos años en varios campos de la academia y la industria, pero en general en base a otros fundamentos.

En mi opinión, los diseñadores de interacción no están muy emparentados con los ingenieros y desarrolladores de sistemas, sino más bien con los diseñadores industriales y los arquitectos.

A diferencia de los diseñadores industriales y de los arquitectos, los diseñadores de interacción se especializan en materiales de diseño digital: software, electrónica y telecomunicaciones. Un diseñador de interacción podría trabajar por ejemplo en sitios web, teléfonos celulares, productos de comunicación, información distribuida en espacios públicos, comercio electrónico, instalaciones de arte interactivas, tecnología de rehabilitación y sistemas empresariales. Por lo tanto, debemos preguntarnos qué significa tener en cuenta los esfuerzos propios en áreas como el trabajo de diseño.

El trabajo de diseño se caracteriza por los siguientes aspectos:

Explorar posibles futuros, partiendo de una situación concreta.

Tratar de cambiar la situación para mejor mediante el desarrollo y la introducción de algún tipo de producto o servicio, es decir, del resultado concreto del proceso de diseño.

Tener en cuenta la práctica y la técnica, así como la estética y las cualidades éticas.

Llegar a comprender la tarea —el objetivo del trabajo de diseño— y a la vez el espacio de las posibles “soluciones”.

Pensar bocetando, construir modelos, y expresar ideas potenciales en otras formas tangibles.

Las diferencias más significativas entre el diseño de interacción y otras disciplinas que desarrollan productos y servicios digitales reside en los últimos elementos: el interés por las cualidades estéticas y éticas, el conocimiento creciente del objetivo durante todo el proceso, en lugar de congelarlo en una especificación temprana, y la importancia de explicitar las ideas. El diseño se ve generalmente como una relación de servicio, en la que el diseñador crea un artefacto —un producto o un servicio— para uno o más clientes.

Hay una cultura del diseño emergente en el campo digital, donde empresas como Apple y Meta Creations de Kai Krause jugaron importantes papeles formativos desde el principio en la difusión de los servicios móviles y de los videojuegos y en los últimos años ha contribuido a la creación de una clase de consumidores en busca de calidad de diseño.

Del mismo modo, hay una cultura de la investigación cada vez mayor en el diseño de interacción, con raíces que se remontan a las disciplinas académicas de la informática y de la interacción persona-computadora, y un interés central en la relación entre el diseño y la investigación.

Mi propósito aquí es analizar la forma en que puede verse el diseño como construcción de conocimiento, o más específicamente, la manera en que el diseño de interacción puede conducir al conocimiento científico de los materiales digitales. Otra forma de parafrasear mi preocupación es preguntando: ¿Qué significa investigar mediante el diseño de interacción?

En primer lugar, cabe señalar que el diseño con frecuencia conduce a nuevo conocimiento de interés para otros diseñadores y para situaciones de proyecto futuras, a veces estrechamente relacionadas con la situación de partida y, otras veces, conectadas más remotamente. Un ejemplo clásico del campo de software es la hoja de cálculo, presentada por primera vez en 1979 por Dan Bricklin y Bob Frankston en el producto VisiCalc como una forma de resumir las columnas de números en las cuentas financieras.

Imágen 1: VisiCalc y Excel:La idea básica de una hoja de cálculo tiene gran potencial.

Imágen 2: La Imac original de Apple y el cuenta pasos PE316FM de Oregon Scientific de una fecha posterior

El diseño y la construcción de los detalles de VisiCalc pueden no haber sido muy influyentes, pero la idea central de una hoja de cálculo dinámico ha demostrado ser un conocimiento viable y valioso usado con ulterioridad no solo en otros programas contables, sino también en otras áreas donde se supone que los usuarios construyen sus propios modelos de cálculo.

Otro ejemplo de conocimiento en el diseño (¿un meme de diseño?) es el lenguaje formal orgánico y translúcido desarrollado por Jonathan Ive para la iMac de Apple en 1998, que ha inspirado una amplia gama de proyectos de estilo para todo tipo de productos de consumo.

La hoja de cálculo y el estilo Bondi Blue son ejemplos bastante diferentes en muchos sentidos, pero ambos muestran cómo el diseño puede conducir a nuevos conocimientos sobre la función y la forma, que puede aplicarse a otros diseñadores y otras situaciones de diseño. Esto no es nada nuevo para los lectores familiarizados con la enseñanza del diseño, donde los ejemplos de diseño siempre han jugado un papel central.

Un profesor de diseño presenta un nuevo campo mediante ejemplos de diseño de ese campo, los estudiantes pasan horas estudiando los ejemplos canónicos de su campo, examinan proyectos de otros estudiantes y el trabajo se presenta a todo el grupo, añadiendo así un nuevo ejemplo.

Pasando del uso cotidiano de los ejemplos de la cultura de diseño a perspectivas más teóricas, encontramos evidencia significativa de la teoría del diseño para indicar que uno de los elementos más importantes de la capacidad de diseño es un repertorio de ejemplos abstractos como medio para generar ideas en nuevas situaciones de diseño.

A nivel general, parece fácil decir que el diseño puede generar conocimiento de valor para otros diseñadores. Por otra parte, se deduce que los diseñadores y otros actores en el campo del diseño, junto con su comunicación y los artefactos del campo, pueden verse como una comunidad para la construcción colaborativa de conocimiento. Cuando un diseñador desarrolla una nueva idea y la presenta a la comunidad como una posible contribución al conocimiento, está haciendo una declaración en un debate en curso.

Algunas declaraciones reciben muchísima atención, muchos colegas se apropian de la idea para probarla en nuevas situaciones de diseño o la elaboran de diferentes maneras, mientras que otras declaraciones pasan sin pena ni gloria.

Lo que la comunidad encuentra correcto y verdadero cambia con el tiempo, a veces poco a poco y otras veces de manera más abrupta, conforme se desarrolla el corpus de conocimiento mantenido en forma cooperativa.

Las comunidades de diseño usan varios canales de comunicación, desde los lugares tradicionales, como las revistas, las exposiciones y los premios hasta las expresiones sub culturales que cuestionan los ideales dominantes.

Cabe mencionar también el papel de la crítica en relación a la noción de comunidades de conocimiento de diseño. Los críticos y la crítica de un campo del diseño contribuyen al crecimiento colaborativo del conocimiento poniendo los ejemplos de diseño en contextos históricos, culturales y sociales más amplios, analizando ideas desde perspectivas distintas a las de los diseñadores, planteando preguntas inesperadas, señalando consecuencias inesperadas. Los críticos y los diseñadores son actores complementarios en la comunidad de conocimiento de un campo del diseño.

El segundo paso del argumento está más específicamente relacionado con el diseño que la construcción del conocimiento científico. Cada disciplina científica tiene su comunidad, dedicada a la construcción colaborativa del conocimiento. Un rasgo particular de las comunidades de conocimiento científico es que dedican buena parte de sus esfuerzos de colaboración a la cuestión de qué significa “científico”, es decir, qué contribuciones se consideran conocimientos aceptables.

Los criterios varían entre las disciplinas científicas y yo, obviamente, no puedo arrogarme un conocimiento completo de las prácticas de todas las comunidades científicas.

Sin embargo, he pasado muchos años como investigador, participando en una serie de diferentes comunidades científicas, y creo que he desarrollado un cierto sentido de las normas científicas. A nivel general, yo diría que los criterios científicos tienen que ver con la novedad, la relevancia, la fundamentación y la criticabilidad.

Una contribución al conocimiento científico —una declaración en la construcción del conocimiento actual de la comunidad científica— debe ser nueva en el sentido de que la idea, afirmación o concepto propuesto no sea ya una parte del corpus de conocimiento de la comunidad.

Una contribución al conocimiento científico debe ser relevante —debe ser singular, interesante y tener sentido. Si la contribución es de interés para la comunidad científica, es posible que la llamemos relevante internamente, mientras que si se trata de una aportación de interés para el mundo fuera de la academia será extremadamente relevante. Las contribuciones pueden ser relevantes, por supuesto, tanto a nivel interno como externo, pero a veces solo son relevantes internamente.

Una contribución al conocimiento científico debe basarse en algo que la comunidad considere aceptable. Las opciones más comunes son de base empírica (una declaración se basa en observaciones), base teórica (una declaración se basa en una teoría que es parte del corpus de conocimiento de la comunidad o de una teoría que la comunidad considera como una extensión aceptable del corpus de conocimiento) y base analítica (una declaración se basa en el razonamiento que la comunidad considera aceptable).

Una contribución al conocimiento científico debe ser criticable para permitirle a otros miembros de la comunidad examinar los fundamentos, las fuentes y los argumentos en los que se basa la contribución. El principio es que otro investigador debe poder evaluar la contribución científica identificando y criticando cada paso de la construcción conceptual en la que se basa la contribución.

Si aceptamos la idea de que el diseño puede conducir al conocimiento, entonces no hay nada en los cuatro criterios científicos generales que impida que el diseño conduzca al conocimiento científico. En principio, sería posible construir por diseño conocimiento nuevo, relevante, bien fundamentado y criticable. Esta es, de hecho, la idea principal que deseo plantear, y dedicaré el resto del texto a elaborar un poco el concepto.

Pero primero, tengo que hacer una digresión histórica. El concepto de diseño de interacción está medianamente establecido —se ha mencionado en ocasiones a partir de la década de 1980, pero en realidad no se extendió hasta mediados de los años 1990— aunque ya está razonablemente bien establecido .

Muchas empresas de las TIC, las telecomunicaciones y los medios de comunicación tienen empleados con el título de Diseñador de Interacción (aunque también es común el uso de términos como Arquitecto de Interacción y Diseñador de Experiencia de Usuario para referirse a descripciones de puesto similares). Muchas universidades se dedican a la enseñanza y la investigación en el diseño de interacción a veces con ese nombre y otras bajo el paraguas de la informática, el diseño industrial o las ciencias de la computación.

Para simplificar las cosas un poco, podríamos decir que hay tres principales tradiciones intelectuales que definen las condiciones para el diseño de interacción en la actualidad. El campo de la informática ha alimentado un interés por la ciencia del diseño desde la década de 1970, con énfasis en la metodología de diseño y participación de los usuarios.

El campo académico de la interacción persona-computadora (HCI, por sus siglas en inglés) surgió en la década de 1980 como una combinación de la psicología aplicada y las ciencias de la computación, y se caracteriza por un enfoque en el uso individual de los productos y servicios digitales con fines instrumentales. Conceptos como usabilidad, utilidad y relevancia son centrales en la HCI y el contexto tradicional es el uso de las TIC en configuraciones de entornos de trabajo. La tercera tradición principal, y la más reciente, es el diseño industrial. Solo en los últimos diez años el diseño industrial ha demostrado interés en los materiales digitales, así como en la creciente importancia de la integración de la forma física y los “contenidos” digitales a la computación móvil y portátil.

En Suecia, y quizá en algunos otros países, también se ha dado el caso de que el diseño industrial ha trabajado históricamente en el ámbito de las artes aplicadas y solo recientemente se ha visto obligado a empezar a orientarse hacia entornos de investigación académica.

Por lo menos dos áreas de las tres que forman el linaje intelectual del diseño de interacción —la informática y la HCI— son campos académicos relativamente bien establecidos con fuertes tradiciones científicas. De modo que la nueva práctica de la investigación en diseño de interacción tiende a adoptar las formas de normas originarias de la informática y la investigación en HCI.

Estos son algunos ejemplos de tales normas:

Una tesis doctoral es un texto argumentativo, que empieza con una introducción y una pregunta de investigación, sigue con la elección del método de investigación y los resultados de la aplicación de los métodos elegidos y termina con una respuesta tentativa a la pregunta de investigación.

Una tesis doctoral es un libro de unas 200 páginas con mucho texto y algunas fotos.

Una idea innovadora para un nuevo producto digital o servicio debe ser probada con los usuarios antes de que su valor pueda ser evaluado.

Una contribución científica ideal es de validez universal, por ende es cierta en todos los contextos y situaciones conocidos hasta el momento.

Los lectores con experiencia en investigación son proclives a reconocer estas normas. Todas están más o menos institucionalizadas en las disciplinas científicas que dan forma a las condiciones para la investigación del diseño de interacción en la actualidad. Sin embargo, si las comparamos con los cuatro criterios generales anteriores (nuevo, relevante, fundamentado, criticable), nos encontramos con que las normas son más restrictivas que lo necesario.

Por ejemplo, imaginemos si un artefacto pudiera ser parte de la estructura argumentativa de un aporte de conocimiento científico (en lugar de limitarse a ser representado en un poco de texto y algunas fotos).

O, ¿qué tal si una tesis doctoral pudiera consistir en un producto digital más una capa de fundamentación escrita y una capa de reflexión y abstracción en texto?

¿Qué tal si una idea innovadora para un nuevo producto digital o servicio se criticara mediante una base analítica en lugar de hacerlo mediante una base empírica?

¿Qué tal si una contribución al conocimiento científico se encuadrara como una semiabstracción? Eso significaría proponer una contribución con la intención de que otros pudieran apropiarse de ella para otras situaciones diferentes al diseño original, pero sin pretensiones de universalidad. Más importante aún, se entendería que la apropiación exigiría una cierta cantidad de trabajo, a pesar de que es tarea del contribuyente facilitar el trabajo de apropiación informando las bases, las fuentes y el razonamiento, es decir, haciendo que la contribución sea criticable. Por otra parte, el contribuyente puede ayudar al apropiador discutiendo el alcance de la contribución y delineando los tipos de situaciones en las que es más probable que tenga sentido apropiarse de la contribución.

Todas estas situaciones hipotéticas y muchas otras, que se pueden prever fácilmente, cumplen los cuatro criterios científicos generales, al tiempo que infringen las normas institucionalizadas de diferentes maneras.

En otras palabras, la investigación de diseño de interacción parece estar atrapada en la tensión entre las normas científicas de la informática/HCI y el objetivo de hacer del diseño una parte del proceso de construcción de conocimiento bajo criterios científicos más generales.

En esta sección, esbozo cinco estrategias perceptibles empleadas por los investigadores para manejar esa tensión.

Diseñar prototipos para la evaluación empírica y estudiar las cualidades de las nuevas ideas de diseño en uso. Esta es la estrategia dominante en HCI y se basa a su vez en muchos años de ingeniería y prácticas de psicología experimental. Algunos prototipos se construyen para demostrar la viabilidad técnica de la idea (tales prototipos son llamados, de manera muy reveladora, prototipos de prueba de concepto), mientras que otros sirven como vehículos para la prueba de hipótesis en una metodología experimental más o menos rigurosa. Los aportes de conocimiento derivados de esta estrategia pueden ser supuestamente universales o semiabstractos, en función de la perspectiva en la que se base la obra, y de los métodos empíricos empleados.

Explorar las posibilidades de un material determinado de diseño, ideal de diseño o tecnología. En esta estrategia, el trabajo de diseño se realiza como una manera de explorar el espacio de posibles nuevos artefactos. Los aportes de conocimiento son generalmente semiabstractos. Un ejemplo útil de esta estrategia es la tesis doctoral de Tomas Sokoler 1, donde una contribución al conocimiento criticable se compone de cinco ciclos de diseño y reflexión sobre el diseño ideal de la computación ubicua. Como ha señalado Krippendorff, el fundamento analítico de una contribución al conocimiento en el contexto de la investigación de diseño puede incluir la presentación de varios nuevos posibles artefactos (varias alternativas de diseño) y una argumentación coherente en torno a sus cualidades como forma de motivar la elección de una de las alternativas. Tales aproximaciones de fundamentación deben ser de gran importancia en esta estrategia.

Explorar futuros posibles bastante lejanos a las situaciones actuales. Aquí, el trabajo normalmente implica diseñar artefactos centrales y su uso en un futuro posible, y el examen de ese futuro a través de una combinación de reflexión analítica y evaluación cuasi-empírica mediante modelos de visión y dramatizaciones. Los aportes de conocimiento consisten en semiabstracciones que abordan las posibles propiedades y cualidades de los objetos propuestos. Un ejemplo de esta estrategia podría ser las notas de trabajo post-hoc 2, un proyecto que dirigí hace unos años sobre el tema del trabajo de oficina en un posible futuro en el que todas las reuniones, documentos y otra información relacionada con el trabajo se almacenaran en archivos multimedia. El trabajo de diseño consistió en modelar herramientas para el acceso y la gestión de grandes volúmenes de información y en hacerlos accesibles imaginándolos en una película que mostrara el uso potencial de las herramientas en gestión de conocimiento en una agencia de publicidad.

Diseñar artefactos para instanciar una teoría más general de un material específico de diseño y evaluar los resultados. Las contribuciones de conocimiento normalmente son semiabstracciones, aunque pueden resultar contribuciones universales en caso de que el trabajo de diseño ofrezca razón para modificar la teoría general subyacente. Un ejemplo ilustrativo es la disertación doctoral de Andreas Lund 3 que combina una teoría universal de la ciencia cognitiva en esquemas de imágenes y proyección metafórica con el diseño y la evaluación de nuevos recursos digitales.

Realizar un proceso de diseño participativo, donde los futuros usuarios actúen como expertos en su campo de práctica y no como objetos de estudio o participantes en sesiones de evaluación. El diseñador/investigador normalmente asume el doble papel de experto en el diseño de materiales del que se trate y facilitador del proceso de diseño. Las contribuciones de conocimiento son semiabstracciones relativas a la práctica en la que se lleva a cabo el proceso de diseño y a las repercusiones de las intervenciones socio-técnicas. Las maneras de actuar y razonar del diseñador/investigador a menudo están estrechamente relacionadas con las de la investigación de acción.

El proyecto Kliv es un ejemplo claro y reciente de esta estrategia, producto de las contribuciones de conocimiento en los ideales de diseño de interacción personificado y en la producción de medios de comunicación locales, así como en prácticas sociales de gestión del conocimiento en salud.

Más o menos todos los ejemplos de investigación disponibles en diseño de interacción parecen considerar las publicaciones escritas y los resultados reales —un proceso de diseño realmente no es investigación hasta que se escribe un artículo o tesis sobre él.

El procedimiento estándar consiste en describir las ideas y los argumentos en forma de texto y agregar algunas fotos de un prototipo o un modelo. La norma “Mucho texto y algunas fotos” parece fuertemente arraigada y toda la infraestructura de la comunicación científica se construye alrededor de los textos escritos. Estas estructuras, por supuesto, no es algo fácil de cambiar aunque algunas conferencias académicas experimentan un poco con exposiciones y otros formatos.

Sin embargo, las normas existentes crean un problema general para la investigación del diseño de interacción ya que los materiales digitales son tanto temporales como espaciales. En otras palabras, las cualidades de un producto digital o servicio dependen no solamente de su forma en dos o tres dimensiones, sino de igual manera de la forma en que se comporta el uso durante períodos más cortos o más largos de tiempo.

Un producto digital tiene una cierta sensación en uso. Algunos productos pueden percibirse como incómodos y rígidos, otros más maleables y fluidos. Por ejemplo, es posible hablar de la flexibilidad de una visualización interactiva con referencia a la sensación del usuario de modelar los datos presentados como un material táctil y receptivo, fomentando la exploración y los descubrimientos fortuitos. Algunos productos digitales demuestran todo su ámbito de aplicación en un breve resumen en el primer contacto, otros aluden a grados de complejidad cuya comprensión requiere tiempo y esfuerzo. Algunos productos se perciben como poderosos, otros como débiles y suaves. La interacción tiene un ritmo que puede ser lento o agitado, vacilante o insistente.

La flexibilidad y las cualidades similares son resultados del diseño de interacción y por lo general no son visibles en la forma del producto. Aparecen solo con el uso. Es bastante obvio que una presentación basada en una gran cantidad de texto y algunas imágenes no puede transmitir esas cualidades temporales. A diferencia del diseñador de sillas y de otros objetos materiales, tenemos la posibilidad, en principio, de incluir una copia de nuestro producto en la argumentación que construimos y difundimos en la comunicación científica, por ejemplo, mediante la construcción de una tesis doctoral en torno a un artefacto digital con una capa de texto de fundamentación y otra capa de texto de reflexión y abstracción.

Imágen 3: Las sillas SUPERLEGGERA y TULIP son de uso muy diferente. Uno puede sentirlo en el cuerpo con solo mirar las fotos.

Imágen 4: Los videojuegos SIMS 2 y GRAND THEFT AUTO también son muy diferentes al uso. Eso no se nota demasiado en las imágenes.

Si bien podemos esperar la publicación de nuevas normas sobre la investigación en diseño de interacción, también es interesante tener en cuenta qué prestaciones permite la regla general “Mucho texto y algunas imágenes” en materia de construcción de contribuciones de conocimiento. Una posibilidad es la formulación de semiabstracciones en forma de cualidades de experiencia, es decir, de conceptos que identifican propiedades deseables en los géneros de productos, de manera tal que otros diseñadores puedan apropiarse de los conceptos y los usen para diseñar nuevos productos con las mismas cualidades. El concepto de flexibilidad que he mencionado anteriormente es un ejemplo de la calidad de la experiencia.

Otra idea que ha despertado un poco de atención recientemente es la formulación de modelos, que refieren a ideas centrales del diseño que aparecen en varios productos y pueden ser semi-abstraídas para su uso en nuevas situaciones de diseño. El fundamento teórico para la formulación de patrones es la idea de que el trabajo de diseño se guía por un repertorio de ejemplos que se comparan con nuevas situaciones de diseño; la idea es que un diseñador puede desarrollar su repertorio y por lo tanto extender su capacidad de diseño mediante la apropiación de patrones formulados y comunicados por otra persona.

La idea de los patrones procede de la obra de Christopher Alexander sobre la planificación urbana en la década de 1970 y se ha empleado en el diseño de interacción, principalmente como forma de captar soluciones estándar probadas a problemas recurrentes (denominadas mejores prácticas). Sin embargo, es perfectamente factible también para resumir las experiencias de la exploración de espacios de diseño previamente desconocidas en lo que podríamos llamar los patrones de inspiración, cuyo objetivo es proporcionar material para que otros diseñadores desarrollen su conocimiento.

En este punto, he argumentado más ampliamente que el diseño puede dar lugar al conocimiento y, específicamente, que el diseño de interacción puede conducir al conocimiento científico. Para mí, la investigación de diseño de interacción parece ser una posibilidad interesante y apasionante. Deben abordarse otras dos preguntas. En primer lugar, ¿qué se requiere de un diseñador/investigador en el ámbito académico? En segundo lugar, ¿cómo sería la investigación en diseño de interacción?

La primera pregunta se refiere esencialmente a la capacidad de diseño. Si el objetivo es la construcción de conocimiento científico, ¿es necesario entonces ser un buen diseñador de interacción?

La historia de la disciplina sugiere que la capacidad de diseño no es esencial. Un argumento recurrente desde el campo de la investigación experimental en HCI (estrategia 1, arriba) señala que un diseño que se ha probado empíricamente con los usuarios puede ser incompleto y deficiente en muchas formas, siempre y cuando las partes pertinentes a la pregunta de investigación se hayan realizado de manera aceptable.

Este argumento me parece cuestionable, ya que supongo que los usuarios que participan en un experimento se ven afectados por la situación, incluyendo el prototipo incompleto y en parte inadmisible, a pesar de que el propósito es solo probar, por ejemplo, una nueva forma de navegar ciertas estructuras de información.

Por otra parte, probar una parte aislada de un producto en una situación que no es muy similar a la situación de uso previsto parece una forma poco fiable de obtener información sobre las cualidades del producto en el uso real. En las estrategias 2 a 4 anteriores, los artefactos diseñados son por sí mismos partes esenciales de las contribuciones de conocimiento. Parece obvio que tienen que ser de calidad de diseño aceptable. La quinta estrategia, donde el diseñador/investigador facilita un proceso de diseño participativo, requiere normalmente que este proporcione conocimientos especializados sobre las propiedades de los objetos digitales, así como un rico repertorio de ejemplos de diseño de relevancia para la situación de proyecto del que se trate.

Al parecer, la capacidad de diseño es un activo del diseñador/investigador y un requisito para algunas de las estrategias identificadas anteriormente. En términos más generales, la tarea de evaluar la calidad del diseño recaería sobre la comunidad científica, así como la evaluación de otros aspectos de la contribución de conocimiento.

Pero, ¿esto no implica una situación del huevo y la gallina? El diseño no es una parte establecida de la comunidad científica y los conocimientos necesarios para evaluar la calidad del diseño no están muy bien representados en el corpus de conocimiento de la comunidad. Sin embargo, esto no implica que los conocimientos necesarios para la evaluación sean inexistentes. En el diseño de interacción, así como en otras disciplinas del diseño, la capacidad de evaluación está muy relacionada con los diseñadores experimentados y su papel en la comunidad. El diseño de interacción es un campo muy joven sin mucho arraigo manifiesto, y con un fuerte interés mutuo en aproximar la cultura del diseño a la cultura científica.

Creo que hay algunas posibilidades para lograr que la calidad del diseño sea uno de los criterios de evaluación de uso habitual para las contribuciones de conocimientos relacionadas con el diseño. Por otro lado, una medida tal podría ser controvertida ya que implicaría ciertas modificaciones en las estructuras de poder prevalentes en la comunidad científica.

La segunda pregunta se refiere a cómo podría ser la investigación de diseño de interacción y ya he abordado parte de eso en una respuesta preliminar. Las cinco estrategias mencionadas anteriormente son ejemplos de investigación en diseño de interacción, en la que el trabajo de diseño desempeña un papel más o menos destacado en la construcción del conocimiento real. Pero todavía veo gran potencial para seguir desarrollando nuestros instrumentos científicos y nuestras prácticas de investigación.

Más concretamente, parece que hay cuatro elementos principales en la agenda de construcción de una comunidad más fuerte para la investigación en diseño de interacción. Debe establecerse el concepto de contribuciones de conocimiento semiabstractas junto a una práctica adecuada de triangulación de las bases empírica, teórica y analítica. Tales nociones resultan ya muy familiares a los investigadores con experiencia en metodologías de investigación cualitativa, donde los conceptos de fundamentación y criticabilidad forman parte del discurso científico cotidiano.

Es necesario elaborar las posibles funciones de los artefactos en la argumentación científica y la práctica de publicación. Esta muy probablemente sea una preocupación en la investigación de diseño en general, pero me resulta particularmente urgente para el diseño de interacción, y esto se debe a que los artefactos digitales son particularmente difíciles de representar en “mucho texto y algunas imágenes” debido al carácter temporal de los mismos.

Los artefactos que se presentan como parte de las contribuciones de conocimiento deben ser evaluados de manera integral en términos de la calidad de su diseño. El peligro de aislar una pregunta de investigación y tratar de responderla mediante un trabajo de diseño incompleto es que el artefacto, que puede ser insuficiente respecto a los aspectos ajenos a la pregunta de investigación, se difunda como una contribución conjunta de conocimiento (dado que los ejemplos de diseño son de fácil apropiación como un todo) y por lo tanto lleve un bagaje inferior de conocimiento.

Por último, tenemos que aprender de la función de la crítica en las disciplinas de diseño más maduro, y específicamente de la interacción entre la práctica creativa y la crítica en campos como la arquitectura. Con algunas excepciones, el diseño de interacción carece de una disciplina de la crítica y yo diría que buena parte de la evaluación que se realiza actualmente mediante comprobación empírica de hipótesis aisladas funcionaría mejor en una comunidad que incluya la crítica de diseño de interacción y su evaluación analítica de perspectivas múltiples.

Estas son solo algunas sugerencias sin ningún tipo de pretensiones de exhaustividad. Sin embargo, para mí en la actualidad representan las medidas más urgentes para la práctica de la investigación en diseño de interacción que contribuirían a un conocimiento aún más valioso para la sociedad sobre las propiedades y posibilidades de los materiales digitales.

Sokoler desarrolla una perspectiva de diseño de la computación ubicua, con énfasis en las habilidades y capacidades humanas, donde argumenta que la tecnología digital debe colocarse a la par de otros recursos físicos y sociales para una acción humana calificada. Este ideal de diseño se expresa a través de un texto reflexivo que analiza cinco proyectos de diseño en el ámbito de la mediación periférica de conciencia de situación, una herramienta para navegar por el espacio físico mediante retroalimentación táctil, un dispositivo de información personal para operadores de plantas de aguas residuales, tarjetas de papel para controlar la reproducción de video en entornos de colaboración creativa y un teléfono móvil para “hablar en silencio”.

El proyecto notas de trabajo post-hoc partió de la suposición de que los trabajadores del conocimiento en un futuro más o menos lejano tendrían acceso a una infraestructura en la cual las reuniones y otras comunicaciones cara a cara se almacenarán como grabaciones de video, junto a los documentos, correo electrónico y otras comunicaciones asíncronas. Aparte de los problemas de seguridad e integridad, también hay una cuestión fundamental relativa a cómo acceder a esa masa potencialmente enorme de material, de ser necesario. Contamos una historia de esa situación de uso mediante el diseño de un conjunto de herramientas de gestión de información y de acceso a la misma y las colocamos en una visión de trabajo prevista que presentamos en forma de película. Las contribuciones de conocimiento consistían en una nueva forma de combinar la búsqueda de imágenes, de texto, en el análisis semántico de la información y la visualización de información, así como en conclusiones sobre la importancia de los metadatos y las formas de extraer metadatos de gestión de la información manual sin sobrecarga.

La contribución al conocimiento de la disertación de Lund aborda el ideal de diseño llamado masificación, lo que conlleva a nuevas formas de visualización de información para expresar sus contenidos de información, basado en la teoría general de la ciencia cognitiva de proyección metafórica y esquemas de imagen. Dos proyectos de diseño forman parte de la argumentación: una realidad virtual de visualización de colecciones de páginas web, y un intento de visualización de datos temporales a través de la espacialización. Las relaciones entre las bases teóricas generales y las decisiones específicas de diseño se presentan en un nivel muy detallado, y los dos proyectos de diseño se evalúan empíricamente, formando así una triangulación teórico-empírica para fundamentar la contribución de conocimiento.

La versión original de este capítulo no tenía referencias bibliográficas. Para que esta versión funcione como un documento independiente, me gustaría enumerar algunas referencias clave usadas en este artículo.

Referencias

1. Sokoler, T., Más allá de la computadora de escritorio con actitud, 2004.

2. Andersson, O., Cacciatore, E., Löwgren, J., Lundin, T., Notas de trabajo Post-Hoc, 2002.

3. Lund, A., Masificación de lo intangible: Una investigación sobre el sentido y la visualización de la información, 2003.

Bibliografía

Andersson, O., Cacciatore, E., Löwgren, J., Lundin, T., Post-hoc worknotes: A concept demonstration of video content management. Proc. 10th ACM Int. Conf. Multimedia (MM ’02), pp.670-671, Nueva York, ACM Press, 2002.

Brandt, E., Björgvinsson, E., y Hillgren, P. A., Self-produced video to augment peer-to-peer learning. Proc. Mlearn 2003: Learning with mobile devices, pp. 27-34, London, Learning and Skills development agency, 2004. [Una introducción bastante directa al proyecto Kliv]

Krippendorff, K., The semantic turn: A new foundation for design, Boca Raton, fl: CRC Press. [Analiza, entre otras cosas, la idea de validar el diseño mediante exploración y evaluación de alternativas], 2006.

Lund, A., Massification of the intangible: An investigation into embodied meaning and information visualization, tesis doctoral, Universidad de Umea, 2003. Disponible en www.diva-portal.org.

Löwgren, J., y Stoterman, E., Thoughtful interaction design: A design perspective on information technology, Cambridge, Mass., MIT Press, 2004.

Nelson, H., y Stoterman, E., The design way: Intentional change in an unpredictable world, Educational Technology Publishing. [De aquí viene la noción de diseño como servicio]

Sokoler, T., Going beyond the desktop computer with an attitude, Tesis doctoral, Universidad Técnica Blekinge, 2004. Disponible en The Electronic Research Archive [Ver en línea].

Capítulo 6: Diseño participativo para la inclusión digital, por Stephen Grant, Laurel Evelyn Dyson y Toni Robertson

Mini biografía de los autores

Trabajaron juntos creando el proyecto de investigación-acción “Programa de Participación Indígena en Tecnologías de la Información” (IPIT) para fomentar la inclusión digital de aborígenes australianos con foco en propiciar la creación de la asignatura de tecnologías de la información dictada para y por aborígenes tal cual se describe en este capítulo. Los tres son docentes e investigadores de la Facultad de Ingeniería y Tecnología Informática de la Universidad Tecnológica de Sydney .

Más información:

Ingresar al sitio web del autor

Traducción: Mariana Inés Calcagno

Diseño participativo para la inclusión digital: El caso de los aborígenes australianos

Introducción

A principios de la década del ‘70 el gobierno australiano admitió que el bajo nivel de participación de los aborígenes en todos los niveles educativos era un gran problema. Por ejemplo, en 1972, un poco menos de 100 aborígenes australianos y habitantes de las islas del Estrecho de Torres se habían inscripto en estudios terciarios (Gale, 1995). En ese momento, se presentaron novedosas medidas orientadas a la igualdad de acceso, que luego fueron modificándose durante las dos décadas subsiguientes. Estas incluían asistencia financiera a los estudiantes indígenas, planes de ingreso especiales, programas de apoyo y tutorías personalizadas. Sin embargo, aunque se mejoró significativamente el número de inscripciones, la finalización de los estudios seguía siendo un desafío. A finales de los ‘90, el gobierno resumía la situación de la siguiente manera: “La tasa de acceso de los indígenas a la educación superior, en el 1,5 % de los estudiantes que ingresan, es ahora apenas menor que el de su grupo de población de 1,7 %. Sin embargo, su éxito académico y permanencia dentro de la educación superior sigue siendo muy baja. La alta deserción significa que, en general, la participación de los indígenas en la educación superior es también baja, al 65 % de lo que se esperaba de esta porción de la población general”. (Detya, 1999, p. 3).

Los factores que contribuyen al éxito o fracaso de los aborígenes en la universidad incluyen el nivel de apoyo a los estudiantes, las actitudes del personal, el disfrute de la vida universitaria, estudiar a distancia versus el modo presencial, la situación familiar, género, finanzas, vivienda, y el grado de preparación previa de los estudiantes para los estudios universitarios. (Bourke y Burden, 1996). Por otro lado, diferentes encuestas a estudiantes aborígenes demostraron “su preocupación y resentimiento por el hecho de que de acuerdo con las expectativas del sistema universitario estuviera en peligro su identidad cultural”. (Bourke y Burden, 1996, capítulo 4). Algunos investigadores identificaron a la educación universitaria en Australia como fundamentalmente eurocéntrica e integradora. (Anderson, Singh, Stehbens y Ryerson, 1998; Gale, 1995).

A pesar de estas tendencias, las carreras de grado en Educación, Derecho, Enfermería, Medicina y Community Management han logrado un éxito creciente atrayendo estudiantes aborígenes que terminan graduándose desde el comienzo de los ‘80 en adelante. Esto fue posible mediante el desarrollo de un conjunto de cursos diseñados específicamente para satisfacer los requerimientos de los estudiantes aborígenes (incluyendo contenido cultural adecuado y modelos de entrega), apoyo social y cultural, lugares “amigables para aborígenes”, y por sobre todas las cosas, la presencia de personal aborigen en el ámbito académico y los espacios de apoyo. (Robertson, Dyson, Norman y Buckley, 2002a).

Sin embargo, las disciplinas que no pertenecían a las áreas de prioridad inmediata para la comunidad aborigen permanecían excluidas de dichos procesos. La Tecnología de la Información (IT) fue una de ellas. Había muy pocos profesionales IT de origen indígena que pudieran funcionar como modelos a seguir. La comunidad aborigen no tenía mucha consciencia de las opciones de trabajo disponibles en la industria IT y tampoco se incluía esta disciplina en las charlas de orientación vocacional a los estudiantes secundarios por parte de sus tutores, maestros y otros líderes de la comunidad. En general, los tutores no conocían ni entendían los tipos de trabajos disponibles en la industria o en qué consistía la capacitación de los profesionales IT. Parecía no haber percepción de la distinción entre conocimiento de computación y habilidades profesionales de IT que se requieren para diseñar, construir y mantener los sistemas. Por otro lado, el éxito de los aborígenes en las áreas tradicionales y de necesidad inmediata probablemente estaba filtrando a los estudiantes desertores directamente hacia campos como el derecho, la educación y la enfermería, mientras que otras opciones no estaban siendo consideradas seriamente (Robertson, Dyson, Norman y Buckley, 2002b). Como consecuencia de esto, la cantidad de indígenas inscriptos en los programas educativos de IT permaneció muy baja.

En octubre de 2001, la Universidad Tecnológica de Sydney (UTS) comenzó un proyecto de investigación cuyo objetivo era encontrar el modo de aumentar el nivel de participación de aborígenes en los estudios IT. Las estadísticas obtenidas en ese momento por el Departamento de Educación, Ciencia y Capacitación confirmaron que el bajo grado de inscripciones era consistente en todo Australia, con incluso varias universidades líderes sin un solo graduado aborigen en el área de IT (Robertson et al., 2002a). La consecuencia de la baja inscripción en los cursos de IT implicaba que había muy pocos aborígenes trabajando como profesionales IT. Esto fue así pese a una creciente toma de conciencia por los aborígenes australianos de los beneficios que IT podría aportarle a sus comunidades (ATSIC, 2002).

Como consecuencia de nuestra investigación inicial se decidió lanzar un proyecto de 3 años para aumentar la participación de los estudiantes aborígenes en los cursos IT. Este fue formulado sobre la base de una participación activa de los aborígenes, trabajando en colaboración con los miembros de la Facultad. En ese momento, había dos puntos de conexión con los enfoques de Diseño Participativo. El primero era que la falta de participación de los aborígenes australianos en el diseño e implementación de políticas y procesos que los afectaran directamente era cada vez más reconocida como una gran fuente de fracasos. La segunda era que, sin aborígenes profesionales de IT capacitados, su participación en el desarrollo de Tecnologías de la Información y Comunicación (TICs) estaría limitada a una participación acordada como usuarios o partes interesadas. No podrían participar completamente en todos los aspectos del desarrollo de sus propias tecnologías y sistemas (Robertson, Dyson, Norman y Buckley, 2002b). Se vería una falta de participación informada de los aborígenes en las decisiones nacionales respecto de las iniciativas TIC de gran importancia, tales como la Red Nacional de Banda Ancha y las mejoras en la cobertura móvil. Continuaría existiendo el bajo nivel de participación indígena en la toma de decisiones que afectan el acceso e implementación de TIC en las comunidades aborígenes. Como consecuencia, se mantendría n intactos el contacto aleatorio y la escasa provisión de TIC en las comunidades, incluyendo sistemas culturalmente apropiados, apoyo y capacitación.

Este capítulo tiene como objetivo proveer un panorama general del desarrollo histórico del Proyecto y el modo en el que, gracias a su éxito, fue evolucionando hasta llegar a ser un programa permanente en la Facultad, el Programa de Participación Indígena en IT (IPIT por sus siglas en inglés). El término “Indígena” fue elegido en ese momento para no excluir a los habitantes de las islas del Estrecho Torres, del norte de Australia1, aunque por razones prácticas todos nuestros estudiantes de licenciatura y post-grado han sido aborígenes australianos debido al lugar en que está situada la Universidad. Además, tiene como propósito mantener al tanto a la comunidad CDP del estado del desarrollo del Proyecto, presentado por primera vez en la Conferencia de Diseño Participativo en 2002 (Robertson et al., 2002b).Como se informó entonces, el proyecto se desarrolló usando los conceptos del Diseño Participativo para darle forma a sus dos enfoques, su diseño y su desarrollo en curso. Fue un proyecto destinado al diseño participativo del acceso y la participación de los aborígenes australianos en IT.

Desarrollo del proyecto IPIT con la participación de los aborígenes.

El proyecto estaba centrado en la Facultad de IT pero concebido como una colaboración entre la Facultad y la gente aborigen. Una colaboración que operaba en tres niveles principales: la conducción de la investigación inicial, la implementación de estrategias de reclutamiento y el manejo del Proyecto.

La Casa de Estudios Indígenas Jumbunna (el centro indígena de apoyo e investigación para la Universidad) trabajó junto a los miembros de la Facultad desde el momento inicial de la investigación y durante todo el proceso, como proveedor de servicios tales como reclutamiento estudiantil, provisión de cursos básicos de comunicación y matemática y la organización de instrucción complementaria.

Como parte del proceso inicial de la investigación, la Facultad trabajó con escuelas y universidades locales con un nivel significativo de inscripciones aborígenes, y visitó algunas instituciones que tuvieron éxito con la educación de aborígenes pero en otras disciplinas. Cada uno de los sitios era visitado por miembros del Proyecto y, a su vez, algunos miembros de las dichas instituciones visitaban la Facultad.

Se emplearon varias estrategias para aumentar el conocimiento de IT entro los aborígenes australianos y atraerlos hacia cursos sobre el tema (Robertson et al., 2002b). Aparte de las visitas a las facultades, se diseñaron nuevos folletos informativos que se distribuyeron en las ferias de empleo, se lanzó un sitio web y se desarrolló un curso de preparación terciaria en IT, el Programa Indígena de Pre-IT, como vehículo de reclutamiento. Publicidad en el diario Koori Mail (un gran distribuidor de noticias aborígenes) ayudó a reclutar estudiantes para el curso de preparación y le dio al programa un perfil nacional. Todas estas actividades se llevaron a cabo por miembros del personal aborigen y no-aborigen de la facultad trabajando y tomando decisiones a la par.

Una parte esencial de la estrategia del proyecto fue emplear gente aborigen de la facultad por primera vez. Se contrató un Project manager aborigen y se creó un puesto académico. Estos dos miembros del personal jugaron un papel clave en la gestión del proyecto, tomando las decisiones importantes, reclutando, ofreciendo a los estudiantes apoyo y desarrollando sus curriculums. No lo hicieron solos, fueron asistidos por miembros ya existentes de la Facultad.

La estructura de gestión del proyecto fue crucial para lograr esto. El cuerpo principal de la dirección era el Grupo de Trabajo del Programa IPIT. Este grupo realizaba un encuentro mensual para discutir el avance, tomar decisiones en conjunto y diseñar nuevas estrategias para los demás objetivos del proyecto. El Grupo de Trabajo consistía de los dos nuevos miembros aborígenes del personal (El Project Manager y el Académico Aborigen), integrantes no-aborígenes de la Facultad (tanto académicos como de apoyo), un aborigen graduado en IT y personal aborigen de otras unidades de la Universidad. Por ejemplo, un informe interno correspondiente al período que va entre septiembre de 2002 a mayo del 2003 muestra 7 aborígenes trabajando junto a 15 no-indígenas. Además de este grupo, había tres subgrupos para: Becas de Financiamiento y Pasantías; Promoción, Reclutamiento y apoyo; Desarrollo del curso. Y de nuevo, todos estos subgrupos incluían la participación de miembros indígenas y no indígenas.

Problemas con el Programa IPIT en los primeros años

A pesar de la planificación cuidadosa, el trabajo dedicado al Proyecto, y la estrecha relación laboral que se había dado entre los miembros del staff, tuvieron que lidiar con importantes problemas. Después de todo, el Proyecto se estaba dirigiendo hacia un área de estudio no tradicional, y a su vez a un camino laboral no tradicional para gente aborigen.

Con respecto al reclutamiento de estudiantes aborígenes, la Facultad tuvo más éxito que con el número de graduados. Las inscripciones habían aumentado de 2 estudiantes antes del comienzo del Proyecto IPIT a 8 (7 estudiantes y un graduado) en 2005, la fecha del final del proyecto. Sin embargo, la mayoría de ellos no llegaría a terminar. Para el 2005, la Facultad había tenido sólo dos graduados aborígenes en IT, uno de los cuales era anterior al comienzo del Programa. (Dyson y Robertson, 2006). En esta etapa, la Facultad todavía estaba tratando de encontrar un mejor modo de reclutar estudiantes y, una vez logrado este objetivo, cómo apoyarlos a completar sus estudios. Por ejemplo, en el 2005, se adoptó una política de admisión más relajada, mediante la cual podrían admitirse estudiantes con pobres antecedentes académicos, y la mayoría de ellos fracasaron en las primeras etapas de su estadía en la Facultad.

Lo que más éxito tuvo en términos de finalización de los estudios fue le Programa Indígena de Pre-IT, un curso sin título de preparación terciaria.

El programa indígena de PRE-IT

El Programa Indígena de Pre-IT era un curso full-time de dos semanas, ofrecido durante 4 años por la Facultad para los Aborígenes Australianos. Fue el primer curso IT de su tipo en Australia, permitiendo a los estudiantes aprender los conceptos y herramientas IT de primer año de licenciatura, mucho más allá del conocimiento básico de informática. (Grant, Hendriks y Dyson, 2007).

El curso fue el resultado de un trabajo en colaboración de académicos con una amplia gama de experiencia en IT. Se encontraban semanalmente, y con el aporte de todos, se creó un programa extraordinario. En el curso los alumnos adquirían un entendimiento sobre las tecnologías subyacentes y varias aplicaciones de la Tecnología de la Información en el lugar de trabajo moderno. Se cubrían algunos temas de programación, Internet, Diseño Web, reglas básicas de la Informática y Desarrollo de Sistemas de Información. Todos los estudiantes completaban un proyecto que integraba las habilidades y el conocimiento de las cinco áreas de estudio. Los dos principales objetivos del Pre-IT eran:

Promover IT como una opción viable de estudio y plan de carrera para los aborígenes australianos y funcionar como un programa introductorio para entrar a los cursos universitarios de IT.

Desarrollar habilidades y conocimiento en IT en la comunidad a través de estudiantes que fueran capaces de pasar esas habilidades a otros y también usar el conocimiento IT en su trabajo comunitario.

Hubo un máximo de 16 alumnos matriculados en cada ocasión en que el programa estuvo en curso, con estudiantes que venían de Sydney, New South Wales y algunos pocos de comunidades más lejanas como el Northern Territory, Cape York y las islas del Estrecho Torres. Un gran logro del Pre-IT fue el número de estudiantes que continuaron sus estudios en el área: uno está actualmente completando sus estudios part-time de licenciatura en la UTS mientras cumple con su trabajo como Analista Comercial, posición que consiguió como resultado de sus estudios IT; cinco completaron los cursos de Educación Técnica Profesional (TAFE ) 2, (Diploma en Administración de Sistemas, Certificado III en IT y Certificado III en Diseño Web); y uno completó la Certificación de Microsoft de Ingeniería en Sistemas (MCSE) 3. Además, tres estudiantes fueron inspirados a volver a la universidad para terminar sus últimos años por su éxito en el curso Pre-IT. Un estudiante ganó la confianza suficiente del curso Pre-IT para inscribirse y completar su Licenciatura en Educación (Educación Adulta) en la UTS.

Su testimonio al respecto: Este curso me dio una visión de las diferentes áreas de IT que no hubieran estado disponibles para mí de otra manera. Me ha abierto realmente los ojos y me ha alentado a impulsar mi formación. La universidad no era una opción para mí – o al menos eso era lo que pensaba. Pero ahora estoy muy interesada en seguir un curso en la universidad gracias a este maravilloso curso y a la Facultad de IT que nos proporcionó contenido académico excelente, paciencia y apoyo.

Con respecto a la difusión de las habilidades IT adquiridas en el curso dentro de sus comunidades de origen, un graduado trabajó en una base de datos de gestión cultural en el Parque Nacional Uluru-Kata Tjuta, catalogando y organizando importantes obras de arte aborigen para colaborar con su preservación y protección. Este graduado ha co-fundado una compañía que desarrolla sistemas de información para la gestión de la herencia cultural aborigen. Otros dos estudiantes abrieron juntos un Cyber-café en su pueblo natal. Algunos otros graduados usaron sus nuevos conocimientos y habilidades en una variedad de aplicaciones no técnicas. Algunos ejemplos son dos docentes que aplicaron su conocimiento IT en su forma de enseñar en la universidad y la Educación Técnica Profesional, un estudiante utilizó sus habilidades informáticas para colaborar en la promoción y conducción de campamentos para jóvenes de la comunidad Gandangara en Sydney, y dos miembros del staff del consejo municipal de áreas remotas usaron sus herramientas IT en el trabajo administrativo. Otros estudiantes han expresado una mayor productividad en sus prácticas de trabajo y una mejor comprensión de la infraestructura IT en sus comunidades. Como explicaba uno de ellos:

“Para mí, se trataba de enfrentar mis miedos respecto a los temas de IT. ¡Logré esto y mucho más! No puedo hablar mejor de este curso para darle a los indígenas la oportunidad de ‘probar’ IT”.

Después de cuatro años, el curso Pre-IT dejó de darse. Se creía que había cumplido su propósito. Para ese momento, la Facultad tenía un flujo pequeño pero estable de estudiantes inscribiéndose en sus programas de licenciatura y había decidido concentrar sus esfuerzos en este aspecto del Proyecto IPIT. Como reconocimiento de la destacable contribución realizada a la promoción de la igualdad en educación para la gente aborigen, los académicos que habían participado en el desarrollo y la realización del curso fueron premiados con el Premio de la UTS a la Igualdad y Diversidad 2007.

De proyecto a programa

Desde su nacimiento, el Proyecto ha madurado para convertirse en un programa fijo dentro de la Facultad y está produciendo resultados sólidos y sostenibles. El Programa tiene en este momento 11 estudiantes inscriptos (7 de licenciatura y 4 de post-grados). Todos los alumnos actualmente cursando están avanzando correctamente y se espera que completen sus estudios. Además, la Facultad ha tenido cuatro estudiantes más graduados del programa de licenciatura, logrando un total de 6 aborígenes graduados en IT desde el 2002. (Tabla 1). Aunque estos números parezcan bajos, es un logro excepcional comparado con la mayoría del resto de las universidades en Australia.

Inscripciones y Finalización de Estudios de estudiantes aborígenes en los Programas IT de Grado en la UTS 2000 – 2013

Año | Grado | Post | total | Grado | Post | total
2000 | 1 | 0 | 1 | 0 | 0 | 0
2001 | 2 | 0 | 2 | 1 | 0 | 1
2002 | 3 | 1 | 4 | 0 | 0 | 0
2003 | 3 | 2 | 5 | 0 | 0 | 0
2004 | 3 | 1 | 4 | 1 | 0 | 1
2005 | 7 | 1 | 8 | 0 | 0 | 0
2006 | 4 | 1 | 5 | 0 | 0 | 0
2007 | 4 | 1 | 5 | 0 | 0 | 0
2008 | 4 | 0 | 4 | 0 | 0 | 0
2009 | 4 | 0 | 4 | 1 | 0 | 1
2010 | 5 | 1 | 6 | 1 | 0 | 1
2011 | 7 | 8 | 1 | 1 | 0 | 1
2012 | 7 | 2 | 9 | 1 | 0 | 1
2013* | 7 | 4 | 11 | - | - | -

Total Finalización de Estudios: 6 0 6

Inscripciones incluye tanto a los nuevos inscriptos como a estudiantes en curso; cada estudiante se cuenta como un nuevo inscripto cada año que cursa el programa.

* Las inscripciones y finalizaciones de estudios del 2013 están hasta ahora incompletas.

De las cifras de la Tabla 1, se desprenden algunas tendencias:

Aparte de la política de admisión relajada probada en 2005, ha habido un crecimiento estable en el número de estudiantes aborígenes inscriptos en nuestros programas de licenciatura.

Desde el 2009, se ha registrado un nivel estable de éxito en las finalizaciones de curso en los estudiantes aborígenes (una por año). Dado el aumento de las inscripciones y las mejoras en los espacios de apoyo ahora implementados, esperamos que esta cifra vaya creciendo pronto.

El Programa IPIT ha empezado a atraer a estudiantes de post-grado pero hasta ahora ha fallado en lograr que terminen sus estudios, ya sea de nuestros programas de investigación como de nuestros cursos presenciales de post-grado. Sin embargo, esta situación podrá mejorar en el 2013 con un estudiante que viene progresando muy bien en el curso de certificación para Project Manager.

Algunos rasgos significativos del diseño del Programa para tener en cuenta:

Los procedimientos estándar de reclutamiento de estudiantes fueron rediseñados específicamente para IT por el subgrupo que trabaja con el Desarrollo del Curso, un trabajo en colaboración de académicos aborígenes y no-aborígenes.

El apoyo a los estudiantes, antes provisto únicamente por el centro indígena de apoyo de la Universidad (Jumbunna) fue reformado para que fuera ofrecido por un trabajo conjunto entre académicos aborígenes y no-aborígenes de la Facultad de IT y los miembros del staff del Jumbunna. Se enfatizó especialmente en la asistencia personalizada.

Dentro de la Facultad se “naturalizó” la presencia del Programa IPIT y esto se evidencia por el hecho de que el Programa ya no necesita un Project Manager, el académico aborigen ha sido promovido a Profesor y está involucrado en la enseñanza de los cursos principales de IT y se ha contratado por primera vez a un administrativo aborigen para cubrir un puesto no designado especialmente para programas aborígenes.

Los siguientes testimonios nos permiten conocer el Programa IPIT desde el punto de vista de los participantes:

Stephen Grant, Profesor

“En el 2002 comencé a trabajar en el Proyecto IPIT como profesor en la Facultad de Tecnología de la Información. Trabajé en el Proyecto junto a los Project Managers, que me dieron la oportunidad de crecer, me alentaron y me mostraron que valía la pena seguir una carrera en el área de IT. El proyecto me permitió explicarle a la gente aborigen que IT es mucho más que estar sentado en frente a la pantalla de una computadora escribiendo código. Pude enseñarles que incluye áreas como arte digital, medios interactivos, desarrollo de sitios web, entre otras. La Facultad de IT me dio la oportunidad de trabajar como docente, lo que me posibilitó emprender el desafío de compartir mis conocimientos y habilidades IT a los estudiantes. La docencia me incita a seguir aprendiendo sobre herramientas de enseñanza y aprendizaje en Educación Superior. El Programa IPIT fue una movida audaz de la Facultad para involucrarse en la promoción y el desarrollo de la idea de IT como una carrera, un entrenamiento y educación para la gente aborigen.”

El primer graduado aborigen en IT

Muchos en nuestra comunidad no ven ni comprenden a la Tecnología de la Información como una opción, pero sé que hay un montón de potencial sin explotar allí afuera. El curso me enseñó que debemos intentarlo. IT ofrece un mundo enorme de oportunidades”.

Estudiante Aborigen de Primer Año de Licenciatura

“LA UTS se ubica en el corazón de la ciudad, a pocos minutos caminando del puerto y el centro para un lado y de los alborotados y bohemios suburbios para el otro. Su fantástica estructura de clases abiertas que perfectamente se ajustaron a mi necesidad de una experiencia de aprendizaje diversa, y su promesa de un ambiente multicultural lleno de gente de diferentes orígenes y perspectivas sobre la vida, todo esto combinado hizo de esta universidad mi primera y única elección. Es una maravillosa sensación saber que encajas entre esta increíble diversidad, sin importar de dónde vienes.”

Colaboración con la comunidad aborigen local

Como su antecesor el Programa Indígena Pre-IT, que ha tenido muchos efectos en la comunidad, el Programa IPIT continúa extendiéndose más allá de la universidad para trabajar con las comunidades locales, ofreciendo capacitación profesional en IT a los Aborígenes Australianos. La Facultad, en colaboración con la Cisco Networking Academy y el National Centre of Indigenous Excellence (NCIE) establecieron un programa en el 2012 en los suburbios marginales de Redfern, que muchos consideran el centro de la Sydney Aborigen, por su histórica cantidad de habitantes indígenas, grupos comunitarios y servicios. Dos días a la semana durante diez semanas Stephen Grant enseñó IT Básica a un grupo de estudiantes aborígenes. El curso estaba insertado en una estrategia con orientación al trabajo que incluía herramientas para la búsqueda laboral, escritura de CV, manejo de entrevistas de trabajo, etc. La consultora de trabajo que daba la capacitación laboral luego encontró posibles empleadores para los participantes y al menos dos de ellos se encuentran trabajando full-time como profesionales IT.

Este programa se extendió en el 2013 al Centro Eora, una escuela técnica (TAFE) que se especializa en educación para aborígenes. El objetivo era “capacitar al capacitador”, es decir, ofrecer entrenamiento en IT a los profesores calificados como Instructores en la Cisco Academy. El curso también tuvo lugar en el Complejo NCIE y dos instructores lo terminaron con éxito. El objetivo de este programa es ofrecer a los aborígenes la capacidad de ofrecer programas profesionales de IT a su gente, sin tener que recurrir a nadie de afuera. Estas colaboraciones demuestran la capacidad de compartir acciones comunes para lograr resultados concretos.

Conclusiones

El Programa IPIT nunca tuvo la intención de ser un “Proyecto Grande”. Uno de sus propósitos era hacer posible un cambio en el modo de percibir la Tecnología de la Información, su accesibilidad y utilidad a la comunidad aborigen. Otro era lograr un cambio en las prácticas de IT en la Facultad de la UTS para asegurarse de que a los estudiantes aborígenes se les ofrecería un ambiente comprensivo y acogedor para seguir sus estudios. Estamos llegando a eso. Una de nuestras primeras metas era que tuviéramos que necesitar “dos manos” para contar la cantidad de estudiantes aborígenes inscriptos en nuestros cursos, y en el 2013 superamos ese objetivo por primera vez. Esperamos que pronto necesitemos dos manos para contar el número de graduados. Sigue siendo nuestro objetivo a largo plazo que no resulte especial que los estudiantes aborígenes estén estudiando IT y participando por su cuenta en todos los aspectos del diseño, desarrollo, implementación y uso de IT.

Mientras la iniciativa IPIT estuvo viva, los desarrollos con TICs se han hecho más accesibles para la gente aborigen y más flexibles en sus usos. Se ha producido un fuerte crecimiento de las empresas digitales dirigidas por aborígenes en el transcurso de esos años, generando espacios en los que las habilidades IT son necesitadas, respetadas, incluyendo puestos de trabajo con algunas de las más remotas comunidades. Estos desarrollos han ayudado enormemente al crecimiento del programa, en particular en el cambio de percepción de los aborígenes sobre el papel que podrían cumplir las TIC en sus vidas. Esto hizo que el reclutamiento de gente aborigen que quisiera participar en el programa fuera más fácil. Hasta donde sabemos, la situación respecto de las inscripciones y finalización de estudios de estudiantes aborígenes de IT es extraordinaria en comparación con la mayoría de las demás universidades. Creemos que el Programa IPIT y su enfoque participativo y colaborativo ha contribuido significativamente ha dicho resultado.

Referencias

1. N. del T: “aborigen” es un término que remite al nombre de la comunidad indígena principal de Australia. “Indígena” es un término apropiado para incluir a todas las comunidades de los pueblos originarios.

2. [N. del T.] Por las siglas en ingles, Technical and Further Education .

3. [N. del T.] Por las siglas en inglés, Microsoft Systems Engineer Certification.

Agradecimientos

Los autores agradecen sinceramente a los estudiantes que brindaron los testimonios incluidos en el artículo y que han contribuido tanto a la vida de la Facultad mediante su participación en nuestros programas educativos. También agradecemos la participación de los miembros aborígenes del staff con quienes trabajamos durante estos años y sin los cuales no se habría obtenido el éxito reportado. Finalmente agradecemos a los Gadigal, de la Nación Eora, en cuyo territorio se sitúa nuestra Facultad.

Bibliografía

Anderson, L., Singh, M., Stehbens, C. and Ryerson, L. Equity Issues: Every University’s Concern, Whose Business? An Exploration of Universities’ Inclusion of Indigenous Peoples’ Rights and Interests, Department of Employment, Education, Training and Youth Affairs Canberra, June 1998.

ATSIC (Aboriginal and Torres Islander Commission). New Solutions to Old Problems: Remote Indigenous Communications as Community Economic Development, Commonwealth of Australia: Canberra, 2002.

Bourke, C. J. and Burden, J. K. with Moore, S. Factors Affecting Performance of Aboriginal and Torres Strait Islander Students at Australian Universities: A Case Study for DETYA, Department of Education, Training and Youth Affairs, Canberra, Australia, 1996.

DETYA (Department of Education, Training and Youth Affairs). Equity in Higher Education. Canberra, 1999.

Dyson, L. E. and Robertson, T. Indigenous Participation in Information Technology Project: Achievements and Challenges of the First Three Years, The Australian Journal of Indigenous Education, Vol. 35, pp. 11-20, 2006.

Gale, P. “A Fair Chance for All? Indigenous Rights and Tertiary Education in Australia”. Prospects, Vol. 25, No. 4, pp. 609-621, 1995.

Grant, S., Hendriks, M. and Dyson, L. E. “The Indigenous Pre-IT Program”, in L.E. Dyson, M. Hendriks, & S. Grant (eds.), Information Technology and Indigenous People (pp. 126-131), Information Science Publishing, Hershey, USA, 2007.

Robertson, T., Dyson, L. E., Norman, H. and Buckley, B. Increasing the Participation of Indigenous Australians in the Information Technology Industry, Technical Report 2002.2, Faculty of Information Technology, Technical Report Series. University of Technology Sydney 2002a.

Robertson, T., Dyson, L., Norman, H. and Buckley, B. ‘Increasing the Participation of Indigenous Australians in the Information Technology Industries’, PDC ‘02, Malmö, 23-25 June, pp. 288-294, 2002b.

Capítulo 7: Introducción a la Interacción Persona-Computadora, por Yusef Hassan Montero

Mini biografía del autor

Trabaja en el sector de la experiencia de usuario y la visualización de información desde hace 10 años, primero como investigador en la Universidad de Granada, donde obtuvo el título de Doctor en Documentación, y actualmente como consultor y diseñador de interacción, colaborando con Scimago Lab. Actualmente compagina su labor de consultoría con la docencia en posgrados de experiencia de usuario, en instituciones como la Universitat Oberta de Catalunya, Universitat Pompeu Fabra, Universidad de Murcia o el Instituto Superior de Ciências da Informação e da Administração, entre otras. Es fundador de la revista No Solo Usabilidad (nosolousabilidad.com), coautor del Informe APEI sobre Usabilidad y miembro de la organización de UX Spain (uxspain.com).

Más información:

Ingresar al sitio web del autor

Twitter: @yusef

Mini biografía de Sergio Ortega Santamaría

Es Diplomado en Educación Social, Licenciado en Comunicación Audiovisual, Doctor en Psicopedagogía, y profesor e investigador en el Instituto Superior de Ciências da Informação e da Administração (ISCIA) de Aveiro, Portugal. Ha trabajado como profesor e investigador en la Facultad de Comunicación de la Universidad Pontificia de Salamanca, formando parte del Laboratorio de Comunicación Multimedia de esta Facultad y participando en proyectos relacionados con las tecnologías de la información y la comunicación. Desarrolla propuestas de comunicación digital interactiva, diseño y usabilidad web e innovación tecnológica en comunicación. Es autor del libro Multimedia, hipermedia y aprendizaje.Construcción de espacios interactivos, coautor del Informe APEI sobre Usabilidad, y miembro del consejo asesor de No Solo Usabilidad Journal.

Más información:

Ingresar al sitio web del autor

Twitter: @sortega

Introducción a la Interacción Persona-Computadora 1

En el presente capítulo se introducen y describen brevemente algunos de los conceptos y aspectos más relevantes -desde la perspectiva de los autores- del estudio de la interacción entre personas y computadoras. Más allá del propio contenido y explicaciones, consideramos que la verdadera utilidad de este trabajo para nuevos profesionales e investigadores en el área reside en la selección bibliográfica ofrecida, que incluye algunos de los trabajos académicos más significativos, a través de los que el lector podrá ampliar y profundizar su conocimiento sobre la disciplina.

1. Introducción

Conforme la tecnología ha ido invadiendo progresivamente todos los aspectos de nuestras vidas, se ha hecho cada vez más evidente la importancia crucial que tiene estudiar la forma en la que se relacionan las personas y los productos tecnológicos, y cómo el diseño media en esta relación. De esta importancia toma conciencia la comunidad académica de forma temprana, dando origen a una nueva área de estudio multidisciplinar, que recibe el nombre de Human-Computer Interaction o Interacción Persona-Computadora. Tal y como la definen Myers, Hollan y Cruz (1996), la Interacción Persona-Computadora es el estudio de cómo las personas diseñan, implementan y usan sistemas informáticos interactivos; y de cómo las computadoras influyen en las personas, las organizaciones y la sociedad.

Aunque la incubación de la disciplina se produce años atrás (Licklider; 1960), podemos considera 1969 una fecha clave, ya que se celebra el primer encuentro internacional y se publica la primera revista especializada (Sackel; 1997). Podemos decir que la disciplina surge de la inevitable confluencia de dos disciplinas asentadas, la informática y la ergonomía. Esta última, también conocida como “Factores Humanos” en EE.UU., es la disciplina que tradicionalmente ha estudiado la relación interactiva entre las personas, artefactos y entornos de trabajo, con especial atención a los factores humanos psicológicos, sociales y físicos que condicionan esta interacción.

No es hasta los años noventa cuando se produce una tangible profesionalización de la disciplina, conocida como Ingeniería de la Usabilidad (Usability Engineering) (Nielsen; 1994). A diferencia de la disciplina académica, la Ingeniería de la Usabilidad presta mucha menos atención a la investigación básica o al método científico, adoptando un enfoque más pragmático, orientado al retorno de inversión, la obtención de resultados y la relación coste-beneficio de los métodos de diseño y evaluación (Dumas; 2007).

Mientras que la Ingeniería de la Usabilidad nace de un entorno profesional y empresarial fundamentalmente tecnológico, de forma paralela, pero esta vez en el seno de empresas y firmas de diseño como IDEO, otra vertiente profesional, conocida como Diseño de Interacción, da sus primeros pasos (Saffer; 2010). Aunque con raíces y enfoques diferentes, el paso de los años ha diluido las fronteras entre Ingeniería de la Usabilidad y Diseño de Interacción, e incluso hay autores como Kaptelinin y Nardi (2006) que creen conveniente sustituir directamente la denominación académica de Interacción Persona-Computadora por la de Diseño de Interacción.

De forma más reciente, y con una clara influencia del área del Marketing, hacen aparición los conceptos de Experiencia de Usuario y Diseño de Experiencias de Usuario, como un intento de superar las limitaciones de las disciplinas académicas y profesionales tradicionales, afrontando la relación entre personas y tecnología desde una perspectiva aún más global, inclusiva e interdisciplinaria (Hassan-Montero; Martín-Fernández; 2005) (Hassan-Montero; Ortega-Santamaría; 2009).

Al margen de la evolución que han sufrido las diferentes vertientes académicas y profesionales, creemos que resulta imprescindible, tanto para nuevos investigadores como profesionales, conocer los conceptos centrales que fundamentan el estudio de la Interacción Persona-Computadora. En el presente capítulo se abordarán tres de los aspectos clave: Interacción, Factor Humano y Tecnología de la interacción.

2. Interacción

El objeto central de estudio de la Interacción Persona-Computadora es, como su propio nombre indica, la interacción. Este intercambio de información a veces es denominado “diálogo”, pero la realidad es que se trata de una denominación poco acertada, ya que la comunicación entre persona y computadora poco tiene que ver con la comunicación interpersonal. Las personas comparten entre sí conocimientos y experiencias muy alejadas de las capacidades de los computadoras, y su comunicación es por tanto mucho más compleja. Como explica Norman (2007), en todo caso podríamos hablar de dos monólogos, en los que a veces el sistema debe obedecer nuestras órdenes, y en otras ocasiones nosotros debemos obedecer las suyas.

Siguiendo el modelo propuesto por Norman (1988) podemos considerar la interacción como un proceso iterativo y cíclico, divisible en 3 etapas principales. En la primera etapa el usuario formularía su objetivo, decidiendo qué quiere lograr. La segunda etapa sería de ejecución; el usuario hace explícita su intención, especificando y ejecutando la acción. Por último la etapa de evaluación, en la que el usuario compara qué ha ocurrido con qué esperaba que ocurriera tras su acción, evaluando e interpretando el estado del sistema.

Lo interesante de este modelo es que nos permite identificar los problemas de uso de un sistema, que básicamente pueden ser de dos tipos: brecha en la ejecución y brecha en la evaluación. La brecha en la ejecución se produce cuando no somos capaces de relacionar qué pretendemos lograr y cómo llevar a cabo la acción con las opciones que nos ofrece el sistema. La brecha en la evaluación, en cambio, se produce cuando no somos capaces de interpretar la respuesta del sistema ante nuestra acción, o cuando esta respuesta no se corresponde con la que esperábamos.

Un concepto íntimamente relacionado con la interacción es el conocido como estilos de interacción, es decir, los diferentes modos o formas en las que el usuario puede interactuar con el sistema (Preece et al.; 1994) (Shneiderman; 1997).

El estilo de interacción con más historia es el conocido como de línea de comandos. En este modo de interactuar el usuario introduce instrucciones o comandos a través de un prompt, y el sistema ejecuta esas instrucciones o, en caso contrario, devuelve un mensaje de error. Este estilo de interacción requiere que el usuario posea un conocimiento previo acerca de qué instrucciones son posibles y qué resultado provocará cada una. Es un estilo de interacción, por tanto, problemático para usuarios no expertos (brecha de ejecución), pero por otro lado resulta muy eficiente para usuarios expertos, lo que explica por qué aún podemos encontrar numerosos sistemas basados en líneas de comandos.

Otro estilo de interacción, presente en la inmensa mayoría de dispositivos que utilizamos cotidianamente, es el basado en menús de selección o navegación. En este caso el sistema ofrece una serie de opciones posibles al usuario, y éste solo tiene que elegir la que mejor responda a sus objetivos o necesidades. Se trata de un estilo de interacción mucho más sencillo para usuarios no expertos, ya que no exige un conocimiento sintáctico previo. Aún así es un estilo que puede resultar complejo de usar cuando las opciones que se presentan son de difícil interpretación para el usuario.

Los formularios representan otro estilo de interacción ampliamente extendido. Por analogía a los formularios clásicos en papel, el sistema presenta una serie de campos que el usuario debe completar. Entre los campos del formulario algunos pueden utilizar un modelo de menú de selección, como las listas desplegables.

Otro estilo de interacción es el conocido como diálogo en lenguaje natural, un modo de interactuar en el que los usuarios dan instrucciones, escritas o habladas, utilizando el lenguaje natural, es decir, sin someterse a reglas y vocabularios rígidos y predefinidos. Aunque es un estilo de interacción sobre el que se lleva muchos años investigando, sus aplicaciones prácticas aún son limitadas. Algunas aproximaciones, a modo de ejemplo, son los buscadores de Internet o los asistentes personales como Siri (Apple).

Por último no podemos olvidar el estilo de interacción predominante en la mayoría de sistemas operativos; el conocido como manipulación directa. Se trata de un modo de interacción que permite al usuario manipular y controlar físicamente los elementos presentes en la interfaz, incluyendo la posibilidad de seleccionar, arrastrar o mover objetos, así como la de deshacer las acciones realizadas. Con la reciente proliferación de los dispositivos táctiles, esta manipulación podemos decir que se ha vuelto aún más directa, ya que no está mediada por dispositivos apuntadores como el ratón.

3. El factor humano

El estudio de la Interacción Persona-Computadora nos exige comprender el funcionamiento y comportamiento de los diferentes elementos que intervienen en la interacción: tecnología y factor humano, pero particularmente este último, el más complejo y enigmático de todos.

Para ello la disciplina se nutre de una gran variedad de teorías y evidencias empíricas tomadas de diferentes disciplinas, como sociología, psicología, antropología, etc. De entre todas, sin ninguna duda, el corpus teórico que más peso ha tenido en el desarrollo de la Interacción Persona-Computadora hasta la fecha ha sido la psicología cognitiva, en especial el modelo de Procesamiento Humano de Información (Broadbent; 1958) (Card, Moran, Newell; 1983) y todas las micro-teorías a las que da cabida.

El Sistema de Procesamiento Humano de Información caracteriza a las personas como procesadores activos de información, utilizando la metáfora computacional. Es decir, el procesamiento de información en las personas se concibe por analogía a como éste se produce en los computadoras. Los humanos adquieren información a través de la percepción, poseen un procesador central que se encarga de razonar y tomar decisiones, almacenan información (memoria), y la materializan a través de acciones motoras.

Aunque por razones obvias la explicación detallada de este modelo y sus teorías relacionadas superan los objetivos del presente trabajo, sí creemos necesario introducir algunos de sus aspectos clave, y su repercusión en el estudio y práctica de la interacción entre personas y computadoras.

Por un lado debemos destacar que la atención de los humanos es selectiva. Esto quiere decir que concentramos nuestro entendimiento en una parte de la realidad, mientras desatendemos el resto. Como indica Cowan (1988), la atención selectiva requiere que ciertos análisis perceptuales tengan lugar de forma automática, en forma de habituación a los estímulos desatendidos. Es decir, no es que desconectemos canales sensoriales o rechacemos completamente los estímulos desatendidos, sino que nos habituamos a ellos. Sólo cuando se produce un cambio de gran significación en estos estímulos desatendidos, superan la barrera de la habituación y se ubican en el foco de nuestra atención. Desde la perspectiva del estudio de la Interacción Persona-Computadora la naturaleza selectiva de la atención humana sugiere que un producto interactivo fácil de usar será aquel que no sature ni interrumpa innecesariamente nuestra atención.

Por otro lado, gracias a la investigación en psicología cognitiva, sabemos que si bien la capacidad de nuestra memoria a largo plazo no tiene límite (conocido), nuestra memoria operativa – aquella que utilizamos para almacenar temporalmente información para el razonamiento y la toma de decisiones conscientes – sí tiene una capacidad muy limitada (Miller; 1956) (Cowan; 2001). Esto implica que cualquier tarea interactiva que requiera retener en la memoria operativa al mismo tiempo un número excesivo de datos, resultará muy compleja de ejecutar para el usuario.

La forma en la que las personas procesamos información y tomamos decisiones resulta también de una importancia vital en el estudio de la interacción. Como describe Kahneman (2003), podemos diferenciar entre dos modos genéricos de función cognitiva: razonamiento e intuición. Nuestro sistema racional es el que nos permite tomar decisiones meditadas; una forma de procesar información lenta, basada en reglas lógicas y que requiere esfuerzo. Por otro lado, el sistema intuitivo es rápido, automático, eficiente, emocional, asociativo y se alimenta de la experiencia. Si consideramos que la mayor parte de nuestro comportamiento diario lo rige nuestra intuición, este hecho implica que el diseño de productos interactivos usables será aquel que, parafraseando el título del famoso libro de Steve Krug, no nos haga pensar. Un diseño que permita un uso eficiente e intuitivo, y que prevenga que el usuario cometa errores, producto de esta forma automática y no meditada de tomar decisiones durante la interacción.

Por último, y no menos importante, un producto interactivo no sólo debe adaptarse a nuestras limitaciones y capacidades cognitivas, también debe hacerlo a nuestras limitaciones motrices. En este sentido, seguramente la norma más importante es la conocida como ley de Fitts (Fitts; 1954) (Fitts, Peterson; 1964), que señala que la dificultad para alcanzar un objeto está directamente relacionada con el tamaño del mismo y su distancia respecto al punto de partida. Como se puede deducir, es una ley con evidentes implicaciones en el diseño de interfaces de usuario.

4. Tecnología de la interacción

La interfaz de usuario es el elemento y lugar de contacto entre usuario y computadora, englobando todos aquellos componentes, tanto software como hardware, destinados a posibilitar el intercambio de información entre persona y computadora.

El desarrollo de la disciplina ha transcurrido de forma paralela a la evolución de las tecnologías que conforman estas interfaces. La aparición de las interfaces gráficas de usuario y del modelo WIMP (Window, Icon, Menu, Pointing device), así como de nuevos dispositivos y formas de interacción, ha modificado y ampliado las posibilidades y modos en los que se han relacionado personas y computadoras durante todos estos años. Al mismo tiempo, la investigación académica en la disciplina, ha propiciado y anticipado el propio desarrollo comercial de estas tecnologías.

Entre los dispositivos que forman parte de la interfaz de usuario se suele distinguir entre dispositivos de entrada y de salida, en función de si están destinados a la transmisión de información del usuario hacia el computadora o viceversa, si bien existen también dispositivos que cumplen al mismo tiempo ambas funciones. Entre los avances más destacados en interfaces de salida podemos señalar el incesante aumento de la resolución y calidad de imagen de las pantallas, su cada vez menor grosor, o la irrupción en el mercado de la tecnología 3D. Por otro lado, los dispositivos de entrada tradicionales, como el teclado o el ratón, se ven desplazados en más contextos a favor de nuevas interfaces gestuales (Saffer; 2008), como las pantallas multi-táctiles, el uso de acelerómetros en mandos de videoconsolas y dispositivos móviles para detectar su movimiento, o el uso combinado de cámaras y sensores de profundidad para identificar gestos del usuario sin necesidad de contacto físico alguno. A estos dispositivos hay que añadir los avances de interfaces no gestuales como las basadas en reconocimiento de voz o en el seguimiento de la mirada (eye-tracking).

Todos estos avances expanden las posibilidades de interacción y facilitan el uso. Por ejemplo, las interfaces táctiles requieren menos esfuerzo de aprendizaje que aquellas basadas en dispositivos apuntadores como el mouse. Mientras que aprender a usar un mouse exige vincular mentalmente lo que hacemos sobre una superficie y lo que ocurre en otra (pantalla), las interfaces táctiles ofrecen un modo de interactuar más directo e intuitivo. No obstante tampoco debemos obviar que, como advierten Norman (2010), Norman y Nielsen (2010), el uso de las interfaces gestuales no es tan “natural” como puede parecer, y que descuidar principios fundamentales de interacción puede provocar problemas de usabilidad.

Referencias

1. Pensando en los lectores latinoamericanos, con anuencia de los autores, hemos suplantado: computadora por ordenador y ratón por mouse.

Bibliografía

Broadbent, D.E., Perception and communication, Londres, Pergamon Press, 1958, p. 338.

Card, S.K., Moran, T., Newell, A., The psychology of human-computer interaction, Hillsdale, NJ: Erlbaum, 1983.

Cowan, N., “Evolving Conceptions of Memory Storage, Selective Attention, and Their Mutual Constraints Within The Human Information-Processing System”, en: Psychological Bulletin, vol.104, n. 2, pp. 163-191, 1988.

Cowan, N., “The magical number 4 in short-term memory: A reconsideration of mental storage capacity”, en: Behavioral and Brain Sciences, n° 24, pp. 87-114, Cambridge University Press.

Dumas, J., “The great leap forward: The birth of the usability profession (1988-1993)”, En: Journal of Usability Studies, 2 (2), febrero, 2007, pp. 54-60.

Fitts, P.M., “The information capacity of the human motor system in controlling the amplitude of movement”, en: Journal of Experimental Psychology, vol. 47, n° 6, pp. 381-391, 1954.

Fitts, P.M., Peterson, J.R., “Information capacity of discrete motor responses”, en: Journal of Experimental Psychology, vol. 67, n° 2, pp.103-112, 1964.

Hassan-Montero, Y., Martín-Fernández, F.J., “La Experiencia del Usuario”, en: No Solo Usabilidad, nº4, 2005. Disponible en: [Ver en línea] .

Hassan-Montero, Y., Ortega-Santamaría, S., Informe APEI de usabilidad, Gijón, Asociación Profesional de Especialistas en Información, 2009. Disponible en: nosolousabilidad.com

Kahneman, D., “A Perspective on Judgment and Choice”, American Psychologist, Vol. 58, n° 9, pp. 697-720, 2003.

Kaptelinin, V., Nardi, B.A., Acting with technology: activity theory and interaction design, Cambridge, MA, MIT Press, 2006.

Licklider, J.C.R., Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronics, vol. HFE-1, pp 4-11, marzo, 1960.

Miller, G. A. “The magical number seven, plus or minus two: Some limits on our capacity for processing information” Psychological Review 63 (2), pp. 81-97, 1956.

Myers, B.A., Hollan, J., Cruz, I. (Eds.), “Strategic Directions in Human Computer Interaction”, en: ACM Computing Surveys, Vol. 28, n. 4, diciembre, 1996.

Nielsen, J., Usability Engineering, Morgan Kaufmann, San Francisco, 1994.

Norman, D.A., The Psychology of Everyday Things, Basic Books, 1988.

Norman, D. A., “Cautious Cars and Cantankerous Kitchens: How Machines Take Control”, en: The Design of Future Things, New York, Basic Books, 2007.

Norman, D.A., “Natural user interfaces are not natural”, en: Interactions, Vol. 17, Issue 3, pp. 6-10, 2010.

Norman, D.A., Nielsen, J., “Gestural interfaces: a step backward in usability”, en: Interactions, Vol. 17, Issue 5, pp. 46-49, 2010.

Preece, J. J., Rogers, Y., Sharp, H., Benyon, D., Human-Computer Interaction, Essex, UK, Addison Wesley Publishing, 1994.

Sackel, B. (1997). Human-Computer Interaction-Whence and whither?, Journal of the American Society for Information Science, 48 (11), pp. 970-986, 1997.

Saffer, D., Designing Gestural Interfaces, O’Reilly Media, Inc., 2008.

Saffer, D., Designing for Interaction: Creating Innovative Applications and Devices, 2ª Edición, New Riders, Berkeley, 2010.

Shneiderman, B,Designing the user interface, Addison-Wesley Publishing Company, 1997.

Capítulo 8: Entre la Arquitectura y la Información, por Jorge Arango

Mini biografía del autor

Es un arquitecto de información con más de 18 años de experiencia en el diseño y producción de experiencias digitales. En su formación académica obtuvo un BA Arquitectura en la University of Arkansas, EE.UU. Es fundador y director de BootStudio, una de las primeras agencias de diseño de experiencias de usuario en América Central. Ha escrito, presentado, y organizado conferencias sobre temas relacionados al diseño de experiencias de usuario en varios países. Ha sido Presidente y Director del Instituto para la Arquitectura de la Información y jefe de redacción de la revista Boxes and Arrows.

Más información:

Ingresar al sitio web del autor

Twitter: @jarango

Entre la Arquitectura y la Información

Introducción

La popularización de Internet ha causado cambios importantes en la forma en que los seres humanos accedemos a la información y cómo nos relacionamos los unos con los otros. Actualmente tenemos acceso a mayor información que nunca antes. Aunque esto es sin duda positivo, esta explosión informática también trae un reto considerable: mientras más información tenemos, más difícil se hace encontrar y entender lo que estamos buscando. Como resultado, los diseñadores digitales tenemos un compromiso ético de lograr que la información sea fácil de encontrar y entender. La arquitectura de la información es el área de práctica que está enfocada en lograr que la información sea fácil de encontrar y de entender. La “arquitectura” en esta frase es más que una metáfora: existe evidencia que las personas experimentan los artefactos que diseñamos como “espacios informáticos”, análogos digitales a los espacios físicos que habitamos. La arquitectura ofrece lecciones valiosas que pueden ayudar a que estos espacios informáticos satisfagan mejor las necesidades de los seres humanos que los usan.

Un nuevo tipo de entorno

Actualmente contamos con mejor acceso a más información que nunca antes. La revolución digital ha tocado todos los rincones del planeta, trayendo con sí la promesa de más formación y entendimiento entre las personas. Sin embargo, el incremento en la cantidad de información también trae con sí el potencial de confusión: mientras más información hay, más difícil se hace encontrar y entender lo que uno está buscando.

Ventajas de la proliferación de espacios informáticos

De acuerdo al CIA World Factbook, en el 2010 más de dos mil millones de personas tenían acceso a Internet. Ese segmento de la población del planeta goza de la colección de contenido más grande que ha existido, y que crece a un paso vertiginoso: cada minuto enviamos 204 millones de mensajes por correo electrónico, publicamos 3,000 imágenes nuevas en Flickr, escribimos 6 artículos nuevos en Wikipedia, y subimos 30 horas de video a YouTube 1.

Esta información representa una oportunidad sin precedentes para que las personas de todo nivel social y ubicación geográfica puedan aprender y compartir. Entre 1970 y el 2005, la tasa global de analfabetismo se redujo a la mitad 2; actualmente casi 89% de las personas mayores de 15 años pueden leer y escribir 3. Los medios digitales, en especial el Internet, hacen que sea factible llevar más información a lugares remotos. Aunque todavía existe una brecha digital entre el nivel de acceso per capita que gozan los países desarrollados versus aquellos en vías de desarrollo, desde el 2003 las Naciones Unidas cuenta con un plan para ayudar a cerrar la brecha 4. El progreso ha sido lento, pero definitivo.

Esta información no se publica de forma centralizada, como sucede en los medios tradicionales. Todos los usuarios de Internet tienen a su disposición mecanismos baratos (y hasta gratuitos) para expresar sus opiniones y publicar sus ideas. Con la proliferación de “teléfonos inteligentes” como el iPhone o los dispositivos Android, más de mil millones de personas 5 tienen en sus bolsillos computadoras extremadamente poderosas que les permiten acceder a Internet y publicar contenido de forma inmediata utilizando un conjunto sin precedentes de sensores y dispositivos de captura: cámaras de fotografía y vídeo, micrófonos, giroscopios, geo-localización global (GPS), etc. El resultado inevitable es un cambio en el equilibrio de fuerzas entre las instituciones, los gobiernos, y los seres humanos que interactuamos con ellos.

La proliferación de los espacios informáticos también está cambiando la gobernación de los países. La disponibilidad de canales digitales como Twitter y Facebook ha sido uno de los causantes de la onda de revoluciones que ha tumbado varios gobiernos totalitarios en el Medio Oriente 6. En las democracias, proyectos como data.gov.uk —un portal del gobierno del Reino Unido que hace asequible la información del estado— están cambiando la relación entre gobernantes y gobernados, con la promesa de incrementar la transparencia en los quehaceres públicos.

La aguja en el pajar

El principal reto que trae con sí la explosión informática es que al tener tanta información disponible, se hace muy difícil encontrar exactamente lo que uno está buscando. Una búsqueda sencilla en Google genera cientos de miles (y en algunos casos, millones) de resultados. Además, no todas estas fuentes son igual de confiables. Un artículo publicado en el New York Times tiene mayor credibilidad que uno publicado en el blog personal de un aficionado a la astrología. Dado que los usuarios acceden a todos estos sitios usando los mismos mecanismos (navegadores web, interfaces de usuario y estructuras similares, etc.), existe un efecto nivelador que hace que los usuarios confíen por igual en canales de trayectorias muy diferentes.

El mover nuestras actividades a espacios informáticos también nos obliga a manejar el reto del colapso contextual. En el mundo físico es obvio cuando estamos interactuando en un espacio privado versus un espacio público, y nos comportamos de forma diferente en cada uno. En Internet estas diferencias no son tan obvias. Como ha resaltado el arquitecto de información Andrew Hinton, una usuaria de Twitter puede asumir que está “susurrando” en un espacio privado con un amigo, pero al equivocarse por un símbolo (“@“ en vez de “d”) puede en vez anunciar su secreto a miles de personas instantáneamente 7.

El colapso de entornos no es el único riesgo a nuestra privacidad que encontramos en Internet. El crecimiento de las redes sociales está causando que muchas personas compartan más información privada que antes, intencionalmente o de forma inadvertida. El diseño de algunos de estos sitios hace que configurar estos detalles sea complicado, y muchas personas no entienden que pueden estar poniendo en juego la privacidad de sus amigos y familiares al subir contenido a estos sitios. Como resultado, es más difícil tomar decisiones al compartir nuestra información.

Cómo hemos enfrentado estos retos hasta ahora

Muchos de estos retos son nuevos para los diseñadores, por lo que no tenemos buenos mecanismos para enfrentarlos. Cuando han aparecido nuevos medios en el pasado, los primeros artefactos en el nuevo medio se han asemejado a los de los medios anteriores. Por ejemplo, las primeras cintas cinematográficas se rodaban con la cámara fija en el centro de un escenario, utilizando el mismo punto de vista inmóvil que vería el miembro de la audiencia, como si se tratara de una obra teatral. Eventualmente, directores como Sergei Eisenstein comenzaron a explorar la gramática del medio, variando la posición de la cámara, haciendo uso creativo del proceso de edición, etc.

Lo mismo ha ocurrido con el web. Durante la primera década de existencia de éste nuevo medio, las metáforas que regían la creación del contenido venían del mundo de las publicaciones. Los primeros sitios web eran considerados un tipo de panfleto electrónico, y todavía hoy podemos ver vestigios de éste fenómeno cuando hablamos de “diagramar” “páginas” web. Un alto porcentaje de los documentos publicados actualmente en línea todavía emplean diagramados fijos y rígidos, y los diseñadores intentan imponer el mismo nivel de control sobre los tratamientos tipográficos, tamaños, y relaciones de los elementos visuales que utilizan cuando diseñan para medios impresos.

Pensar en estos artefactos como publicaciones fue útil en estas primeras fases del web, antes de que hubiéramos podido identificar las estructuras gramaticales y semánticas del nuevo medio. Sin embargo, como metáfora para nuestro trabajo es cada vez menos útil. Por un lado, el contenido que se publica en el web está cada vez menos atado a la forma en que el usuario lo consume. El diseño para publicaciones impresas siempre ha sido inflexible: el diseñador sabía de antemano las dimensiones y características del producto terminado, y producía un diseño definitivo para que fuera plasmado sobre papel. Ahora contamos con una diversidad de tamaños de pantallas y modalidades de interacción (ej. Interfaces táctiles, punteros y ratones, interfaces de voz, etc.) por lo que ya no existe una versión definitiva del diseño de un artefacto digital. La experiencia de leer un documento en una pantalla táctil de 8.9 centímetros es muy diferente que hacerlo en una pantalla de 68.6 centímetros con un ratón; y la popularización de técnicas como el diseño responsivo —un esquema que permite variar la presentación del contenido en base al tamaño de las pantallas de los dispositivos— está forzando que muchos diseñadores tengan que adoptar estrategias de diseño menos rígidas.

Las publicaciones tradicionales también han tenido estructuras relativamente inflexibles. Por ejemplo, las revistas ofrecen índices que relacionan los títulos de los artículos particulares a las páginas en que aparecen. Al igual que las revistas, las primeras páginas web, que eran creadas “a mano”, también contaban con estructuras jerárquicas sencillas e inflexibles. Sin embargo, la popularización de sistemas de gestión de contenido (ej. Wordpress, Drupal, etc.), hace que sea cada vez más factible producir esquemas de navegación dinámicas.

Pero las diferencias no solo están limitadas a la interacción que ocurre en las computadoras tradicionales. Los usuarios también pueden acceder a la información por otros canales completamente ajenos al web. Por ejemplo, es común que las organizaciones provean servicios de respuesta de voz interactiva (IVR, por sus siglas en inglés) por teléfono. Mucha de esta información es similar a la que publican en el web, pero normalmente no pensamos en el sistema de IVR como una “publicación”. Otro ejemplo son los apps para los teléfonos inteligentes: en muchos casos proveen información similar a la que ofrecen los sitios web, pero lo hacen usando mecanismos de interacción diferentes.

Otra dificultad que enfrentamos al pensar en los sitios web como publicaciones es que el web es un medio fundamentalmente social, pero la metáfora de la publicación no acomoda los usos sociales. La forma de las revistas, libros, y otras publicaciones impresas evolucionó con un solo lector simultáneo en mente; es posible leer una revista junto a dos o tres personas, pero no es práctico hacerlo con 900 personas. Un sitio web puede ser visto fácilmente por 900 personas simultáneamente; de hecho, en algunos casos, el valor del sitio es precisamente que permite la interacción de muchas personas simultáneamente. El pensar en estos canales como publicaciones limita nuestro vocabulario y por ende las posibilidades de diseño que estamos dispuestos a considerar.

¿Publicación o lugar? Ambos

Dado que la metáfora de la publicación se queda corta, ¿Hay alguna otra que podamos usar para informar lo que hacemos? Si analizamos el lenguaje que usamos para describir nuestro trabajo, encontraremos parte de la respuesta: muchas de las metáforas que usamos sugieren que pensamos sobre estos artefactos como lugares. Hablamos de “visitar” “sitios” web y de “encontrarnos” con nuestros amigos en Facebook. Los periódicos erigen “muros” de pago, e “ingresamos” a la banca en línea para revisar nuestras cuentas. Un estudio realizado en 1998 por investigadores de IBM y la Universidad de California, Santa Cruz sugiere que las personas piensan en el web como un tipo de espacio físico en el que se pueden mover, basado en el lenguaje que usan para describir sus interacciones en el medio 8. Los arquitectos de la información Andrea Resmini y Luca Rosati explican la conexión en su libro Pervasive Information Architecture: los mecanismos mentales que usamos para orientarnos y navegar en los espacios informáticos son similares a los que empleamos para orientarnos y navegar en el mundo físico 9.

Mi principal argumento en este artículo es que los espacios informáticos que diseñamos y utilizamos a diario son una experiencia nueva para los seres humanos: los experimentamos como un nuevo tipo de “publicación espacial” que cae en medio de una gama que tiene en un extremo a los lugares físicos, como los edificios, y en el otro a las publicaciones tradicionales como los libros y revistas. En qué parte de la gama podemos ubicarlos exactamente depende del tipo de artefacto del que estamos discutiendo: el sitio web de una revista puede ser visto como una publicación tradicional, mientras que una red social puede ser experimentada de forma más parecida a un lugar. Siempre y cuando se trate de un artefacto interactivo (no-linear), el usuario lo va a experimentar entre uno de estos dos extremos. Los espacios informáticos combinan algunas características de las publicaciones (“páginas”, “contenido”, etc.) y algunas características de los lugares (“navegar”, “ingresar”, “sitio”, etc.).

La implicación es que el diseño de estos espacios puede estar informado por dos campos: la literatura (y por extensión, las ciencias de la información), y la arquitectura. La conjunción de estos campos es donde se encuentra la arquitectura de la información (AI), y las raíces de la AI están fundamentadas en ambos campos, como veremos a continuación. Sin embargo, hasta ahora, la atención de los arquitectos de la información ha estado enfocada casi exclusivamente en las lecciones provenientes de las ciencias de la información. Mi intención es que comencemos a tomar en serio la arquitectura como fuente que informe la creación de los entornos informáticos. Para hacerlo, primero debemos ver cuáles son las raíces de la arquitectura de la información.

La Arquitectura de la Información

La arquitectura de la información es el área de práctica profesional que busca traer orden y coherencia a estos nuevos entornos para lograr que la información sea más fácil de encontrar y entender a través de múltiples canales y dispositivos. La AI define las estructuras semánticas que usan las personas para encontrar y entender la información. Los productos de la AI pueden experimentarse de diversas formas: en los esquemas de navegación de un sitio, en la forma en que está organizada la ilustración de una explicación médica, o en el rotulado en los pasillos de un hospital que le muestran a los pacientes dónde están ubicados los diversos espacios del edificio. Lo que tienen en común es la organización de un conjunto de elementos discretos de significado en relaciones entre sí de forma que comuniquen claramente.

Morville y Rosenfeld

La mayoría de los profesionales de diseño que conocen sobre la arquitectura de la información llegaron a este campo por medio de un libro: Arquitectura de la Información para el World Wide Web, de Peter Morville y Louis Rosenfeld 10. El “libro del oso polar”, como se le conoce en la industria, ha sido el texto estándar de referencia sobre AI desde su primera edición en 1998. Ha sido un libro muy influyente en la industria, y ha ayudado a definir la forma en que muchos los profesionales en el campo entienden el tema.

Los principios de diseño propuestos en este libro buscan resolver problemas de organización de la información, específicamente para sitios web, desde el punto de vista de las ciencias de la información. Morville y Rosenfeld son bibliotecarios, y su libro refleja su experiencia en este campo: está enfocado en la creación de esquemas taxonómicos, definición de componentes de búsqueda, etiquetado, y organización general de los sitios web. Morville y Rosenfeld hacen explícita la diferencia entre los aspectos estructurales de los sitios web y otros aspectos que tienen un impacto importante sobre la experiencia del usuario de los sitios, como el diseño de la información (el diagramado de las páginas que componen el sitio), y aspectos del diseño visual como los tratamientos tipográficos, imágenes, colores, etc.

El libro de Morville y Rosenfeld divide los problemas (el programa) del diseño de una arquitectura informática en tres partes: el entorno, el contenido, y los usuarios. El entorno consiste en aspectos contextuales del proyecto: objetivos de la organización, aspectos políticos y culturales, requisitos tecnológicos, recursos disponibles, etc. El contenido incluye los tipos de documentos, objetos de contenido, metadata, estructuras existentes, y más. Los usuarios son las audiencias que van a interactuar con el producto: el esquema propone analizar sus necesidades y objetivos, tareas que deben realizar, perfiles/experiencia, y más.

Wurman

Aunque el libro del oso polar es extremadamente popular, Morville y Rosenfeld no son los primeros en haber utilizado el título “arquitectura de la información”. El arquitecto Richard Saul Wurman originó el término en los la década de 1960, y lo utilizó explícitamente como título conferencia anual del Instituto Americano de Arquitectos (AIA) en 1976. Wurman trae a la arquitectura de la información una clara sensibilidad arquitectónica. La diferencia entre la arquitectura y el diseño, según Wurman, es que la arquitectura busca definir el “¿Qué?” de los proyectos — qué problemas buscan resolver — versus el “¿Cómo?”, que es lo que hacen los diseñadores. Su obra ha estado enfocada en utilizar técnicas arquitectónicas para entender una variedad de temas de interés general, desde mapas de autopistas hasta manuales sobre salud. La mayoría de esta obra consiste en lo que llamamos actualmente diseño de información; un ejemplo es su mapa del metro de Tokio 11, que busca hacer entendible un conjunto de ideas complejas por medio de una gráfica sencilla, impactante, y con una estructura clara.

En 1996 (dos años antes que el libro de Morville y Rosenfeld) Wurman publicó Information Architects, libro que incluye la siguiente definición del término:

Arquitecto de la Información [L infotectus] 1) el individuo que organiza los patrones inherentes en la data, haciendo que lo complejo sea claro. 2) una persona que crea la estructura o mapa de la información que permite que otros encuentren sus propios caminos hacia el conocimiento. 3) la práctica profesional emergente del siglo XXI que responde a las necesidades de la época enfocada en la claridad, el entendimiento humano, y la ciencia de la organización de la información 12.(Énfasis en el original)

Esta definición resume claramente el reto que busca resolver la arquitectura de la información, y hace énfasis en los objetivos humanistas del campo.

Morville y Rosenfeld habían comenzado a usar el término “arquitectura de la información” antes de conocer la obra de Wurman. Según Morville, cuando leyó el libro Information Architects por primera vez (en 1996), su reacción fue pensar “esto no es arquitectura de la información del todo, esto es diseño de información” 13. Sin embargo, claramente ambos precedentes comparten el mismo objetivo: lograr que la información sea fácil de encontrar y entender por medio de estructuras informáticas que sirvan las necesidades de los seres humanos que las van a utilizar.

En fin, la arquitectura de la información contemporánea tiene raíces en las ciencias de la información, por medio de Rosenfeld y Morville, y en la arquitectura tradicional, por medio de Wurman. Mucho del discurso en el campo durante la última década ha estado enfocado en la primera a exclusión de la segunda.

Vínculos, Nodos, y Orden

Aunque los retos que presentan los espacios informáticos son nuevos, los seres humanos tenemos amplia experiencia diseñando espacios físicos: el campo de la arquitectura tradicional —el diseño de los edificios y espacios urbanos que habitamos— cuenta con un rico historial de prácticas que pueden ayudarnos a generar espacios informáticos coherentes y comprensibles. En conjunto con técnicas aprendidas de otros campos relacionados como el diseño de la información y las ciencias de la información, podemos comenzar a desarrollar un área de práctica altamente enfocada en resolver los problemas que enfrentamos al diseñar esto espacios informáticos.

Qué hacen los arquitectos tradicionales

El producto de los arquitectos tradicionales son las instrucciones necesarias para que otros puedan construir edificios: composiciones intencionales de formas y espacios que proveen entornos que podemos habitar. Estos son los lugares donde vivimos, trabajamos, aprendemos, y más. Decimos que los edificios son composiciones intencionales porque han sido diseñadas para el propósito explícito de ser habitadas. (Hay muchos otros entornos habitables en el mundo que no han sido creados intencionalmente: nuestros antecesores lejanos buscaban refugio donde pudieran.)

Enfoquémonos en los dos elementos que mencioné arriba: formas y espacios. Las formas son el componente físico de los edificios. Son los elementos tangibles que componen un edifico: sus muros, ventanas, columnas, techo, jardines, etc. Las formas pueden contener otras formas: por ejemplo, una pared puede contener una ventana. Los espacios son los vacíos que separan las formas que componen el edificio. Son definidas por (y definen) la relación entre estas formas. Los espacios no son “reales” en el mismo sentido que las formas: solamente las experimentamos temporalmente cuando estamos en el edificio. Los espacios no tienen existencia propia más allá de esta experiencia individual, pero son críticos para el funcionamiento de lo que entendemos como “arquitectura”. Las formas y los espacios no pueden existir independientemente los unos de los otros: están profundamente relacionados entre sí. Son el yin y el yang de la arquitectura.

Qué hacen los arquitectos de la información

La arquitectura de la información tiene muchas cosas en común con la arquitectura, pero hay una diferencia importante: el objetivo de la AI no es la producción de espacios para habitar, sino espacios para comprender. Mientras que la arquitectura produce entornos para habitar por medio de la organización de espacios y formas, la arquitectura de la información produce entornos para comprensión mediante la organización de nodos y vínculos. Al pensar en los nodos y vínculos como elementos análogos a las formas y espacios que emplea la arquitectura tradicional, podemos emplear metodologías devengadas de este campo centenario para informar el diseño de los espacios informáticos. Veamos estos elementos más de cerca.

Los nodos son unidades individuales de significado. Son los elementos de contenido —los textos, imágenes, videos, etc. —que en conjunto comunican un concepto o idea. Un nodo puede ser tan sencillo como una palabra, o puede ser infinitamente complejo. Al igual que las formas de un edificio, los nodos pueden contener otros nodos: Una página web es un nodo, pero también lo son las oraciones, imágenes, y otros elementos que la componen. Un “sitio web” puede ser considerado un nodo en un conjunto más grande (el grupo de sitios que comprenden la presencia digital de una organización, o el web en general.) Una de las responsabilidades más importantes de un arquitecto de la información es definir los límites de un nodo para que comunique significado de la manera más óptima.

Hablemos ahora sobre el segundo elemento con que trabajamos los arquitectos de la información: los vínculos. Los vínculos son los elementos definen (y son definidos) las relaciones que existen entre dos o más nodos; son el equivalente de los espacios en la arquitectura tradicional. Estas relaciones vienen de muchos tipos diferentes. Para aquellos que trabajamos en el web, el ejemplo más obvio son los hipervínculos, en los que un nodo (una palabra o un grupo de palabras) apunta a otro nodo (una página o una sección de una página, por ejemplo) de forma que haciendo clic con un puntero en el primer nodo causa que la pantalla del usuario cargue y muestre el segundo nodo.

Sin embargo, existen muchos otros tipos de relaciones que pueden establecerse entre nodos. Algunas obvias:

Secuenciales: un nodo sigue a otro en una secuencia predefinida. Por ejemplo, múltiples palabras pueden unirse para formar oraciones, que en sí puede unirse para formar párrafos, secciones, capítulos, etc.

Espaciales: relaciones definidas por la posición geométrica entre dos nodos. Por ejemplo, dos imágenes pueden ser comparadas al ubicarlas una al lado de la otra.

Jerárquicas: cuando un nodo contiene a otro nodo. Por ejemplo, como mencionamos arriba, las páginas contienen colecciones de nodos que las definen.

Conceptuales: un nodo dispara en la mente del usuario asociaciones conceptuales con un segundo nodo, aún cuando este no está presente. Por ejemplo, podemos presentar una fotografía al usuario, y luego utilizar otra fotografía que utilice los mismos componentes en una composición diferente. La memoria de la primera imagen ayuda a crear un vínculo entre los dos nodos en la mente del usuario.

Tomando en cuenta estos conceptos, podemos definir la arquitectura de la información como la composición intencional de nodos y vínculos como estructuras organizadas que facilitan el entendimiento. Esta definición es intencionalmente amplia, e incluye muchos otros artefactos culturales dentro del alcance de la arquitectura de la información: libros, mapas, catedrales Góticas, y más. El producto final de la arquitectura de la información puede tomar muchas formas: un sitio web, una película (ej. Powers of 10 de Charles y Ray Eames 14), un libro (ej. cualquiera de la serie Understanding de Wurman), la organización de los pasillos en un supermercado, y más.

Estas composiciones coherentes de elementos se logran mediante el ordenamiento de los nodos y vínculos de forma tal que puedan producir estructuras espacio-semánticas que comuniquen significado claramente. Existen diversas metodologías que pueden ser empleadas para lograr estos ordenamientos: por ejemplo, Wurman propone el esquema LATCH, que sugiere que existen cinco formas de organizar la información: en torno a su ubicación, en orden alfabético, en orden cronológico, por categorías, y por jerarquía. (LATCH es un acrónimo en inglés de estos cinco conceptos: location, alphabet, time, category, y hierarchy.) El campo de la arquitectura tradicional también cuenta con una amplia literatura que propone diferentes metodologías para realizar análisis programáticos de los requisitos de diseño, incluyendo requisitos contextuales, para luego producir soluciones sintéticas (ej. diseños) que puedan ser ejecutadas como conjuntos de formas y espacios (“estructuras”) que satisfagan esos requisitos. La obra de Christopher Alexander, en particular su libro Notes on the Synthesis of Form 15, viene a mente. Estos precedentes arquitectónicos son una fuente inagotable de recursos para los diseñadores de espacios informáticos.

Conclusión

La revolución informática ha traído con sí algunos cambios fundamentales a la experiencia de las personas que usamos los medios digitales. Muchas de nuestras actividades diarias se han movido a los espacios informáticos, y muchas más lo hacen cada año. El crear estos espacios con fines humanistas, para que la información sea fácil de encontrar, navegar, y entender, es un reto nuevo para los diseñadores. Sin embargo, es un reto que puede ser abarcado por medio de una combinación de técnicas, provenientes de las ciencias de la información y de la arquitectura. La arquitectura de la información es donde convergen estos campos, por lo que es un área de práctica crítica para lograr espacios informáticos mejor adecuados a las necesidades de los seres humanos que los habitan.

Referencias

1. What Happens in an Internet Minute? [Ver en línea la referencia 1]

2. Literacy [Ver en línea la referencia 2]

3. The World Factbook [Ver en línea la referencia 3]

4. Global digital divide [Ver en línea la referencia 4]

5. CBS NEWS [Ver en línea la referencia 5]

6. How an Egyptian Revolution Began on Facebook [Ver en línea la referencia 6] .

7. Hinton, Andrew, “The Machineries of Context: New Architectures for a New Dimension”, Journal of Information Architecture, Volume 1, Issue 1, 2009, p 37.

8. P. Maglio, Paul, Matlock, Teenie, “Metaphors We Surf the Web By”, 1998.

9. Resmini, Andrea y Rosati, Luca, “Pervasive Information Architecture: Designing Cross-Channel User Experiences”, Morgan Kaufman, Capítulo 4.

10. Rosenfeld, Louis, Morville, Peter, Information Architecture for the World Wide Web, O’Reilly, 1998.

11. Wurman, Richard Saul, “Tokio Access”, Access Press, 1984.

12. Wurman, Richard Saul, Information Architects, Graphis Press, 1996.

13. P. Morville, “A brief history of information architecture”, en: Gilchrist; Mahon (eds.), Information architecture: Designing information environments for purpose, Neal-Schuman Publishers, p. xiii, 2004.

14.The Memphis Plenary [Ver en línea la referencia 14]

15. peterme.com [Ver en línea la referencia 15]

Bibliografía

What Happens in an Internet Minute? [Ver en línea]

Hinton, Andrew, “The Machineries of Context: New Architectures for a New Dimension”, Journal of Information Architecture, Volume 1, Issue 1, 2009, p 37.

P. Maglio, Paul, Matlock, Teenie, “Metaphors We Surf the Web By”, 1998.

Resmini, Andrea y Rosati, Luca, “Pervasive Information Architecture: Designing Cross-Channel User Experiences”, Morgan Kaufman, Capítulo 4.

Rosenfeld, Louis, Morville, Peter, “Information Architecture for the World Wide Web”, O’Reilly, 1998.

Wurman, Richard Saul. “Tokio Access”, Access Press, 1984.

Wurman, Richard Saul, “Information Architects”, Graphis Press, 1996.

P. Morville, “A brief history of information architecture”, en: Gilchrist; Mahon (eds.), Information architecture: Designing information environments for purpose, Neal-Schuman Publishers, p. xiii, 2004.

Eames, R. & Eames, R. (1968). Power of 10. Disponible en YouTube. [Ver video en Youtube]

Alexander, Christopher, “Notes on the Synthesis of Form”, Harvard University Press, 1964.

Capítulo 9: Accesibilidad Web y SEO, por Olga Carreras Montoto

Mini biografía del autor

Filóloga y lingüista, con un máster en Dirección Técnica en Sistemas Multimedia y Diseño Asistido por Ordenador de la empresa Autodesk. Cuenta con más de 12 años de experiencia en el desarrollo de proyectos web y fue durante 7 años responsable del Departamento de Diseño, Usabilidad y Accesibilidad de la empresa TB-Solutions. Actualmente trabaja como consultora independiente especializada en accesibilidad, usabilidad y arquitectura de información. En 2012 fue incluida como una de las 40 mujeres más influyentes de internet/nuevas tecnologías en España por el blog “Mujeres Consejeras”. Es autora del blog “Usable y accesible”, referente para la comunidad hispana, algunos de cuyos artículos han sido incluidos en diferentes libros.

Más información:

Ingresar al sitio web del autor

Twitter: @olgacarreras

Accesibilidad Web y SEO

¿Qué es la accesibilidad web?

La accesibilidad web es el arte de garantizar que un sitio o servicio web puede ser visitado y utilizado de forma satisfactoria por el mayor número posible de personas, independientemente de las limitaciones personales que tengan o de aquellas limitaciones que sean derivadas de su entorno.

Muchas veces se identifica accesibilidad web con accesibilidad para personas con discapacidad, pero hablar de accesibilidad web “es hablar de un acceso universal a la web, independientemente del tipo de hardware, software, infraestructura de red, idioma, cultura, localización geográfica y capacidades de los usuarios” [W3C, 1994]

Las limitaciones personales no implican siempre una discapacidad (visual, auditiva, motriz, neurológicas, cognitiva o del lenguaje). Pueden ser derivadas de la edad, de la inexperiencia tecnológica o de una incapacidad transitoria; asimismo pueden depender del idioma y cultura del usuario, de su nivel educativo, o de su localización geográfica.

Las limitaciones tecnológicas o las derivadas de su entorno pueden ser muy dispares: conexión lenta de acceso a Internet, ambiente ruidoso, escasas condiciones de visibilidad, acceso desde diferentes dispositivos o navegadores, etc.

¿Cómo se hace el contenido web accesible?

Las “Pautas de Accesibilidad para el Contenido Web 2.0” (WCAG 2.0) [W3C, 2008] han sido desarrolladas por la Web Accessibility Initiative (WAI), organismo dependiente del W3C, y definen cómo crear contenido web accesible.

Las WCAG 2.0 están estructuradas en torno a los cuatro principios que conforman los fundamentos de la accesibilidad web: perceptible, operable, comprensible y robusto.

Cada uno de estos principios tiene asociado un determinado número de pautas, 12 en total, que proporcionan el marco y los objetivos generales a cumplir.

Cada una de estas pautas cuenta con una serie de criterios de conformidad, 61 en total, que son los requisitos verificables y tienen asociados un nivel de conformidad: A (el más bajo), AA, AAA.

Por cada criterio de conformidad se documentan una serie de técnicas suficientes, otras recomendables y los errores conocidos más frecuentes.

¿Qué es SEO?

SEO (Search Engine Optimization) o Posicionamiento Orgánico en Buscadores es el conjunto de técnicas para mejorar la visibilidad de un sitio web en los diferentes motores de búsqueda como Google, Yahoo! o Bing.

El objetivo principal es aparecer en las primeras posiciones de la página de resultados (denominada SERP) para determinados términos de búsqueda, lo cual aumentará las probabilidades de que sea visitada por el usuario que está realizado esa búsqueda concreta.

¿Cómo se mejora el posicionamiento en buscadores?

El robot de búsqueda de Google (Googlebot) rastrea contenido en Internet de forma continua y automática para el índice de Google, siguiendo los enlaces de las páginas e indexando de esta manera miles de millones de páginas.

El algoritmo que aplica Google para determinar la relevancia de nuestra página para unos términos de búsqueda concretos, y en base al cual posicionar nuestra página en los resultados de búsqueda, es modificado con frecuencia y no se conoce con exactitud, pero son más de 200 factores los que se tienen en cuenta [Cutts, 2010].

Las técnicas SEO para mejorar el posicionamiento de las páginas se centran en:

Facilitar el rastreo y la indexación de las páginas por parte de los robots de los motores de búsqueda, y que esta se realice por los términos de búsqueda relevantes para esa página.

Conseguir que Google considere nuestra página relevante. Aunque el algoritmo de Google no se conoce, sí se sabe de ciertos factores que influyen, como por ejemplo: el número, autoridad o temática de las páginas que enlazan con la nuestra, la velocidad de carga del sitio 1 o que otorga prioridad a las páginas con contenido propio, actualizado y de interés para los visitantes.

Hablamos de black hat SEO para referirnos a las malas prácticas SEO, a las técnicas para conseguir un posicionamiento poco lícito de las páginas y que están penalizadas por Google.

Nosotros haremos referencia a las buenas prácticas (white hat SEO) que llevan a cabo los verdaderos profesionales SEO y que en muchos casos son similares a las técnicas de accesibilidad web.

Un enfoque conciliador

Difícilmente puedes usar lo que no puedes encontrar. Esta es la primera reflexión que debemos hacernos para tender puentes entre ambas disciplinas. Las dos son importantes en un proyecto web, pues no tiene mucho sentido hacer un sitio accesible si nadie puede encontrarlo. Y a la inversa, no tiene mucho sentido que nuestro sitio aparezca en el primer lugar de los resultados de búsqueda si luego el usuario encuentra barreras insalvables para acceder a su contenido.

El usuario ciego más rico del mundo

Uno de los visitantes más fieles de nuestro sitio web es un usuario con discapacidad. Es ciego, -no ve las imágenes (al menos de momento), ni los videos, ni admira la belleza de nuestras animaciones-, es sordo, navega sin plugins instalados, sin applets y sin javascript activo, por lo tanto le es imposible seguir los enlaces que dependen de javascript.

Jakob Nielsen le llama el “usuario ciego más rico del mundo” [Nielsen, 2012]. Este usuario es Googlebot, el robot de búsqueda de Google.

Los problemas que suele tener para acceder, interpretar e indexar el contenido no difieren mucho de los que tratamos en la accesibilidad web. Esta es la razón por la cual muchas de las técnicas que aplicamos para hacer nuestra web más accesible repercuten directa y positivamente en su indexación y posicionamiento.

Foco en el usuario

La accesibilidad web pone su foco en los usuarios, y por el contrario, el SEO parece poner su foco en máquinas. Sin embargo, los motores de búsqueda quieren encontrar lo mismo que nuestros visitantes: información actualizada, pertinente y de calidad. Por ello las últimas modificaciones en el algoritmo de Google van encaminadas a reconocer la calidad de cada sitio y a basarse en criterios de usabilidad y accesibilidad.

El buen SEO se centra también en los usuarios, en el interés que generan los contenidos o en que estos respondan a las expectativas que tenían los usuarios al realizar la búsqueda y seleccionar nuestro sitio.

Accesibilidad web y SEO: técnicas comunes

En este apartado vamos a repasar las requisitos de accesibilidad web (haciendo referencia a las WCAG 2.0 [W3C, 2008]) que coinciden con buenas prácticas SEO ([Google, 2011], [Google, 2012]) y que por tanto repercuten directamente en la indexación y posicionamiento de nuestra páginas 2.

Alternativas textuales para elementos no textuales

Uno de los requisitos de accesibilidad más conocidos es que las imágenes deben tener un texto alternativo que proporcione la misma información que pretende transmitir la imagen.

Para el contenido tempodependiente, como videos o audios, se aplican requisitos adicionales, por ejemplo proporcionar subtítulos, transcripciones textuales o audiodescripciones al contenido.

Desde el punto de vista de la accesibilidad web

Las alternativas textuales permiten a las personas que no pueden percibir el contenido visual, por una discapacidad visual o por su contexto de uso, leer en pantalla, en braille o mediante un lector de pantalla la información que transmiten.

Las personas sordas podrán leer la información textual alternativa al contenido sonoro, o esta podrá ser traducida automáticamente a la lengua de signos.

Desde el punto de vista de SEO

Teniendo en cuenta que los buscadores solo entienden texto, podrán interpretar y clasificar los contenidos no textuales (imágenes, videos, audios, object, applet, etc.) gracias a sus alternativas textuales.

Esta información podrá ser indexada y recuperada por los motores de búsqueda, por ejemplo para mejorar la información que se ofrece para la búsqueda por imágenes o por videos de Google.

Si además estas imágenes son relevantes en relación con el contenido de la página, las alternativas textuales que incluyas tendrán palabras claves que ayudarán también al posicionamiento.

Título e idioma de las páginas

El criterio de conformidad 2.4.2 (nivel A) indica que las páginas deben tener un título que describa su temática o propósito.

Se especifica que el título debe identificar claramente el contenido de la página web, tener sentido fuera de su contexto y ser corto. Se recomienda además que identifique el sitio y que sea único para cada página del mismo.

El criterio de conformidad 3.1.1 (nivel A) señala que se debe indicar el idioma de la página y en el criterio de conformidad 3.1.2 (nivel AA) que también han de marcarse los cambios de idioma en el contenido.

Desde el punto de vista de la accesibilidad web

El título de las páginas beneficia a todos los usuarios, que así pueden identificarlas con rapidez y facilidad: en las pestañas del navegador, al incluirla en Favoritos, al compartirla en redes sociales, etc.

Favorece especialmente a las personas que usan un lector de pantalla, pues de este modo pueden diferenciar varias páginas abiertas.

Indicar el idioma del sitio y los cambios de idioma del contenido permite que los agentes de usuario puedan presentar el texto de forma correcta. Por ejemplo, los lectores de pantalla podrán usar el acento y la pronunciación adecuados al idioma definido.

Desde el punto de vista SEO

El título de la página indica a los motores de búsqueda sobre qué trata la página y es un factor muy importante a la hora de indexarla.

Además, la primera línea que se muestra en cada resultado de la SERP suele ser el TITLE de la página, y este será un elemento decisivo para que los usuarios decidan si la página es de su interés.

[Google, 2011] da recomendaciones muy similares a las que veíamos en las WCAG 2.0: incluir el nombre de la web o negocio; usar títulos descriptivos breves; indicar claramente el tema de la página sin ser demasiado genéricos; o usar títulos únicos para cada página.

Por otra parte, especificar el idioma de un documento o una parte del mismo proporciona metainformación relevante a los motores de búsqueda para su indexación.

Enlaces

El criterio de conformidad 2.4.4 (nivel A) y 2.4.9 (AAA) tratan sobre cómo clarificar el propósito de los enlaces, especialmente a través del texto de los mismos. Por ejemplo, un enlace cuyo propósito no está claro sería un enlace con el texto “Pulse aquí”.

Los enlaces con el mismo destino deben tener la misma descripción. Por el contrario, no debería haber enlaces con la misma descripción y destinos diferentes.

La “mejora progresiva” (progressive enhancement) aplicada a la programación javascript implica implementar las páginas como si no fueran a soportar javascript y sobre ellas añadir una capa de programación javascript no intrusivo como mejora. Esto permite que no haya enlaces que dependan de javascript.

Desde el punto de vista de la accesibilidad web

Beneficia a todos los usuarios, que así pueden comprenden el propósito del enlace y decidir si seguirlo o no. Beneficia especialmente a las personas con discapacidad cognitiva y a las personas que utilizan un lector de pantalla, que pueden explorar los enlaces y saltar aquellos en los que no están interesados.

Desde el punto de vista de SEO

Es imprescindible que el robot de los motores de búsqueda pueda rastrear nuestros enlaces. El uso de la “mejora progresiva” y de javascript no intrusivo, además de hacer páginas más ligeras y con un código más claro y sencillo, permite evitar enlaces que dependen de javascript y que los robots no podrán seguir.

Además, los textos de los enlaces son un factor muy relevante para los algoritmos de búsqueda, puesto que etiquetan el contenido de destino de la página. Cuanto más significativo y claro sea el texto del enlace o su información adicional, más fácil le será a Google entender la temática de la página a la que enlaza e indexar y posicionarla por las palabras claves que la definen.

Encabezados y marcado semántico

En el criterio de conformidad 1.3.1 (nivel A) se aborda la necesidad de separar el contenido de la presentación y usar un marcado estructural y semántico adecuado para cada contenido: <h1>-<h6> para los encabezados; <p> para los párrafos; <ol>, <ul>, <dl> para las listas; <em> y <strong> para enfatizar el texto; etc.

No se deben utilizar determinados elementos para conseguir un efecto visual. Por ejemplo, no se debe usar H1 para aumentar el tamaño de letra de un texto sino para marcarlo como un encabezado de primer nivel.

Asimismo, tampoco se deben simular elementos mediante estilos. Por ejemplo, no se debe utilizar un elemento P con estilo de texto grande y en negrita para simular un encabezado, sino que se debe utilizar un elemento H1.

El criterio de conformidad 2.4.1 (nivel A) hace referencia a la importancia de la estructuración del contenido mediante encabezados y a la agrupación de los enlaces en listas. Los encabezados se deben usar de forma coherente según su importancia y jerarquía, sin saltarse niveles y encabezando siempre contenido.

En el criterio de conformidad 2.4.6 (nivel AA) se indica que los encabezados deben ser claros, breves e identificar la sección de contenido que encabezan.

Desde el punto de vista de la accesibilidad web

El correcto marcado semántico de las páginas, la estructuración del contenido mediante encabezados y la agrupación de los enlaces en listas, permiten reconocer la estructura y la semántica del contenido independientemente del contexto de uso.

Por ejemplo, los usuarios de lectores de pantalla podrán buscar diferentes tipos de contenidos, obtener un listado de enlaces o encabezados, u “ojear” el documento saltando de un encabezado a otro, sin necesidad de una lectura lineal completa.

Si los títulos son claros y descriptivos, los usuarios pueden encontrar más fácilmente la información y comprender las relaciones entre las diferentes partes del contenido.

Desde el punto de vista de SEO

El marcado semántico y el uso correcto de los encabezados de la página hacen más evidente la estructura del contenido y la relevancia de cada uno de sus elementos, lo cual ayuda a interpretar la página e indexarla correctamente.

También hay que tener en cuenta que Google no solo tiene en cuenta la frecuencia de las palabras sino también su relevancia, y esta es mayor en función de dónde se encuentran: si están en un encabezado, el nivel de encabezado que las contiene, si están marcadas como relevantes (con “strong” o “em”), etc.

Estándares y separación entre contenido y presentación

El criterio de conformidad 4.1.1 hace referencia al uso del lenguaje de marcado utilizado de acuerdo a su especificación, y una técnica para lograrlo es la validación del código mediante el validador automático del W3C <http://validator.w3.org/>

Otros criterios de conformidad ya vistos (como 1.3.1 explicado en el apartado anterior) hacen referencia a la separación entre el contenido y la presentación. En el criterio de conformidad 1.1.1 (nivel A) se indica además que las imágenes decorativas se deberían incluir preferentemente en las CSS para separar el contenido de la presentación; y por el mismo motivo, las WCAG 2.0 desaconsejan las tablas para maquetar.

En el criterio de conformidad 1.4.5 (nivel AA) se indica que debe utilizarse texto en vez de imágenes de texto.

Desde el punto de vista de la accesibilidad web

Un código válido y de acuerdo a la especificación asegura que los agentes de usuario y productos de apoyo podrán interpretar correctamente la página y su contenido.

Separar el contenido de la presentación permite modificar la presentación basándose en la estructura, por ejemplo permite al usuario utilizar una CSS alternativa: de alto contraste, con el texto más grande, etc.

Usar texto en vez de imágenes de texto asegura que los usuarios puedan modificar el texto para adecuarlo a sus necesidades.

Desde el punto de vista de la accesibilidad web

La separación entre el contenido y la presentación genera páginas más ligeras y disminuye el tiempo de carga, que es un factor relevante para el posicionamiento. Además las páginas tienen un código más claro y sencillo, con una buena relación entre contenido y código, que sumado a un marcado válido y de acuerdo a la especificación, las hace más fáciles de interpretar e indexar.

Mapa web y navegabilidad

El criterio de conformidad 2.4.5 (nivel AA) indica que se debe proporcionar más de un camino para localizar una página web en el conjunto del sitio. Se pueden usar diferentes técnicas: enlaces a páginas relacionadas, una tabla de contenidos o un mapa web.

Por su parte, el criterio 2.4.8 (nivel AAA) trata sobre proporcionar información al usuario acerca de su ubicación en el conjunto del sitio. Las técnicas aplicables pueden ser, por ejemplo, el uso de migas de pan, un mapa web o incluir una barra de navegación semántica mediante el elemento LINK.

En las WCAG 2.0 también se hace referencia a que las redirecciones deberían ser transparentes para el usuario (criterio 2.2.1 y técnica SVR1) usando por ejemplo redirecciones de servidor 301 para las páginas movidas permanentemente.

Desde el punto de vista de la accesibilidad web

Los requisitos para mejorar la navegabilidad nos benefician a todos, pero especialmente a las personas con discapacidad visual, con problemas cognitivos o con déficit de atención.

Desde el punto de vista de SEO

El robot del motor de búsqueda debe ser capaz de llegar a todas las páginas de nuestra web. Incluir un mapa del sitio, migas de pan o enlaces relacionados ayuda a evidenciar su estructura y nos asegura que se pueda acceder a todas sus páginas.

La inclusión de metainformación en una barra de navegación semántica ofrece al buscador información sobre su relación con otras páginas o el tipo de contenido que incluyen. [Google, 2011] también recomienda el uso de migas de pan y de un mapa web. Además, las redirecciones 301 para las páginas movidas permanentemente nos permitirán mantener los enlaces entrantes backlinks y el PageRank.

Legibilidad

El criterio de conformidad 3.1.5 (nivel AAA) trata sobre adecuar el nivel de lectura del texto y su legibilidad para todos los usuarios.

El criterio de conformidad 3.1.3 (nivel AAA) indica que se debe clarificar el significado de las palabras inusuales o de jerga mediante por ejemplo una definición en línea o con un glosario de definiciones.

El criterio 3.1.4 (nivel AAA) señala que también se debe explicar el significado de acrónimos o abreviaturas, por ejemplo en el propio texto, mediante el atributo TITLE de los elementos <abbr> y <acronym> o con un glosario.

Desde el punto de vista de la accesibilidad web

Beneficia a todos los usuarios, especialmente a las personas con una discapacidad cognitiva o del lenguaje, con problemas de aprendizaje o memoria, a las personas de una cultura diferente o con un nivel educativo menor al requerido por la página.

Desde el punto de vista de SEO

Es más sencillo inferir la temática de un contenido textual claro, conciso y correcto, y sin duda es más fácil de rastrear e indexar correctamente.

Si la página contiene el lenguaje más apropiado, claro y simple para el contenido del sitio será probable que estemos más cerca de los posibles términos de búsqueda de nuestros visitantes. Las alternativas a siglas, palabras de jerga, tecnicismos, etc. permiten abarcar también más variedad de posibles búsquedas.

El uso de un resumen al comienzo del contenido, -que presumiblemente tendrá las palabras clave para la página-, responde al modelo de pirámide invertida: lo más importante arriba, y cuanto más arriba más relevancia le da Google.

Para ello debe estar realmente situado “arriba” en el código, para que sea, dentro del contenido, lo primero que lean los lectores de pantalla pero también los buscadores; las técnicas de las WCAG 2.0 relativas al correcto orden lectura nos apoyarán en este sentido.

Otras consideraciones

Google indexa también archivos PDF [Google, 2011b] y SWF Flash [Google, 2012b]. Las WCAG 2.0 se aplican también a este tipo de archivos (de hecho incluyen técnicas específicas para ellos), que si son inaccesibles de forma nativa serán no sólo inaccesibles para muchos usuarios sino también para Google.

Por otro lado, tanto las WCAG 2.0 (técnica H70, técnica H64) como Google [Google, 2012b], [Google, 2012c] desaconsejan el uso de frames e iframes, y en el caso de usarlos ofrecen las mismas recomendaciones.

Conclusiones

“Vender” accesibilidad web es a menudo complicado. Esta dificultad es debida en gran medida al desconocimiento de qué es realmente la accesibilidad web y de todos beneficios que reporta, así como a la simplificación de que la accesibilidad web es accesibilidad solo para personas con discapacidad.

Por el contrario, “vender” SEO suele ser más sencillo, quizás porque los resultados son más fáciles de medir y los beneficios económicos más evidentes.

Conocer y ser conscientes de que:

muchas de las acciones que llevamos a cabo para hacer nuestras páginas web más accesible repercuten directa y positivamente en su posicionamiento en los buscadores;

ambas disciplinas tienen muchos puntos de encuentro y utilizan técnicas similares; quizás ayude a que efectivamente la accesibilidad web y el SEO caminen de la mano, no se miren con desconfianza y llegue el día en que se ofrezcan habitualmente de forma conjunta e integrada.

Y quizás también, de esta manera, muchas más empresas y organismos decidan hacer sus sitios web accesibles.

Referencias

1. En abril de 2010 Google confirmó la velocidad de carga de las páginas como un factor relevante de posicionamiento [Google, 2010]

2. Hay otros requisitos de accesibilidad que no tienen relación directa con el posicionamiento en buscadores, y a la inversa, acciones SEO que no tienen una correspondencia directa con requisitos de accesibilidad.

Bibliografía

Carreras, Olga, “Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.0”, en: blog Usable y accesible: [Ver Blog en línea] , 28 de agosto de 2012 [Consulta: 27 de noviembre de 2012]

Cutts, Matt. “How Search Works” [Archivo de vídeo], en: canal de YouTube de Google [Ver video en Youtube] , 4 de abril de 2010 [Consulta: 27 de noviembre de 2012]

“Using site speed in web search ranking”, en: Google Webmaster Central Blog: [Ver en línea sitio de Google] 9 de abril de 2010 [Consulta: 25 de noviembre de 2012]

Guía para principiantes sobre optimización para motores de búsqueda: [Ver en línea guía para principiantes] , 2011 [Consulta: el 23 de noviembre de 2012]

“Archivos PDF en los resultados de búsqueda de Google”, en: El Blog para Webmasters: [Ver en línea blog para Webmasters] , 24 de septiembre de 2011 [Consulta: el 23 de noviembre de 2012]

“Directrices para webmasters Prácticas recomendadas para ayudar a Google a encontrar, rastrear e indexar tu sitio”, en: Herramientas para webmasters de Google: [Ver en línea las directrices] , 16 de octubre de 2012 [Consulta: el 27 de noviembre de 2012]

Google. “Flash y otros archivos multimedia”, en: Herramientas para webmasters de Google.: [Ver en línea recomendaciones para Flash] , 16 de octubre de 2012 [Consulta: el 27 de noviembre de 2012]

Google. “Marcos”, en: Herramientas para webmasters de Google.: [Ver en línea macros] , 16 de octubre de 2012 [Consulta: el 27 de noviembre de 2012]

Morville, Peter. “User Experience Design”, en: Semantic Studios: [Ver en línea UXD] , 21 de Junio de 2004. [Consulta: 24 de noviembre de 2012]

Nielsen, Jakob. SEO and Usability: [Ver en línea SEO y Usabilidad] , 12 de Agosto de 2012. [Consulta: el 23 de noviembre de 2012]

World Wide Web Consortium (W3C) Oficina Española. “Accesibilidad web”, en: El W3C de la A a la Z: [Ver en línea Accesibilidad Web] , 1994. [Consulta: 27 de noviembre de 2012]

W3C. Web Accessibility Initiative (WAI). Web Content Accessibility Guidelines 2.0.

W3C Recommendation, 11 de diciembre de 2008.: [Ver en línea las recomendaciones en Inglés].Traducida al español en: SIDAR. [Ver en línea las recomendaciones en Español] , 15 de diciembre de 2009. [Consulta: 27 de noviembre de 2012]

W3C. Web Accessibility Initiative (WAI). Techniques for WCAG 2.0: [Ver en línea las técnicas WAI] , 3 de junio de 2012. [Consulta: 27 de noviembre de 2012]

W3C. Web Accessibility Initiative (WAI). Understanding WCAG 2.0: [Ver en línea las WAI] , 3 de junio de 2012. [Consulta: 27 de noviembre de 2012]

Capítulo 10: Desarrollo de un videojuego accesible, análisis del proceso de trabajo: El Caso Slalom, por Javier Mairena

Mini biografía del autor

Técnico Superior en Desarrollo de Aplicaciones Informáticas y ha complementado su formación de forma autodidacta como desarrollador de videojuegos especializado en accesibilidad. Actualmente trabaja en AccessAble Games como responsable y experto en accesibilidad en videojuegos desarrollando productos propios y ayudando a otros desarrolladores a crear juegos más accesibles.

Más información:

Ingresar al sitio web del autor

Twitter: @javimairena

Mini biografía de Daniel Márquez

Ingeniero en Informática, posee un máster en Lógica, Computación e Inteligencia Artificial por la Universidad de Sevilla. Ha completado su formación con el desarrollo de videojuegos. Actualmente trabaja en The Game Kitchen como Lead Programmer donde también trata investigar avances en todo lo referido a la inteligencia artificial en videojuegos.

Más información:

Ingresar al sitio web de Daniel Márquez

Correo electrónico: Enviar mail al autor.

Desarrollo de un videojuego accesible, análisis del proceso de trabajo: El Caso Slalom

Accesibilidad siempre presente

Lo más importante a la hora de desarrollar un videojuego accesible es tener siempre la accesibilidad presente, desde el inicio del diseño del juego hasta su publicación. En los primeros diseños de concepto de lo que será el juego (objetivos, mecánicas, elementos, control...) resulta sencillo incluir modificaciones que hagan que el juego vaya a ser más accesible, comparado con incluir esas modificaciones una vez el juego ya está en desarrollo o terminado. Durante el desarrollo es importante que todos los perfiles que forman parte en la realización del videojuego (diseñador de juego, diseñador gráfico, programador, diseñador de niveles, técnico de sonido...) tengan siempre en mente la accesibilidad, ya que cada uno de ellos puede realizar pequeñas modificaciones en su trabajo que hagan que el juego sea más accesible. Por ejemplo, un diseñador gráfico puede crear distintas formas para cada identificar elementos distintos dentro del juego, en vez de intentar diferenciarlos sólo asignándoles colores diferentes (lo que supondría un problema para personas con daltonismo). O puede crear los gráficos teniendo en cuenta que es posible que se pueda añadir una opción en el juego de alto contraste. Un programador que tenga siempre en mente la accesibilidad puede crear también código en el que sea más fácil implementar ciertas características de accesibilidad. También puede avisar al resto del equipo de opciones de accesibilidad que considere poco costosas de implementar, a nivel de programación, debido al tipo de juego que se esté haciendo y la tecnología con la que se esté trabajando. Estos son solo algunos ejemplos para mostrar que es importante que todos los perfiles tengan conocimientos básicos de accesibilidad en videojuegos para que el juego acabe siendo lo más accesible posible, dentro de las posibilidades y recursos del proyecto.

Conceptos básicos:

Es ilusorio pensar que el hecho de hacer un buen diseño de juego antes de comenzar el desarrollo del juego nos asegure que el videojuego vaya a ser más accesible, porque durante el desarrollo siempre se acaban produciendo cambios en el diseño del juego por motivos muy variados: tras comprobar que ciertas cosas resultan distintas una vez están el juego, o por falta de recursos o tiempo, o al descubrir la necesidad de ciertos cambios tras las fases de pruebas de calidad con jugadores. Incluso a la hora de la publicación del juego es importante informar sobre el nivel de accesibilidad del juego para que los posibles jugadores tengan claro si van a poder disfrutar del juego o no antes de comprarlo.

Todavía no existe ningún estándar sobre la forma de identificar la accesibilidad de un videojuego, pero sí una iniciativa por parte de Special Effect de utilizar un ícono que indique que el juego ha sido diseñado para ser más accesible en alguno de sus aspectos.

Este ícono debería aparecer en alguna parte visible de la portada del juego, parte trasera o cualquier otro tipo de situación a la que pueda tener acceso el jugador antes de su compra.

Debería también ir acompañado de una información algo más detallada de su accesibilidad o de un enlace a esa información. Una información más detallada podría ser: detalle de las capacidades necesarias del jugador para poder disfrutarlo, cuando el juego está configurado en su modo más accesible; o detalle de los pasos a seguir y/o características incluidas para eliminar las barreras cognitivas, auditivas, visuales y de control.

Más información sobre la iniciativa de esta identificación: [Ver en línea la iniciativa]

También, a la hora de su distribución por tiendas digitales de videojuegos, sería importante indicar a la tienda estas características, ya que algunas de ellas ya cuentan con una clasificación de estas que son visibles para los compradores.

En Steam [Ver en línea Steaam] por ejemplo, una de las características que destacan de los juegos es que tengan Closed Captions (subtitulado completo de sonidos).

IndieCity [Ver en línea IndieCity] es la tienda digital que actualmente tiene la mayor clasificación de características de accesibilidad en sus juegos. Dispone de indicadores de accesibilidad para:

Daltónicos

Auditivo

Controles personalizables

Soluciones de accesibilidad

Aunque todavía no existe un estándar en accesibilidad en videojuegos, sí existen algunas recomendaciones publicadas por distintas entidades que pueden servir como guías para crear videojuegos más accesibles. En castellano podemos encontrar un documento muy extenso, una recopilación llevada a cabo por el CEAPAT [Ver en línea CEAPAT] de artículos de varios autores que recoge experiencias reales y recomendaciones:

“Buenas prácticas de accesibilidad en videojuegos”, CEAPAT. 2012. Descargar PDF CEAPAT 2012. Y un pequeño documento que resume algunos de los conceptos más básicos: “Videojuegos accesibles, por qué y cómo hacerlos”, Mairena García de la Torre, Javier. 2009.Descargar PDF de Videojuegos accesibles

En inglés destacan dos guías creadas recientemente. Una de ellas sólo se puede consultar por web: “Game Accessiblity Guidelines”, varios autores. 2012. [Ver en línea la guía, en inglés]

Y otra dispone en formato documento: “Includification, a practical guide to game accessibility”, varios autores. 2012. Descargar PDF

Mayores dificultades de documentación y experiencias previas

La mayor dificultad a la hora de desarrollar un videojuego accesible seguramente puede ser la falta de experiencias previas en accesibilidad dentro de la industria del videojuego. Desgraciadamente, los desarrolladores de videojuegos no han llegado a considerar la accesibilidad como algo importante todavía y hoy en día sólo son algunos los que están empezando a considerarla como algo necesario. Debido a esto existe una importante carencia en cuanto a documentación, estandarización y experiencias previas sobre las que aprender y basarse para desarrollar un videojuego más accesible. Las guías y recomendaciones públicas que existen pueden resultar vagas a la hora de la implementación de esas características en un videojuego. Cada característica de accesibilidad se podría implementar de muchas formas, pero por la experiencia todavía no se conoce bien cuál es la mejor para cada una de ellas.

Tecnología para videojuegos no preparada para la accesibilidad

Otro gran impedimento es que la tecnología utilizada para crear los videojuegos no está pensada para crear videojuegos más accesibles, con lo que en la mayoría de los casos cualquier nueva característica básica de accesibilidad tiene que ser creada desde cero.

En otras industrias de nuevas tecnologías ha habido grandes cambios en los estándares tecnológicos y de diseño en pro de la accesibilidad, y las herramientas para la creación de contenidos se han actualizado para que añadir más accesibilidad al producto sea una tarea menos costosa. Falta todavía un poco más de tiempo para que los videojuegos creen una base de diseño y tecnológica que facilite la creación de juegos más accesibles.

Caso práctico: Slalom, el Videojuego

Concepto

Slalom, el Videojuego, es un simulador del deporte “Slalom en Silla de Ruedas”, practicado por personas con parálisis cerebral. El objetivo de la creación de este simulador es que las personas que practican o quieren empezar a practicar este deporte puedan conocer mejor sus reglas, tipos de pruebas y recorridos, e incluso mejorar sus tiempos practicando estrategias distintas de movimientos.

El juego no pretende ser un sustituto de la práctica real, pero sí una gran ayuda para mejorar y conocer más este deporte sin las necesidades de espacio, tiempo y personal que requiere la práctica real de este deporte.

Slalom, el Videojuego, es un proyecto del Ministerio de Sanidad, Servicios Sociales e Igualdad de España (http://www.mspsi.gob.es) y del Centro de Referencia Estatal Discapacidad y Dependencia de León (http://www.crediscapacidadydependencia.es/); desarrollado por The Game Kitchen (http://www.thegamekitchen.com/) junto a AccessAble Games (http://www.accessablegames.com/).

Se puede descargar de forma gratuita para PC Windows aquí: Descargar aquí

Accesibilidad prioritaria: movilidad

Ya que es un juego sobre un deporte practicado por personas con parálisis cerebral y que el principal usuario objetivo son personas también con parálisis cerebral, la accesibilidad en este proyecto se ha centrado principalmente en la movilidad.

Se han tenido también en cuenta otros aspectos a nivel cognitivo, visual y auditivo que, por las características concretas de este juego, resultaban poco costosas de implementar. El proyecto fue desarrollado utilizando la metodología SCRUM, con lo que para cada uno de los seis sprints de los que se compuso el proyecto se priorizaron las distintas características de accesibilidad se iban a implementar en el juego.

Accesibilidad implementada en el juego:

Estas son las características de accesibilidad que se implementaron en el juego.

Movilidad

Configuración de la velocidad general del juego. Se puede modificar la velocidad del juego, ralentizando o acelerando todo lo que sucede en el juego. Exceptuando algunas cosas que no son momentos realmente de juego, como las secuencias introductorias a las pruebas.

Modo de control con joystick o teclado. El juego está principalmente diseñado para ser controlado con un joystick tradicional por su semejanza con los joystick de las sillas motorizadas, a los que muchos de los usuarios objetivo puede que ya estén acostumbrados a manejar. Además resulta un dispositivo sencillo de controlar por su tamaño y forma para personas con parálisis cerebral, comparado con otros dispositivos de control. Pero también puede ser controlado con gamepad o teclado, lo que lo hace compatible también con pulsadores grandes externos si se configuran como las teclas cursores.

Modo de control con ratón (para trackballs y ratones faciales también). En este modo se puede controlar el juego tan sólo moviendo el cursor del ratón, sin necesidad de pulsar ningún botón. El cursor del ratón funciona como un joystick virtual en pantalla: si está situado en el centro de la pantalla no hará nada, si lo movemos a la parte superior de la pantalla es como si empujáramos el joystick hacia delante, si lo situamos en la parte inferior es como si moviéramos el joystick hacia nosotros, y del mismo modo si movemos el cursor hacia los lados es como si moviéramos el joystick hacia los lados.

Este modo se introdujo pensando sobre todo en las personas que ya controlan el PC con un ratón facial, para las que es importante que no sea necesario tener que pulsar una tecla o botón por comodidad de uso. Además también resultaba más accesible para los que utilizaran ratón o trackballs, de los que hay versiones especiales muy grandes pensados para la accesibilidad.

Modo de control con un botón (para pulsadores). Pensado para personas que utilizan grandes pulsadores conectados al ordenador. En este modo al pulsar alguna de las teclas o el pulsador, el juego se detiene por completo y en pantalla aparece en pantalla un círculo con una flecha. La flecha gira automáticamente sobre el círculo y al pulsar de nuevo la tecla o el pulsador el juego volverá de la pausa y se comportará como si estuviéramos empujando un joystick en la dirección en la que estaba la flecha cuando volvimos a pulsar la tecla. En las opciones del juego se puede configurar a la velocidad a la que queramos que se mueva la fecha en este modo, por si necesitamos ponerlo a una velocidad muy lenta o nos vale con una algo más rápida.

Configuración de la sensibilidad de los controles. Se puede modificar la sensibilidad de los controles para que personas que, por ejemplo, no puedan realizar pequeños movimientos con el joystick y lo hagan siempre al máximo del rango del joystick, no produzcan en el juego siempre un movimiento a máxima velocidad si no más pequeño.

Del mismo modo para los que sólo pueden mover el joystick en un rango muy pequeño, se puede configurar para que ese leve movimiento se traduzca en el juego en el movimiento máximo que se podría hacer con el joystick.

Cognitiva

Tutoriales. El juego dispone de un tutorial para cada tipo de prueba y obstáculo donde se explica paso a paso las reglas del juego. Se puede reproducir a la velocidad que se desee, incluso retroceder hacia atrás para repetir ciertas partes y también pausarlo totalmente.

Líneas de ayuda para guiar entre obstáculo y obstáculo. Se puede activar unas flechas indicatorias que muestran el camino hacia el siguiente obstáculo, algo muy importante cuando todavía estás aprendiendo las reglas del juego y no recuerdas cual es el orden de ellos. Esta opción resulta de gran ayuda sobre todo en el modo de recorrido variable, donde ciertos obstáculos cambian de posición.

Dos idiomas: Castellano e Inglés. El juego se encuentra en dos idiomas: Castellano e Inglés. Automáticamente al iniciarlo comprueba el idioma del sistema operativo, si es Castellano el juego se iniciará en Castellano, en cualquier otro caso lo hará en Inglés. El idioma se puede cambiar también manualmente en las opciones.

Auditiva

Configuración del volumen de la música y sonidos por separado. Útil para personas con problemas de audición, se puede configurar los volúmenes de música y sonidos por separado. La música en el juego no se utiliza como ningún tipo de indicador, pero los sonidos sí pueden ayudar a saber cuando has tirado un pivote al suelo, por ejemplo.

Subtitulado de sonidos (closed captions). El juego dispone de subtitulado completo de sonidos, con el que la mayoría de los sonidos son indicados visualmente mediante una breve descripción cada vez que suenan.

Visual

Ajuste de brillo y contraste con gran libertad. Se puede configurar el brillo y contraste del juego, pero con una libertad mucho mayor la habitual en la mayoría de los videojuegos, pudiendo llegar a esquemas de colores parecidos al negativo.

Mayores complicaciones en la implementación de la accesibilidad:

Configuración de la velocidad general del juego

Para que el jugador pudiera configurar la velocidad general del juego, al principio se pensó que bastaba con dejar que el usuario modificara directamente un parámetro de velocidad del juego que influye en todo los elementos móviles y que dependen del tiempo; algo que suelen tener todos los videojuegos para poder implementar la pausa o una cámara lenta para ciertos momentos, por ejemplo.

Pero se vio que realmente hacía falta otra velocidad más, una “velocidad de accesibilidad” que influyera como multiplicador sólo en ciertas cosas en las que realmente se querían que cambiasen al modificar esta velocidad.

La necesidad de este parámetro por separado saltó a la vista con situaciones como cuando el jugador ponía la velocidad del juego muy lenta y las secuencias introductorias a las pruebas (una cámara que vuela recorriendo el escenario antes de empezar) se reproducían también de una forma extremadamente lenta. Al no ser realmente un momento de juego no se vio la necesidad de que cada vez que empezaras a jugar una prueba nueva tuvieras que esperar tanto en una secuencia introductoria.

Fue una necesidad que se descubrió algo tarde durante el desarrollo, pero que fue fácil de solucionar.

Multijugador

El juego, como el deporte real, dispone de una prueba tipo eliminatoria en la que pueden jugar dos personas a la vez. El ganador es el primero en llegar a la meta después de haber superado ciertos obstáculos.

El primer problema surge al pensar que pasa cuando juegan dos personas utilizando perfiles distintos en los que la configuración de la velocidad del juego no es la misma. En este caso se decidió que la mejor opción era aplicar a los dos jugadores la velocidad más lenta que tuviera uno de ellos. En la mayoría de los casos obligar a uno de ellos a jugar a una velocidad más lenta de la que tenía configurada no supondrá un problema, en cambio obligar a que juegue a una más rápida sí sería un problema.

El segundo problema surgió en el caso en el que uno de ellos quisiera usar el modo de control con un botón, en el que jugando de forma individual el juego se detiene por completo al pulsarlo. En este caso lo que se hizo es modificar el comportamiento del control de un botón para que en vez de detener el juego por completo detuviera sólo el movimiento de la silla de este jugador, así al pulsar el botón no detiene también el movimiento del otro jugador.

Accesibilidad en los menús

En la lista de características que se querían tener en el juego se añadió la opción de poder navegar en los menús utilizando sólo un botón o con el joystick, además de la navegación por defecto que ya existía con el ratón.

El problema fue que no se le dio la suficiente importancia a este tema y se añadió demasiado tarde a la lista de características del juego y con poca prioridad, pensando que su implementación no iba a ser demasiado costosa o por no darle realmente la importancia que se merecía.

El resultado fue que al final del proyecto se vio que no daba tiempo porque era más costoso de implementar de lo que parecía por culpa principalmente de la tecnología. El juego se desarrolló con Unity 3D, donde el sistema de interfaces y menús era muy deficiente y costoso de implementar. En las nuevas versiones de Unity 3D se ha mejorado mucho eso, pero por aquel entonces el desarrollo de los menús tan sólo con navegación con ratón se llevó mucho más tiempo del esperado y añadir opción de navegación con un botón y joystick ya se salía del tiempo de desarrollo establecido.

El resultado es que una persona que sólo pueda jugar con el joystick o con un botón necesita la ayuda de otra persona para navegar por los menús del juego. Se hizo un cambio al final para solventar mínimamente este problema haciendo que al menos, al terminar de jugar una prueba (por llegar al final o por resultar eliminados por penalizaciones), en el menú de finalización si no hay ningún movimiento en el ratón aparece una cuenta atrás de 7 segundos en botón de empezar de nuevo, cuando llega a cero es como si se hubiera pulsado ese botón y la prueba se reinicia. Con esto al menos el jugador que utiliza joystick o un botón sólo necesita ayuda al iniciar el juego hasta llegar a la prueba que quiere jugar, una vez en ella puede reintentarla toda las veces que quiera sin la necesidad de otra persona.

Accesibilidad planteada pero no llegada a implementar:

Movilidad

Menús navegables con joystick o con un botón. Hubiera sido la siguiente característica implementada si se hubiera tenido más tiempo de desarrollo, para dar total autonomía para navegar por los menús a los jugadores que utilizan joystick o un botón.

No se añadió porque su implementación era más costosa de lo que se había pensado en un principio y no se le dio la prioridad que realmente necesitaba.

Visual

Modo alto contraste. Aunque el juego da total libertad de cambiar el contraste y el brillo, hubiera estado bien añadir un modo especialmente diseñado de alto contraste para personas con baja visión.

Modo gráficos simplificados. También se pensó en un modo de gráficos simplificados en el que se eliminarían elementos gráficos que realmente no son necesarios, como las gradas del estadio y paredes, para dejar sólo los elementos importantes del juego.

Además también que se hubieran simplificado ciertas texturas para tuvieran menos detalles pensando en que contrastaran más unos elementos del juego de otros.

Locuciones. Añadir locuciones en Inglés y Castellano hubiera ayudado a personas con baja visión y también a personas que tienen problemas de lectura a nivel cognitivo, pero era algo que se salía del presupuesto del juego.

Cognitiva

Indicadores de ayuda mientras juegas. Aunque el juego tiene la opción de añadir unas guías que te dicen por donde tienes que ir al siguiente obstáculo, se pensó en la idea de dar más indicaciones al jugador incluso mientras estaba dentro de un obstáculo, diciéndole paso a paso lo que tenía que hacer en cada momento.

Mapa durante el juego. Antes de iniciar una prueba de recorrido variable, en el menú de juego se puede ver un mapa de la prueba seleccionada, con el dibujo del recorrido y la situación de cada tipo de obstáculo. Entre las posibles características se pensó también añadir ese mapa mientras estabas jugando la prueba, y en el que además hubiera un ícono que identifica tu posición actual en el mapa y hacia dónde estás mirando. Esto hubiera ayudado mucho a saber tu situación dentro del circuito y cuál es la siguiente prueba que te toca. Perdió importancia porque con la opción de las guías en el suelo que indican como ir al siguiente obstáculo ya estaba solucionado este problema.

Íconos para los perfiles de jugadores. Cada jugador puede crear un perfil personal en donde se guarda su configuración del juego y al que le pone un nombre personalizado. Lo ideal hubiera sido también poder asignar un ícono, avatar o fotografía a ese perfil; pensando en personas con dificultades de lectura.

Conclusiones

Aunque se cometieron algunos fallos en las decisiones de prioridad de las características de accesibilidad, en general, el Centro de Referencia Estatal Discapacidad y Dependencia de León quedó muy satisfecho del resultado del proyecto y del nivel de accesibilidad alcanzado.

El equipo de desarrollo aprendió que a nivel de programación habría que plantear mejor ciertas cosas desde el principio, desde que se conocen cuáles son las características de accesibilidad más importantes para este juego y que seguramente acaben implementándose, para que finalmente se puedan añadir sin que sea una labor demasiado costosa.También hubiera estado bien analizar mejor el coste de la implementación de ciertas opciones de accesibilidad pensando en las limitaciones de la tecnología que se estaba usando.

Más sobre Slalom, el Videojuego. Slalom, el Videojuego se puede descargar de forma gratuita para PC Windows aquí: [Descargar el juego aquí]

Y se puede encontrar más información, capturas de pantalla y videos sobre el juego y su desarrollo aquí: [Ver online]

Para más información sobre el deporte de Slalom en silla de ruedas y su reglamento, puedes visitar la página web de la Federación Española de Deportes de Personas con Parálisis Cerebral y Lesión Cerebral: http://www.fedpc.org/

Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad y usabilidad, por Emmanuelle Gutiérrez y Restrepo

Mini biografía del autor

Es Experta en Accesibilidad en el Grupo de Investigación aDeNu, del Departamento de Inteligencia Artificial de la Universidad Nacional de Educación a Distancia (UNED), es Licenciada en Ciencias de la Comunicación (Rama de Cine, Radio y Televisión), Master en Comunicación en Sociedad y Problemas Sociales, Experto en Comunicación e Imagen Corporativas; por la Universidad Complutense de Madrid. Patrono y Directora General de la Fundación Sidar – Acceso Universal, es activista de la accesibilidad informática desde 1995, y en especial de la accesibilidad en Internet. Ponente invitado en congresos nacionales e internacionales. Ha impartido numerosos cursos y seminarios sobre accesibilidad en Argentina, Colombia, Chile, El Salvador, España, México, Perú, Portugal, y Puerto Rico, entre otros países. Es Experto Invitado en el Grupo de Trabajo Education & Outreach y en el de Evaluation and Repair Tools del W3C-WAI, participó en el Grupo de Trabajo para la redacción de las WCAG 1.0 y de la versión 2.0, y participa activamente en otros grupos de interés relacionados con la web semántica.

Lo que desconocemos que conocemos sobre accesibilidad y usabilidad

Introducción

El presente artículo se fundamenta en el estudio que fue la base para la conferencia que impartí en el Congreso Internacional CAVA 2010 [CAVA 2010, 2010], que se celebró en Cartagena de Indias, del 1 al 3 de septiembre de 2010. Mediante la comparación con las técnicas y prácticas habituales en la creación de documentos de texto, y siguiendo los tipos de contenido que suelen encontrarse en la mayoría de los sitios web hoy en día, especialmente aquellos que han sido creados mediante un gestor de contenidos, se analizan los criterios de conformidad que tienen su equivalente en dichas prácticas habituales y que, por tanto, todo desarrollador y diseñador conoce de antemano. De esta manera, veremos cómo todos tenemos un conocimiento de la accesibilidad y la usabilidad, que no sabíamos que teníamos.

El lector no ha de asustarse por las referencias y términos ciertamente especializados del campo de la accesibilidad web, puesto que en definitiva el resultado de la lectura de este artículo no hará más que proporcionarle confianza y, quizás, algún conocimiento nuevo sobre la forma correcta de estructurar y definir la presentación de un contenido que puede estar destinado a la comunicación general o a la enseñanza, tanto por medios “tradicionales” como los documentos en Word o PDF, como en formato HTML para ser empaquetados como objetos de aprendizaje. Todo el estudio se hace sobre los textos de las Pautas de Accesibilidad para el Contenido Web 2.0 [WCAG 2.0] [W3C-WAI, 2009], teniendo en cuenta el documento “How to meet WCAG 2.0” [W3C-WAI, 2008], el “Understanding WCAG 2.0” [W3C-WAI, 2008], y el extenso documento de “Techniques for WCAG 2.0” [W3C-WAI, 2008b]; pero en este artículo nos limitaremos a citar los números de los criterios, para que sólo aquellos más directamente relacionados con la creación web y la revisión de su accesibilidad consulten el texto original del estudio [Gutiérrez y Restrepo, 2010].

Los documentos anteriormente citados, pueden resultar realmente complejos en un principio, pero su objetivo último es facilitar la comprensión de aquello que hay que tener en cuenta a la hora de crear un contenido web de manera que resulte fácil su utilización, comprensible su contenido y satisfactoria su interacción; por parte de cualquier persona, incluyendo a las personas mayores y con discapacidad, entre otros grupos de usuarios que pueden encontrarse con ciertas limitaciones personales o tecnológicas.

Utilizaremos para guiarnos una maqueta o “mockup” de un sitio web ficticio, en la que hemos destacado cada uno de los tipos de contenido y secciones que constituirán la web final.

Encabezado

En el encabezado encontramos una serie de elementos que no suelen percibir la mayoría de los usuarios, pero sí lo hace uno de nuestros usuarios preferidos y al que prestamos especial atención: Google y los demás robots de búsqueda. Son elementos especialmente importantes para la indización y localización de nuestros contenidos.

Idioma de la página

Cuando creamos un texto en un editor de textos como por ejemplo Word u Office Writer, una de las primeras cosas que nos interesa hacer es definir en qué idioma vamos a escribir, para que el editor pueda echarnos una mano con avisos sobre posibles errores ortográficos o debidos al intento de escribir rápidamente.

De igual manera, aunque no con el mismo propósito, al crear una página web debemos indicar en qué idioma estarán los contenidos. Esto se hace en el elemento <html> mediante el atributo lang. Hoy en día los Gestores de Contenidos o CMS [Content Management System, por sus siglas en inglés] facilitan esta tarea y, por tanto, es menos habitual encontrar páginas que no tengan una indicación de idioma principal de la página.

La indicación de idioma principal es fundamental para que los robots de búsqueda puedan indizar correctamente la página, los navegadores puedan servir al usuario los contenidos en el idioma que haya indicado como favorito [cuando el sitio ofrece los contenidos en varios idiomas y utiliza la negociación de contenidos] y para que los usuarios de lectores de pantalla obtengan una lectura con una pronunciación correcta.

Al indicar el idioma principal de la página estamos cumpliendo con el criterio de conformidad 3.1.1 Idioma de la página.

Título

El título de cualquier obra es un elemento distintivo al que todo autor dedica especial atención. En un contenido o recurso web es igualmente importante pues permitirá identificar y distinguir el recurso y cada uno de sus contenidos. Hace algún tiempo era bastante habitual encontrar páginas cuyo título era: “place title here” o alguna expresión parecida que ponía automáticamente el editor de HTML en el elemento <title> para que el autor la reemplazara por el título adecuado para cada página. Hoy en día es menos común gracias al uso de los CMS, pero por otro lado se está extendiendo el mal hábito de que todas las páginas que constituyen un sitio o recurso lleven exactamente el mismo título, el nombre del sitio o empresa que lo publica, que incluye automáticamente el CMS.

El título de cada página o contenido ha de ser distintivo y, si bien conviene que haga referencia al propietario del sitio, ha de ser distinto en cada una de ellas refiriéndose concretamente a lo que el usuario encontrará en esa página en especial. De esta manera será más fácil para el usuario encontrar una determina sección o contenido en nuestra web.

Indicando un título adecuado para cada una de nuestras páginas, estaremos cumpliendo con el criterio de conformidad 2.4.2 Titulado de páginas.

Elementos meta

Los elementos <meta> nos permiten transmitir información sobre la información contenida en cada una de nuestras páginas. Por tanto, aunque algunos de ellos puedan y deban contener exactamente la misma información en todas las páginas, no es conveniente que todos esos elementos sean exactamente igual en todas las páginas.

Al igual que cuando creamos un documento en un editor de textos indicamos quién es el autor, de qué trata el documento y con qué palabras clave está relacionado, desde las propiedades del documento; igualmente debemos hacer al crear una página web utilizando los elementos <meta>.

La meta información que nos permite transmitir este elemento es muy variada, va desde la indicación de tipo de caracteres que se utilizan en los contenidos, hasta cada cuánto tiempo deben repasar la página los robots de búsqueda para indizar nuevos contenidos en ella, pasando por quién o qué entidad es la responsable de la página, qué palabras clave se asocian con sus contenidos y una breve descripción de éstos.

El uso de los CMS ha facilitado que los autores incluyan en mayor medida algunas de estas meta-informaciones. Aunque lamentablemente encontramos habitualmente sitios en los que la descripción y las palabras clave son las mismas en todas las páginas. Esto limita las posibilidades de localización e indización de los contenidos.

Elementos link

Algunos desarrolladores o autores Web conocen bien el elemento <link> en cuanto les permite indicar a los robots que no indexen determinada página, y a los navegadores dónde se encuentra la o las hojas de estilo, pero poco más. Muchos lo han descubierto al empezar a usar la sindicación o adentrarse en el mundo de los cuadernos de bitácora [blogs], pues en ellos se usa para identificar la relación entre entradas, los archivos, los temas, etc. [Atom, 2005].

No vamos a pretender aquí que los desarrolladores realmente usan de forma generalizada el elemento <link> en toda su capacidad y potencia para incrementar la accesibilidad, como sería el caso si se usase para definir la relación entre la página actual y el resto de páginas del sitio [Gutiérrez y Restrepo, 2005]. Cumplirían con ello con algunas de las técnicas del criterio de conformidad 2.4.8 Ubicación con el 3.1.3 Palabras inusuales y con el 3.1.4 Abreviaturas. Además se considera técnica recomendable para el cumplimiento del criterio 2.4.5 Múltiples vías.

Pero al menos sí que se ha generalizado el uso de este elemento para indicar la localización de la hoja de estilos y de los JavaScript, separando de esta manera el contenido de los efectos de presentación visual y comportamiento, lo que incrementa la accesibilidad de manera muy eficaz. Estamos entonces cumpliendo con el criterio 1.3.1 Información y relaciones.

Cabecera visual

En la cabecera de una página web se suelen colocar contenidos distintivos como el logo y nombre del sitio, institución o empresa, enlaces de ayuda al usuario, como al mapa del sitio, a la página de contacto, etc.; y algún lema o slogan y el buscador. Estos contenidos tienen su equivalente en un documento de texto, por ejemplo el mapa con el índice o tabla de contenidos para todo el sitio, y el logo, nombre de la empresa o institución y lema suelen crearse también en la cabecera del documento de texto.

Pero en las páginas web que pretenden ser accesibles se añade un elemento que no existe en un documento de texto: Un enlace que permite saltar todos los elementos comunes entre las páginas del sitio e ir directamente al contenido principal de cada una. Esta práctica viene siendo ya habitual en muchos sitios, en parte por el efecto emulador de diseñadores de renombre y en parte porque lo facilitan los CMS de hoy en día. Al incluir dicho enlace estamos cumpliendo con el criterio de conformidad 2.4.1 Evitar bloques.

Dicho enlace suele formar parte de lo que podríamos llamar “menú de navegación global”, del que hacen parte también los enlaces al mapa del sitio, forma de contacto e información sobre accesibilidad.

Menú de navegación global

Con el menú de navegación global, incluido ya en la mayoría de los “themes” o plantillas de los CMS, y fácilmente configurable por parte de los autores, estaríamos cumpliendo con varios criterios de conformidad: El 3.2.3 Navegación coherente y también puede ser que con el criterio 3.2.4 Identificación coherente; por ejemplo, en el caso de un manual o de un objeto de aprendizaje que ofrece unos enlaces para ir a la página anterior y la siguiente, siempre localizados en el mismo sitio y consistentes. En un documento en formato texto, esta funcionalidad de navegación entre páginas la ofrece la propia aplicación.

Mapa del sitio, contacto y ayuda

Como hemos dicho, el mapa del sitio sería el equivalente al índice o tabla de contenidos de un documento de texto, y es importante ofrecerlo pues incrementa la usabilidad y la accesibilidad. Cada vez son más los sitios web que ofrecen un mapa del sitio, con lo cual se cumple con el criterio de conformidad 2.4.5 Múltiples vías y del 2.4.8 Ubicación así como con el 3.1.3 Palabras inusuales. Otra cosa es cómo se crea y presenta ese mapa del sitio, pero eso lo trataremos más adelante.

En todo documento se ofrecen unos datos de contacto más o menos extensos y variados dependiendo del tipo de documento que se trate. De igual forma, en un sitio web hemos de ofrecer distintos modos de contactar con los responsables del sitio y en especial con el webmaster. De este modo estaremos facilitando al usuario la posibilidad de solicitar formatos alternativos de la información presentada y de avisar al webmaster sobre cualquier dificultad que encontremos en el sitio. Estaremos entonces aplicando una de las técnicas recomendadas para el cumplimiento de la Pauta 3.1 Legible.

En un documento de texto se suele incluir un apartado de introducción en el que se describe la conformación general del documento, indicando la localización de determinados apartados o elementos especiales. En un sitio web se suele ofrecer una página de ayuda al usuario, enlazada desde este menú de navegación global, en la que se suele hacer eso mismo. Al proporcionar instrucciones al usuario, ya sea en esta página de ayuda o en cualquier otro apartado de la web, es fundamental que no sea necesario depender de la percepción de características sensoriales para poder comprender las instrucciones. Esto es, las instrucciones han de cumplir con el criterio de conformidad 1.3.3 Características sensoriales.

Logo y nombre del sitio

Al igual que en los documentos que se presentan en papel membrete de una compañía o institución, en las páginas web se suele colocar el nombre y el logo del responsable del sitio o recurso. Con el uso de los CMS se ha generalizado un poco más el cumplimiento de un requisito de accesibilidad básico como es el de indicar mediante una alternativa textual qué significa cada imagen. Si bien es verdad que no siempre se cumple el criterio satisfactoriamente. Pero vamos a suponer que el desarrollador conoce y ha entendido el criterio de conformidad 1.1.1 Contenido no textual.

Pero siempre será recomendable, no sólo por accesibilidad sino por razones de posicionamiento, que el nombre del sitio lo incluyamos mediante texto y no mediante una imagen. Cosa que se facilita mucho hoy en día gracias a la progresiva implementación de CSS3 [W3C, 2010] en los navegadores, lo que nos permite incluir distintas fuentes y fuentes especiales en nuestras web con variados efectos de presentación, incluso. Y en un futuro cada vez más próximo tendremos la posibilidad de usar SVG [W3C, 2010b] para conseguir el efecto que queremos de manera accesible.

Buscador

En un documento de texto, el buscador lo proporciona la aplicación mediante la cual examinamos el documento, pero en un sitio web debe ser el autor el que proporcione mecanismos de búsqueda. Y esos mecanismos de búsqueda deben ser ajustables a las necesidades y preferencias del usuario. Si así lo hacemos, estaremos cumpliendo con una de las técnicas de aplicación del criterio de conformidad 2.4.5 Múltiples vías, que ya hemos mencionado antes. Proporcionar un mecanismo de búsqueda incrementará la usabilidad y la accesibilidad de nuestro sitio, siempre y cuando el listado de resultados se ofrezca también de manera accesible, es decir, bien estructurado.

Puesto que la interfaz para la búsqueda es un campo de formulario, se ven aquí implicados todos los criterios relacionados con este tipo de elementos, y habremos de aplicar la Pauta 3.3 Entrada de datos asistida: Ayudar a los usuarios a evitar y corregir los errores, en sus distintos grados de accesibilidad según sea el caso.

Además, habremos de aplicar las técnicas suficientes para cumplir con el criterio de conformidad 1.3.1 Información y relaciones, el 2.4.3 Orden del foco, el 2.4.7 Foco visible, y el 4.1.2 Nombre, función, valor.

Contenido principal

Llegamos por fin al contenido principal del recurso o página, y en él encontraremos una serie de elementos comunes y no comunes a un documento de texto. Por ejemplo, las “migas” no son un elemento común a los documentos de texto ya sean comerciales o científicos, pero los encabezados o títulos y subtítulos, las listas, las citas, las imágenes y gráficas, y las tablas; sí son comunes a muchos tipos de documentos de texto. Veamos pues todos ellos:

Las migas

Otro elemento funcional que favorece la accesibilidad y que se ha generalizado ampliamente gracias al uso de CMS es la inclusión de las llamadas “migas de pan” o rastro que indica al usuario dónde se encuentra respecto al árbol de navegación del sitio.

Proporcionar esta “migas” es una de las técnicas suficientes para el cumplimiento del ya mencionado criterio de conformidad 2.4.8 Ubicación. Y al crear esas migas mediante una lista, estaremos también dando cumplimiento a una de las técnicas suficientes para el cumplimiento del criterio 1.3.1 Información y relaciones.

Encabezados de sección

Nuestro documento, sea del tipo que sea, habrá de estructurar la información de manera que sea más fácil comprender su contenido. Para ello, crearemos tantas secciones como sea conveniente, y cada una de ellas llevará un título y, posiblemente, uno o varios subtítulos.

Al estructurar el documento de esta manera, estaremos cumpliendo con varios criterios de conformidad. Aunque hay que decir, que realmente no se ve una aplicación correcta de los mismos de manera generalizada. Sobre todo es muy habitual encontrar fallos en cuanto al orden correcto de anidación de los elementos de encabezado y a la función que han de cumplir. Y lamentablemente esto ocurre sobre todo con el elemento de encabezado de primer nivel, que en muchos “themes” o plantillas se genera en todas las páginas para indicar el nombre del sitio en la cabecera. También es muy habitual no encontrar el título del contenido principal marcado con un elemento de encabezado de primer nivel.

Si lo hacemos correctamente estaremos cumpliendo con los siguientes criterios: El ya mencionado 1.3.1 Información y relaciones, el 2.4.6 Encabezados y etiquetas, y con el 2.4.10 Encabezados de sección.

Nivel de lectura

Tanto para los encabezados o títulos, como para el contenido en general es importante tener en cuenta el nivel de lectura necesario para comprender el texto. Dependiendo de cuál sea el público o audiencia del sitio, el nivel de lectura habrá de ajustarse llegando incluso, para el caso de sitios o contenidos dirigidos a personas que puedan tener ciertas deficiencias cognitivas o de aprendizaje, a requerir que se ofrezcan alternativas que apliquen las “pautas para la lectura fácil” [ILSMH, 1998]. Para aquellos dirigidos a la ciudadanía en general y en general para todos los sitios que pretendan conseguir el más alto grado de accesibilidad, se ha de cumplir con el criterio de conformidad 3.1.5 Nivel de lectura: Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese grado de educación. [Nivel AAA].

Pero existen también una serie de técnicas recomendadas, que probablemente los autores pondrán en práctica sin saber que se tratan de técnicas para el cumplimiento de la Pauta 3.1 Legible: Hacer que los contenidos textuales resulten legibles y comprensibles, como son: no justificando completamente los textos, justificándolos a la izquierda [cuando el idioma usado se lee de izquierda a derecha], limitando el ancho de las columnas, limitando el uso de estilos a unos pocos y realmente necesarios, haciendo que los enlaces se distingan claramente del resto de textos, proporcionando ilustraciones del texto mediante gráficas, videos, versión hablada o símbolos [por ejemplo cuando usamos íconos asociados a cada elemento de un menú], no usando el blanco absoluto como fondo para el texto negro, respetando la ortografía y la ortotipografía del idioma en que se escribe; entre otros. Todos ellos generalmente sugeridos desde la usabilidad.

Es práctica habitual y regla ortotipográfica que cuando incluimos términos o frases en un idioma distinto al general del documento, los marquemos e indiquemos claramente mediante el uso de la cursiva. También, es importante marcar esos textos con el cambio de idioma pertinente, para que el revisor ortográfico de la aplicación pueda hacer bien el trabajo y no nos llame la atención sobre un texto creyendo que está en el idioma general del contenido, cuando está en otro. En un recurso web no es suficiente con modificar la forma de presentación del texto sino que contamos con un medio para indicar a cualquier aplicación el idioma en el que está ese término frase. Esto contribuye de manera fundamental a la accesibilidad [en este caso a la comprensión] por parte de varios grupos de usuarios y a la vez mejorará la indización de nuestros contenidos. Estaríamos cumpliendo con el criterio de conformidad 3.1.2 Idioma de las partes.

También con el uso de los CMS podemos esperar, en cierta medida, que nos ayuden a cumplir con el criterio de conformidad 1.4.8 Presentación visual: En la presentación visual de bloques de texto, se proporciona algún mecanismo para lograr lo siguiente: [Nivel AAA]

Los colores de fondo y primer plano pueden ser elegidos por el usuario.

El ancho no es mayor de 80 caracteres o signos [40 si es CJK].

El texto no está justificado [alineado a los márgenes izquierdo y derecho a la vez].

El espacio entre líneas [interlineado] es de, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos es, al menos, 1.5 veces mayor que el espacio entre líneas.

El texto se ajusta sin ayudas técnicas hasta un 200 por ciento de modo tal que no requiere un desplazamiento horizontal para leer una línea de texto en una ventana a pantalla completa.].

Los puntos 1 y 5 se consiguen con la separación entre contenido y presentación, y el uso de unidades relativas en vez de fijas para la indicación de tamaños de texto y bloques contenedores o capas. Y el resto son fácilmente alcanzables mediante la definición de estilos y son de aplicación común en la creación de documentos de texto de tipo divulgativo. Todos ellos contribuyen a la legibilidad del contenido y son generalmente solicitados desde la perspectiva de la usabilidad.

Párrafos, listas, negritas, cursivas, secuencia de lectura, etc.

Los editores de texto ofrecen a los autores la posibilidad de marcar apropiadamente tanto los párrafos, como los elementos de una lista, como los textos destacados que se representarán en negrita o cursiva, etc. Aunque la mayoría de los usuarios utilizan las opciones de formato directo que aparecen como botones en vez de los estilos definidos para la plantilla que estén usando; lo cual crea serios problemas de accesibilidad. De la misma manera, en la creación de un documento web, lamentablemente encontramos muchos sitios en los que los textos aparecen sin marcar apropiadamente, muchas veces puestos directamente dentro de una capa y tan sólo, separados por el elemento <br> que no transmite suficiente información sobre dónde empieza un párrafo y termina otro. Los elementos para destacar palabras o frases que se representan visualmente en los navegadores con texto en negrita o cursiva, también se utilizan espuriamente y no para destacar textos que realmente merezcan tener un énfasis o énfasis fuerte. Pero los autores de documentos de texto que ya estén acostumbrados a crear documentos “comme il faut” tienen ya integrada en sus hábitos de trabajo la costumbre de marcar apropiadamente cada tipo de texto.

Cumplirán entonces con el criterio ya citado 1.3.1 información y relaciones, y con varias de sus técnicas suficientes, y en algunos casos será necesario también cumplir con el requisito de conformidad 1.3.2 Secuencia significativa.

Citas y textos citados

También en los documentos en general son de uso común las citas y bloques de texto citado, por lo que los autores estarán más o menos familiarizados con la importancia de destacar tanto visual como estructuralmente este tipo de contenidos. En un recurso o documento web, contamos con la posibilidad y el deber de hacerlo también de manera muy precisa. Deberemos cumplir con el ya citado criterio de conformidad 1.3.1 Información y relaciones, pero en este caso aplicaremos la Técnica General 115, que nos indica que debemos utilizar elementos de marcado significativos para identificar la estructura, y la técnica de HTML que nos pide utilizar marcado significativo para indicar el texto especial o que deba enfatizarse. Hoy en día aún algunas plantillas de los CMS cometen el error de utilizar el marcado de bloques de texto de manera espuria.

Abreviaturas y palabras inusuales

De todos es conocido que al crear un documento cualquiera la primera vez que se utiliza una forma abreviada [abreviatura o acrónimo] de indicarse su significado en su forma expandida, y de la misma manera debe hacerse en un recurso o documento web, pero también contamos con mecanismos para identificarlas cada vez que aparecen, y ofrecer a los usuarios un modo de recordar su significado. Haciendo esto estamos cumpliendo con el criterio 3.1.4 Abreviaturas.

Cuando en un documento se utiliza un término de manera poco usual o que tiene un significado distinto según el contexto del documento al que pueda tener en otros contextos, generalmente se proporciona una explicación sobre este extremo ya sea mediante un glosario o mediante una nota a pie de página. Si queremos conseguir el más alto grado de accesibilidad en un recurso web, hemos de cumplir con el criterio 3.1.3 Palabras inusuales: Se proporciona un mecanismo para identificar las definiciones específicas de palabras o frases usadas de modo inusual o restringido, incluyendo expresiones idiomáticas y jerga. [Nivel AAA]. Este criterio nos ofrece varias técnicas que podemos utilizar y, aunque no me atrevo a afirmar que sea una práctica generalizada, al menos sí que es conocida como principio general en la creación de cualquier documento.

Enlaces o hipervínculos

En un documento de texto extenso pueden utilizarse marcadores para identificar puntos o secciones con las cuales se va a enlazar otro contenido al citarlas. En una web los enlaces o hipervínculos son elementos esenciales y, por tanto, habremos de tener especial atención con ellos. Como principio general han de ser distinguibles del resto de contenidos, lo que es un principio básico de usabilidad, y con ello cumpliremos con el criterio 1.4.1 Uso del color, pero también ha de poderse deducir claramente su propósito u objetivo ya sea que formen parte de un contexto o que se encuentren aislados. Cumpliremos entonces con los criterios 2.4.4 Propósito de los enlaces (en contexto y con el 2.4.9 Propósito de los enlaces solo enlaces).

Las técnicas suficientes para cumplir con estos criterios de conformidad no están tan ampliamente generalizadas como sería de esperar, pero dado que la primera ley de Internet “copiaos los unos a los otros” se sigue a rajatabla, su generalización se hará seguramente de manera exponencial en cuanto los diseñadores implemente de forma masiva las WCAG 2.0.

Tablas

En bastantes tipos de documentos de texto es habitual tener que incluir tablas de datos, y tanto al crear un documento de este tipo como al crear una página o recurso web es fundamental dar el formato apropiado a cada uno de los tipos de datos que se incluyan en la tabla, especialmente es importante establecer las relaciones entre los datos y los encabezados a los que pertenecen. Los editores de texto facilitan esta tarea, aunque no es muy habitual ver tablas bien marcadas, de lo que se deduce que los usuarios no suelen tener un conocimiento muy profundo de las opciones de configuración de documentos que les ofrece su editor.

Aquellos que sí aprovechan todas las posibilidades de estructuración de contenidos de su editor, tienen muy fácil comprender y cumplir con el criterio de cumplimiento, ya mencionado, 1.3.1 Información y relaciones, para el que hay una serie de técnicas suficientes directamente relacionadas con la creación de tablas, como el uso del atributo “caption”, para asociar la tabla con su título, el atributo “summary”, para dar una visión general de la disposición de su contenido, y los atributos “scope”, “id” y “headers” para asociar los datos en celdas con las celdas de encabezado.

Sintaxis

Una cuestión esencial en la creación de todo documento es revisar la gramática y ortografía del mismo. Hemos hablado ya de la importancia de revisar la ortografía y la ortotipografía, pero también la gramática es fundamental. De igual manera, en la creación de un recurso o página web es muy importante revisar la sintaxis del código fuente. Cumplimos así con el criterio de conformidad 4.1.1 Procesamiento.

Conclusiones

Con los conocimientos básicos para crear un documento de texto, bien formateado, legible y comprensible para nuestros destinatarios, conseguimos cumplir con 32 de los 61 criterios de conformidad de las WCAG 2.0. Es decir, cumplimos con el 52% de las pautas de accesibilidad para el contenido web.

De los 25 criterios de conformidad de nivel A, cumplimos con 15, lo que significa cumplir con el 60% de ellos.

De los 13 criterios de conformidad con nivel Doble A, cumplimos con 8, lo que significa cumplir con el 61,5% de ellos.

De los 23 criterios de conformidad de nivel Triple A, cumplimos con 9, lo que significa cumplir con 39% de ellos.

Pero lo más importante a tener en cuenta es que si nuestra página o recurso web es sencillo, no contiene elementos multimedia, contenidos dinámicos, ni exige la entrada de datos por parte del usuario que supongan información sensible de tipo legal o bancaria, con estas simples prácticas ya conocidas por todos y tan sólo prestando atención al contraste de color, tendremos una web con un muy alto grado de accesibilidad, pues los puntos que están recogidos aquí se refieren todos ellos a esos tipos de elementos y funcionalidades.

En definitiva, como hemos visto, la accesibilidad web no exige que hagamos nada extraño, no hacen falta conocimientos que no sean aplicables a otros órdenes de nuestra vida, y sus requisitos son todos de puro sentido común para dar la oportunidad a todos los humanos de participar en la Sociedad de la Información y del Conocimiento de manera equitativa. Además, cumplir con los criterios de conformidad no mencionados en este documentos no es difícil y está al alcance de todo desarrollador y diseñador actual, cualquiera que sea la tecnología que haya decidido utilizar para crear su documento o recurso web.

Referencias

Atom, 08/07/2005. Link Tag Meaning, Recuperado el 08/08/2010, de Intertwingly: [Ver en línea Link Tag Meaning]

CAVA 2010, Página principal de CAVA 2010, Recuperado el 03/03/2011, de CAVA 2010: [Ver en línea CAVA 2010]

ILSMH, 06/1998, Pautas de estilo: Sidar. Recuperado el 08/08/2010, de Sidar: [Descargar PDF]

W3C, 19/07/2010, Cascading Style Sheets. Current Work. Recuperado el 08/08/2010, de W3C: [Ver en línea CSS]

W3C. 2010, Scalable Vectors Graphic. Recuperado el 08/08/2010, de W3C: [Ver en línea W3C Vector]

W3C-WAI, 01/12/2008, How to meet WCAG 2.0. Recuperado el 10/08/2010, de W3C: [Ver en línea W3C-WAI]

W3C-WAI, 11/12/2008, Techniques for WCAG 2.0. Recuperado el 10/08/2010, de W3C: [Ver en línea W3C-WAI técnicas]

W3C-WAI, 11/12/2008, Understanding WCAG 2.0. Recuperado el 10/08/2010, de W3C: [Ver en línea W3C-WAI Understanding]

W3C-WAI, 15/12/2009, Traducción WCAG 2.0. Recuperado el 10/08/2010, de SIDAR: [Ver en línea traducción W3C - SIDAR]

Capítulo 12: Ergonomía física y cognitiva: los sistemas sensoriales humanos y la evaluación ergonómica de interfaces, por Sebastián Betti

Mini biografía del autor

Ingeniero de sistemas, comenzó su carrera en la industria de las aplicaciones de telefonía y en la actualidad lidera el desarrollo de portales web en Petrobras Argentina. Es profesor asistente de la Especialización en Usabilidad y Accesibilidad de la Universidad Tecnológica Nacional y coordinador de español en el proyecto interlingüístico del sitio www.ted.com.

Más información:

Correo electrónico: Enviar mail al autor.

Twitter: @se6as

Ergonomía física y cognitiva: los sistemas sensoriales humanos y la evaluación ergonómica de interfaces

Introducción

La medida del grado en que las personas podemos aplicar una herramienta de manera exitosa en la consecución de un propósito pretendido, nos ha acompañado desde tiempos inmemoriales. Primero fue el homo habilis que con su herramienta precaria, la piedra, perseguía su idea de fuego. Luego, hace más de dos milenios fue Vitruvio 1 en su tratado “De Architectura” quien afirmó que la arquitectura descansa en tres pilares: la Firmeza (firmitas), la Belleza (venustas) y la Utilidad (utilitas). Y, salvando las distancias, incluso los programas informáticos pueden ser analizados desde esta tríada vitruviana. [Betti, 2008]. Otros enfoques del diseño más contemporáneos se centran en el estudio de una suerte de homo ergonomicus [Keller y Stappers, 2005], poseedor de unas características físicas condicionantes del mismo. Y, en este sentido, probablemente la imagen más famosa del estudio de las proporciones del cuerpo humano sea el Hombre de Vitruvio 2 [Wakeford, 2004] de Leonardo da Vinci. De hecho, ese fue el ideal de la pintura occidental durante varios siglos, y fue la base expresiva de medidas ergonómicas como el “modulor” de Le Corbusier [Le Corbusier, 1961]; una formalización del hombre ideal con la intención primaria de derivar todo el diseño del mundo a partir de la escala humana.

Dentro de la psicología, la ergonomía cognitiva es la disciplina que estudia los aspectos conductuales y cognitivos de la relación entre el hombre y los elementos físicos y sociales del ambiente, cuando esta relación está mediada por el uso de artefactos. [Cañas y Waern, 2001]

A nivel sensorio-motor, fue el neurólogo canadiense Wilder Penfield quien publicó en 1950 una representación del esquema corporal humano construido según la cantidad de estímulos que recibe el córtex cerebral. [Dawkins, 2008] El homúnculo sensorial de Penfield es un breve resumen visual de las habilidades sensoriales humanas y, en particular, de las de la mano. De allí la importancia de estas investigaciones para aplicar los resultados en evaluaciones hápticas de interfaces y en el diseño de aplicaciones, productos y servicios que aprovechen la motricidad y sensibilidad de la mano en las interacciones, como el móvil Braille de Sumit Dagar 3 o las haptografías de Katherine Kuchenbecker 4.

Otro caso interesante es el guante móvil Lorm ideado en Berlín por el equipo de investigadores del Design Research Lab 5. Se trata de un dispositivo de comunicación y traducción para sordos-ciegos. Traduce del alfabeto táctil Lorm 6 a texto digital y viceversa. Este proyecto es un ejemplo de patrones de retroalimentación vibrotáctil que permiten al usuario percibir los mensajes de texto entrantes, en el dorso de la mano. Y por la misma vía generar mensajes en Lorm, desde la palma de la mano, que se traducen en textos salientes.

Evaluación ergonómica de interfaces

Existe una serie de criterios para la evaluación ergonómica de interfaces, que minimiza las ambigüedades en la identificación y clasificación de las cualidades y problemas relacionados con la ergonomía de sistemas interactivos. Para profundizar en este tipo de evaluaciones, analizaré el trabajo de la dupla de investigadores franceses Christian Bastien y Dominique Scapin [Bastien y Scapin, 1993] que en 1993 propusieron un conjunto de 8 criterios ergonómicos principales que, a su vez, se subdividen en 18 subcriterios y criterios elementales.

El objetivo de los estudios ergonómicos centrados en el individuo consiste en reducir la carga del esfuerzo mental, visual y físico: 1) reduciendo entradas innecesarias; 2) ofreciendo valores default; 3) exhibiendo mensajes de error de fácil comprensión; 4) proveyendo atajos de ayuda de fácil acceso; 5) brindando feedback inmediato de las acciones realizadas en la computadora, hayan sido concluidas o no; 6) adecuando elementos de acuerdo con su funcionalidad o 7) siguiendo algún criterio lógico (intuitividad) por ubicación o por formas y colores, de acuerdo a su legibilidad, etc.

La siguiente tabla resume los criterios de conformidad para la evaluación ergonómica de interfaces humano-computadora.

Detalle y razón de ser de los criterios

1. Guía del usuario

La guía del usuario se refiere a los medios disponibles para aconsejar, orientar, instruir y guiar a los usuarios en sus interacciones con la computadora (mensajes, alarmas, etiquetas, etc.) desde un punto de vista léxico.

Una buena guía facilita el aprendizaje y el uso de un sistema permitiéndole a los usuarios: 1) saber en cada momento dónde están en una secuencia de interacciones, o en la consecución de una tarea; 2) saber cuáles son las posibles acciones y sus consecuencias; y 3) obtener información adicional (posiblemente a pedido).

Una buena guía es un excelente catalizador del modelo de la articulación de preferencias [Chernev, 2003] que sostiene que cuando uno sabe exactamente lo que busca, más opciones es mejor porque hay más probabilidades de encontrar exactamente lo que se busca. Luego elegir es fácil. Si no se tiene esto en claro, muchas opciones producen parálisis.

La facilidad de aprender y la facilidad de uso, producto de una buena guía, lleva a mejores rendimientos y menos errores. Tanto es así que el aspecto más importante a tener en cuenta si se quiere facilitar el aprendizaje exploratorio es diseñar la interfaz de tal manera que los objetos que el usuario encuentre en ella puedan ser relacionados fácilmente con la tarea que se quiere aprender a realizar. De la similitud semántica entre la tarea que el usuario quiere realizar y la etiqueta que aparece en la interfaz, depende el tiempo necesario para aprender a realizar dicha tarea. [Soto, 1999]

1.1 Prompting (articulación de acciones)

Se refiere a los medios disponibles para guiar a los usuarios hacia acciones específicas o para ayudarles a conocer las alternativas cuando hay varias acciones posibles dependiendo del contexto. También tiene que ver con la información de estado, es decir, información actual del estado o contexto del sistema, así como con la información de ayuda y de su accesibilidad.

Una buena articulación de acciones guía al usuario y le evita, por ejemplo, tener que aprender una serie de comandos. Le permite conocer exactamente el modo actual, si está en un diálogo, y también las acciones disponibles en ese contexto. En definitiva, le ayuda a navegar la aplicación o sistema y a reducir los errores.

1.2 Agrupamiento/Distinción de elementos

Este criterio está relacionado con la organización visual de los componentes de información entre sí. Tiene en cuenta la topología (ubicación) y algunas características gráficas (formato) para indicar las relaciones entre varios elementos mostrados, para indicar si pertenecen a una clase o para indicar diferencias entre clases. Este criterio también tiene que ver con la organización de elementos dentro de una clase.

El agrupamiento se subdivide en dos subcriterios: agrupamiento por ubicación y agrupamiento por formato.

1.2.1 Agrupamiento por ubicación

El agrupamiento por ubicación tiene en cuenta la ubicación relativa de los elementos para indicar si éstos pertenecen a una clase determinada, o para indicar las diferencias entre clases. También está emparentado con la ubicación relativa de los elementos dentro de una clase.

Los usuarios detectarán los distintos elementos con más facilidad si éstos se presentan en forma organizada (por ejemplo, en orden alfabético, por frecuencia de uso, etc.) Además, esto mejorará el aprendizaje y hará más fácil recordar los elementos.

1.2.2 Agrupamiento por formato

El agrupamiento por formato se relaciona con los aspectos gráficos (formato, color, etc.) que indican si los elementos pertenecen a una clase dada, o que indican distinciones entre diferentes clases, o de distintos elementos dentro de una clase dada.

Será más fácil para el usuario conocer las relaciones entre elementos o clases de elementos si se ilustran sus similitudes o diferencias con distintos formatos. Esto mejorará el aprendizaje y hará más fácil recordar los elementos.

1.3 Feedback inmediato

Este subcriterio está relacionado con las respuestas a las acciones del usuario. Estas acciones pueden ser entradas simples o transacciones más complejas como comandos en lote. En cualquier caso el sistema debe brindar una respuesta rápida, en tiempo y forma, para las distintas transacciones. Esta respuesta debe, además, proveer información sobre la transacción requerida y su resultado.

La calidad y la velocidad de respuesta son dos factores importantes para forjar la confianza y la satisfacción del usuario así como para la comprensión del diálogo. Estos factores le permiten al usuario entender mejor el funcionamiento del sistema.

La ausencia de feedback o la demora en el mismo puede desconcertar al usuario. Y si éste sospecha que ha ocurrido una falla en el sistema, podría emprender acciones potencialmente perjudiciales para los procesos en curso.

1.4 Legibilidad

La legibilidad hace alusión a las características léxicas de la información presentada en pantalla que puede dificultar o facilitar la lectura de esta información (brillo de la letra, contraste entre los caracteres y el fondo, tamaño de la letra, espaciado, interlineado, sangrías, etc.)

2. Carga de trabajo

La carga de trabajo se relaciona con los elementos de la interfaz que desempeñan un papel en la reducción de la carga cognitiva, mental o perceptual del usuario, y en el aumento de la eficiencia del diálogo. Se utiliza el término carga mental para referirse a la porción de recursos de procesamiento que una persona necesita para realizar una tarea [Norman y Bobrow, 1975; O’Donnell, 1986].

Cuanto más alta es la carga de trabajo, más alta la probabilidad de cometer errores. Y, a su vez, cuanto menos distracciones experimente el usuario, producto de información innecesaria, más posibilidades tendrá de terminar su tarea con eficiencia. [Krug, 2005] Por otra parte, cuanto más cortas sean las acciones, más rápida serán las interacciones.

2.1 Brevedad

El criterio de brevedad se refiere a la carga cognitiva o perceptual tanto de las entradas como de las salidas y de los conjuntos de entradas (por ejemplo, el conjunto de acciones necesarias para lograr un objetivo o tarea). Tiene que ver con el objetivo de limitar la lectura, la carga de entrada y la cantidad de pasos de una acción.

El criterio de brevedad tiene dos subcriterios: concisión y acciones mínimas.

2.1.1 Concisión

El criterio de concisión tiene que ver con la carga cognitiva y perceptual referente a las entradas y salidas. Y dado que la memoria de corto plazo es limitada, cuando se almacena una unidad de información en dicha memoria, si no se hace nada con ella, desaparece después de un intervalo de aproximadamente 20 segundos. [Peterson y Peterson, 1959]

Por otro lado, Huguenard y colaboradores [Huguenard, 1997] demostraron que, debido a las limitaciones en capacidad y procesamiento de la memoria de corto plazo, se cometen frecuentemente dos tipos de errores: 1) errores por pérdida de información, cuando el usuario olvida la información sobre lo que debe hacer; 2) errores de elección, cuando el usuario elige una opción incorrecta. En consecuencia, cuanto más cortas las entradas, menor es la probabilidad de cometer errores. Además, cuanto más sucintos son los elementos, más cortos son los tiempos de lectura.

2.1.2 Acciones mínimas

El subcriterio de acciones mínimas está relacionado con la carga de trabajo respecto de la cantidad de acciones necesarias para lograr un objetivo o una tarea. Se trata de limitar tanto como sea posible los pasos que deben realizar los usuarios.

Cuanto más numerosas y complejas sean las acciones necesarias para alcanzar un objetivo, mayor será la carga de trabajo y, en consecuencia, mayor el riesgo de cometer errores.

Hay otro factor que interviene en este subcriterio y es que existe un límite a la cantidad de información que puede retenerse en la memoria de corto plazo. Se estima que esta cantidad es de entre 4 y 7 unidades de información. [Miller, 1956; Cowan, 2001]

2.2 Densidad de información

La densidad de información se refiere a la carga de trabajo del usuario desde una perspectiva perceptual o cognitiva en referencia al conjunto de la información presentada al usuario en vez de a cada elemento en particular.

La mayoría de las veces, el rendimiento del usuario se ve perjudicado si la densidad de información es demasiado alta o demasiado baja: en estos casos, los errores se vuelven más probables. Entonces, los elementos que no tienen relación con la tarea deberían eliminarse. Las buenas prácticas establecen que puestos a elegir entre dos soluciones, siempre debe elegirse la solución más sencilla. Es lo que se conoce como lex parsimoniae, o principio de parsimonia.

Debe minimizarse la carga mental sobre el usuario. Debe evitarse la memorización de largas listas de datos o procedimientos complicados. Los usuarios no deberían realizar actividades cognitivas complejas si la tarea en cuestión no lo requiere.

3. Control explícito

El control explícito tiene que ver tanto con el procesamiento de las acciones explícitas del usuario como con el control que los usuarios tienen del procesamiento de sus acciones en el sistema.

En ocasiones el usuario puede delegar el control en un agente que gestiona la tarea en su nombre si esto reduce su carga cognitiva y da el resultado esperado. Es el modelo principal-agente [Keys y Schwartz, 2007], en el cual el principal (usuario) delega la tarea en el agente (interfaz) y disfruta del proceso mientras el agente realiza la tarea para el principal.

Pero puede ocurrir que el resultado no sea el esperado y la delegación del control produzca un desamparo aprendido [Seligman, Miller y Kurlander, 1975] Este modelo sostiene que gran parte de la frustración de los usuarios surge de un sentimiento de desamparo ocasionada por eventos negativos sobre los cuales la persona no tiene control. En esos casos, si los usuarios definen explícitamente sus entradas y si estas entradas están bajo su control, se minimiza la cantidad de errores, así como las ambigüedades y el nivel de frustración. Es más, el sistema será más aceptado por el usuario si éste tiene el control sobre el diálogo.

El control explícito se divide en dos subcriterios: acción explícita de usuario y control de usuario.

3.1 Acción explícita de usuario

El criterio de acción explícita de usuario estudia la relación entre lo que la computadora procesa y las acciones del usuario. Esta relación debe ser explícita. Es decir, la computadora debe procesar sólo aquellas acciones requeridas por el usuario y sólo cuando éste lo requiere.

Cuando lo que la computadora procesa es producto de acciones explícitas del usuario, éste aprende y entiende mejor el funcionamiento de la aplicación y se observan menos errores.

3.2 Control de usuario

El control de usuario se refiere al hecho de que el usuario siempre debería tener el control del procesamiento del sistema (por ejemplo, interrumpir, cancelar, pausar y continuar). Cada posible acción de usuario debería ser predecible y deberían mostrarse las opciones adecuadas.

El control sobre las interacciones favorece el aprendizaje y, por ende, disminuye la probabilidad de cometer errores. En consecuencia, la computadora se vuelve más predecible.

Nótese que la acción explícita de usuario se diferencia del control de usuario en que la primera se refiere al carácter explícito de las acciones requeridas por los usuarios, mientras que el segundo se refiere a la capacidad de control que el usuario debería tener sobre el proceso en curso.

4. Adaptabilidad

La adaptabilidad de un sistema se refiere a su capacidad de comportarse de manera contextual y de acuerdo a las necesidades y preferencias del usuario.

Cuanto más diversas las maneras de lograr una tarea dada, más probable es que cada usuario particular encuentre una forma que le resulte apropiada, una forma que aprenderá a dominar en el transcurso del aprendizaje. De esto se desprende que para lograr un objetivo dado deben proporcionarse procedimientos, opciones y comandos.

Además, una interfaz determinada puede no ser adecuada para todos sus usuarios potenciales. Para evitar efectos negativos en los usuarios, la interfaz debe adaptarse a ellos.

La adaptabilidad tiene dos subcriterios: flexibilidad y habilidad del usuario.

4. 1 Flexibilidad

La flexibilidad está relacionada con los medios disponibles para que el usuario personalice la interfaz con el objeto de tener en cuenta sus estrategias de trabajo o sus hábitos y los requerimientos de la tarea.

La flexibilidad se refleja en la cantidad de posibles maneras de lograr un objetivo dado. En otras palabras, es la capacidad de la interfaz para adaptarse a las necesidades particulares del usuario.

Cuanto más diversos sean los medios disponibles para realizar una tarea dada, más probable es que los usuarios elijan uno de ellos y lleguen a dominarlo en el transcurso del aprendizaje.

4.2 Habilidad del usuario

La habilidad del usuario tiene que ver con el grado de conocimiento de la interfaz por parte del usuario. Los usuarios expertos e inexpertos tienen distintas necesidades de información. Sería deseable brindarles a los usuarios sin experiencia un modo guiado que les permita realizar tareas paso a paso.

Para los usuarios experimentados, los diálogos con la computadora podrían resultar aburridos y percibidos como que hacen más lentas las interacciones; los atajos podrían permitir entonces un acceso más rápido a las funciones del sistema.

Los diferentes niveles de interacción deberían tener en cuenta las habilidades del usuario, pues con el correr del tiempo los usuarios pueden tornarse expertos a medida que ganan experiencia de uso, o volverse menos expertos luego de largos períodos de no usar la herramienta. Entonces, la interfaz debería acomodarse a las variaciones en el grado de conocimiento que el usuario tenga del sistema.

5 Manejo de errores

El manejo de errores se refiere a los medios disponibles para prevenir o reducir los errores y para recuperarse ante la ocurrencia de los mismos. Los errores se definen en este contexto como entrada inválida de datos, sintaxis incorrecta de comandos, etc.

Las interrupciones provocadas por errores del usuario tienen consecuencias negativas en las actividades del mismo. En general, este tipo de interrupciones aumenta la cantidad de interacciones y perturba la organización y la realización de la tarea. Al limitar la cantidad de errores, la cantidad de interrupciones también se ve limitada. Por ende, el rendimiento es mejor.

El manejo de errores tiene dos subcriterios: protección ante errores y calidad de los mensajes de error.

5.1 Protección ante errores

La protección ante errores tiene que ver con los medios disponibles para detectar y prevenir errores en el ingreso de datos, errores de comandos o acciones con consecuencias destructivas.

Es preferible detectar errores antes de la validación que después dado que la detección es menos perturbadora para el usuario.

5.2 Calidad de los mensajes de error

La calidad de los mensajes de error se refiere a la redacción y al contenido de los mismos, es decir: su relevancia, legibilidad, la especificidad de la naturaleza del error (sintaxis, formato, etc.) y las acciones necesarias para corregirlo.

La calidad de los mensajes promueve el aprendizaje de los sistemas por parte de los usuarios, indicándole al usuario las razones de sus errores, la naturaleza de los mismos, y persigue el fin didáctico de enseñarle maneras de prevenirlos o resolverlos.

5.3 Corrección de errores

La corrección está relacionada a los medios disponibles para que los usuarios enmienden sus errores. Los errores son menos traumáticos si se los puede corregir fácilmente y de inmediato.

6. Consistencia

La consistencia se refiere a la forma en que se mantienen las elecciones del diseño de la interfaz (códigos, nomenclatura, formatos, procedimientos, etc.) en contextos similares, y se diferencian al aplicarlos a contextos diferentes.

Los procedimientos, etiquetas, comandos, etc. se recordarán con más facilidad, serán mejor ubicados, reconocidos y usados si su formato, ubicación y sintaxis son estables de una pantalla a otra, de una sesión a la siguiente. En estas condiciones el sistema informático es más predecible, se facilita su aprendizaje y la generalización, y se reduce la ocurrencia de errores.

La falta de consistencia puede incrementar el tiempo de búsqueda de manera considerable y es una razón importante para el rechazo por parte del usuario.

7. Significado de los códigos

El significado de los códigos es un calificador de la relación entre un término y/o signo y su referencia. Los códigos y los nombres son significativos para los usuarios cuando hay una relación semántica fuerte entre tales códigos y los elementos o acciones a los que refieren.

Cuando los códigos son representativos, recordarlos e identificarlos se hace más fácil. Además, los códigos o nombres no significativos pueden conducir a operaciones de usuario no apropiadas y, por lo tanto, a errores.

8. Compatibilidad

La compatibilidad hace referencia a la concordancia entre las características del usuario (memoria, percepción, costumbres, habilidades, edad, expectativas, etc.) y las características de la tarea por un lado y la organización de la entrada, de la salida, y del diálogo para una aplicación dada, por otro lado.

La compatibilidad también está relacionada con la coherencia entre entornos y entre aplicaciones. La transferencia de información de un contexto a otro es más rápida y más eficiente si el volumen de información que requieren los usuarios para recodificarla es limitado.

Aumenta la eficiencia cuando: los procedimientos diseñados para realizar una tarea son compatibles con las características psicológicas del usuario; los procedimientos y las tareas se organizan respecto a las expectativas y prácticas del usuario; cuando se reduce la cantidad de traducciones, interpretaciones o referencias a la documentación.

Además, se observa una mejora en el rendimiento cuando la información se presenta en forma usable de manera directa.

Conclusiones

En este capítulo he presentado brevemente un marco conceptual y algunos trabajos realizados —principalmente en ergonomía cognitiva— en los últimos cincuenta años. Analicé algunas características de los sistemas sensoriales humanos y enumeré criterios ergonómicos necesarios para realizar estudios ergonómicos centrados en el individuo. Dichos estudios tienen como objetivo reducir la carga del esfuerzo mental, visual y físico de las interfaces para, de ese modo, adaptarse mejor a las capacidades humanas.

Presenté además proyectos como el móvil Braille de Sumit Dagar, el guante Lorm de Gesche Joost o las haptografías de Katherine Kuchenbecker, por citar solo algunos casos que muestran otras posibilidades de interacción.

Como afirma el futurista Vito di Bari, es momento de pasar de la era de las tecnologías inteligentes a la era de las tecnologías sensibles: tecnologías que se adapten a nuestros sentidos y se comporten en consecuencia. El diseño de una buena herramienta debe satisfacer las necesidades del hombre y al mismo tiempo amplificar las capacidades humanas, nuestras potencialidades sensoriales y cognitivas, para convertir lo que podemos hacer en lo que queremos hacer.

La revolución tecnológica que permita el cambio de paradigma en la visión de futuro del IxD no se producirá por generación espontánea, sino que será fruto de una larga experimentación de la que podemos ser parte. La ergonomía, por ejemplo, mediante evaluaciones hápticas o evaluaciones ergonómicas de interfaces, puede contribuir grandemente al diseño centrado en el individuo.¿Cómo? Teniendo en cuenta tempranamente en el proceso de diseño las características físicas y cognitivas del usuario. Eso permite ampliar la recepción de feedback que ofrecen los objetos del mundo exterior y esto redunda en herramientas más adaptadas al ser humano y, por lo tanto, más usables.

Referencias

1. Marcus Vitruvius Pollio, arquitecto e ingeniero romano, siglo I a.C

2. Homo quadratus, Leonardo da Vinci (1485-1490), Venecia, Galería de la Academia.

3. Móvil multitáctil para discapacitados visuales [ Ver video de móvil multitáctil ].

4. Digitalizando el sentido del tacto [ Ver video en Youtube ]

5. Mobile Lorm Glove [ Ir al sitio Web ]

6. Una forma común de comunicación utilizada por personas con discapacidad auditiva y visual.

Bibliografía

Bastien, Christian J.M., Scapin, Dominique L., Critères ergonomiques pour l’évaluation d’interfaces utilisateurs, INRIA Rocquencourt, mayo de 1993.

Betti, Sebastián, Homo habilis a la conquista del mundo: factores no computacionales que inciden en la calidad del software, Congreso Internacional de Información, La Habana, abril de 2008.

Cañas, J.J. y Waerns, Y., Ergonomía cognitiva. Aspectos psicológicos de la interacción de las personas con la tecnología de la información, Médica Panamericana, Madrid, 2001.

Chernev, Alexander, “Product Assortment and Individual Decision Processes”, Journal of Personality and Social Psychology, junio de 1985. En: Monitor on Psychology, junio de 2003. [último acceso: 28 de diciembre de 2012].

Cowan, N., “The Magical Number 4 in Short-term Memory: A Reconsideration of Mental Storage Capacity”. En: Behavioral and Brain Sciences, 24, pp. 87-114, Cambridge University Press, 2001.

Dawkins, Richard, El cuento del antepasado. Un viaje a los albores de la evolución, Antoni Bosch Editor, Barcelona, 2008.

Huguenard, B. R., Lerch, F. J., Junker, B. W., Patz, R. J., Kass, R. E., Working Memory Failure in Phone-based Interaction. ACM Transactions on Computer–Human Interaction, 4, pp. 67–102, 1997.

Keys, Daniel J.; Schwartz, Barry, “Leaky Rationality: How Research on Behavioral Decision Making Challenges Normative Standards of Rationality”, en: Perspectives on Psychological Science, 2007.

Keller, A.I., Stappers, P.J.; Creating People for Products: Humorous Homunculi in the Service of Design Communication. Designing Pleasurable Products and Interfaces, pp. 490-491, 2005.

Krug, Steve, Don’t Make Me Think. A Common Sense Approach to Web Usability, New Riders, Berkeley, California, 2005.

Le Corbusier, El modulor. Ensayo sobre una medida armónica a la escala humana aplicable universalmente a la arquitectura y a la mecánica, Editorial Poseidón, Buenos Aires, 1961.

Miller, G.A. “The Magical Number Seven Plus or Minus Two: Some Limits on our Capacity for Processing Information”, Psychological Review, 63, pp. 81-97, 1956.

Norman, D. A., y Bobrow, D. G., “Data Limited and Resource Limited Processes”, Cognitive Psychology, 7, pp. 44-64, 1975.

O’Donnell, R.D. y Eggemeier, F.T., “Workload assessment methodology”. En: K.R. Boff, L. Kaufman, and J. Thomas (Eds.), Handbook of Perception and Human Performance: Volume II Cognitive Processes and Performance, pp. 42-1-41-49, John Wiley, Nueva York, 1986.

Penfield, W., Rasmussen, T., The Cerebral Cortex of Man. A Clinical Study of Localization of Function, The Macmillan Comp, Nueva York, 1950.

Peterson, L.R., Peterson, M.J., Short-term Retention of Individual Verbal Items, Journal of Experimental Psychology, 58, pp. 193-198, 1959.

Seligman, M. E., Miller, W. R., Kurlander, H. M., Learned Helplessness, Depression and Anxiety, Journal of Nervous and Mental Disease, 161(5), pp. 347-357, 1975.

Soto, Rodolfo; Learning and Performing by Exploration: Label Quality Measured by Latent Semantic Analysis, University of Colorado, CHI 99, 15-20 de mayo de 1999.

Wakeford, N.; Innovation through People-Centered Design, Lessons from the USA. DTI Global Watch Mission Report, octubre de 2004.

Wickens, C. D., Engineering Psychology and Human Performance (2da Ed.). Harper Collins, Nueva York, 1992.

Ziegler, J. E., Vossen, P. H., Hoppe, H. U., “Cognitive Complexity of Human-Computer Interfaces: An Application and Evaluation of Cognitive Complexity Theory for Research on Direct Manipulation-style Interaction”, en: Falzon, P. (Ed.), Cognitive Ergonomics: Understanding, Learning, and Designing Human-Computer Interaction, pp. 27–38, Academic Press, San Diego, California, 1990.

Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking: El Caso de la TV conectada, por Mari Carmen Marcos

Mini biografía del autor

Profesora e investigadora del Departamento de Comunicación de la Universitat Pompeu Fabra de Barcelona. Licenciada en Documentación (1996) y Doctora en Documentación (2002). Experta en Interacción Persona-Ordenador y Recuperación de Información. Estudia el comportamiento de las personas en los procesos de búsqueda de información en la web. Autora de más de 70 trabajos. Subdirectora del Máster Online en Documentación Digital (IDEC-UPF), co-directora del Máster Online en Buscadores (IDEC-UPF) y Coordinadora del Máster en Gestión de Contenidos Digitales (UB-UPF).

Más información:

Ingresar al sitio web del autor

Correo electrónico: Enviar mail al autor.

Twitter: @mcmarcos

Verónica Mansilla

Periodista y Licenciada en Comunicación Social por la Universidad Andrés Bello en Chile (2005). Titulada en el Máster en Gestión de Contenidos Digitales por la Universitat de Barcelona y la Universitat Pompeu Fabra (2012). Actualmente estudiante de doctorado. Su línea de investigación es la interacción de las personas con sistemas de televisión en distintos dispositivos. Desde 2003 ha trabajado en medios de comunicación online y sitios web como Web Content Manager.

Más información:

Ingresar al LinkedIn autor

Correo electrónico: Enviar mail al autor.

Twitter: @verito_mansilla

Evaluación de la usabilidad con tecnología eye tracking: El Caso de la TV conectada

1. Introducción

De entre las distintas técnicas de evaluación de la usabilidad, los tests con usuarios son una de las más usadas ya que proporcionan información de primera mano sobre los problemas que presenta una interfaz a los usuarios finales (Barnum 2011; Dumas y Redish 1999). Sin embargo, no todos los problemas se explican observando al usuario o con una entrevista final, en ocasiones se requiere “ver con sus ojos” para entender el problema. Para esos casos, disponer de un eye tracker (ET) es de suma utilidad.

El ET es un dispositivo de seguimiento y grabación de la mirada que incorpora luz infrarroja y cámara de vídeo. Cuando está activado, ilumina al usuario con dos proyecciones de rayos infrarrojos que generan un reflejo en las córneas del los ojos, concretamente en la fóvea, que es una pequeña zona de la retina donde registramos la visión más nítida (no se registra por tanto la visión parafoveal ni la periférica). Una cámara de vídeo integrada en el equipo de ET recoge esos reflejos junto con la posición del usuario y, mediante procesamiento digital de la imagen, extrae la ubicación de las pupilas. La posición de las pupilas se mapean con la ubicación de la mirada en la pantalla; de esa forma se registran las fijaciones y las sacadas. Las sacadas son los movimientos que hacemos con los ojos al cambiar el foco de atención, son muy rápidos -¡hasta 500 movimientos por segundo!- (Duchowski 2009). Cuando mantenemos la mirada fija en un lugar durante varios milisegundos se produce una fijación (Figura 1).

El ET puede ir situado en un dispositivo que se coloca en la cabeza del usuario, por ejemplo en unas gafas, o bien grabar desde enfrente al usuario, por ejemplo incorporado en un monitor (figura 2).

La tecnología de eye tracking ha despertado interés en las áreas más diversas: Psicología Cognitiva, Diseño, Publicidad… e Interacción Persona-Ordenador, donde ha demostrado ser una herramienta que complementa al test de usuarios para estudiar la usabilidad y la user experience (Bojko 2012; Hassan y Herrero 2007; Jacob y Karn 2003; Nielsen y Pernice 2009; Nielsen y Pernice 2010; Pernice y Nielsen 2009; Poole y Ball 2004). En los últimos años se han publicado estudios sobre temas muy variados, por ejemplo en la Universitat Pompeu Fabra hemos llevado a cabo investigaciones sobre la interacción en los procesos de búsqueda en Google (Marcos, Nettleton y Sáez 2012) sobre diferencias culturales en esa interacción con el buscador ((Marcos, García-Gavilanes, Bataineh y Pasarín 2013), y sobre personalización de texto en pantalla para mejorar el rendimiento en la lectura (Rello y Marcos 2012; Rello, Pielot; Marcos; Carlini 2013).

2. La incorporación del eye tracker en un test de usuarios

Realizar un test de usuarios con tecnología ET no es muy diferente de un test sin este dispositivo, en realidad las etapas son las mismas, la forma de preparar el test también, y los errores que podemos cometer no difieren mucho (Marcos 2013), es más, ¡se amplía la lista! pero se han de considerar una serie de aspectos que ahora presentamos.

¿Realmente necesitamos testear con un eye tracker? Si se opta por realizar un test de usuarios con un ET debe ser porque interesa conocer cómo miran los usuarios una interfaz cuando realizan determinada tarea. Para cualquier otro dato que pretenda obtenerse durante el test, habrá que utilizar las técnicas y metodologías que se aplican en un test con usuarios convencional.

¿Nos lo podemos permitir? Antes de lanzarse a un estudio con ET, se debe hacer un cálculo realista de la inversión necesaria y contemplar el precio del eye tracker (sea de alquiler o de compra) y de la licencia del software de testeo y análisis.

¿Cuánta muestra necesitamos? Al igual que en un test de usuarios, si se va a realizar un estudio cualitativo, una muestra pequeña (por ejemplo 10 usuarios) será suficiente. En cambio si se van a realizar estudios cuantitativos el tamaño de la muestra dependerá de cuántas variables entren en juego, como orientación podemos decir que al menos se necesitarán 30 personas, posiblemente más.

¿Los usuarios deben cumplir algún requisito en cuanto a la visión? Para obtener datos fidedignos, los usuarios deberán tener una buena visión en ambos ojos, o ésta deberá estar corregida con gafas o lentes de contacto. El uso de gafas no es un impedimento, salvo que tengan una graduación muy alta y cristales gruesos, en tal caso no se registrarán bien las fijaciones y sacadas.

¿Qué métricas se obtienen de un test de usuarios con ET? Además de las métricas habituales de los estudios de usuarios (Sauro; Tullis y Albert 2008), los estudios con ET incluyen medidas propias de esta tecnología. Las más usadas en los estudios de usabilidad tienen relación con los niveles de performance de las tareas (eficacia y eficiencia); son las siguientes:

Porcentaje de participantes que han fijado su atención en una zona.

Tiempo que ha pasado desde que se ha presentado la interfaz hasta que los usuarios han fijado la vista por primera vez en una zona determinada. Mide la atracción de cierta zona de la interfaz.

Número de fijaciones de los usuarios en una interfaz o en una zona de una interfaz. Una mayor número indica mayor interés, o en ocasiones dificultad para comprender.

Duración de las fijaciones en una interfaz o en una zona de ésta. Una mayor duración indica mayor interés, o en ocasiones dificultad para comprender.

Camino recorrido por cada usuario, del que se puede obtener tanto su longitud como su complejidad.

Tiempo que ha pasado desde que los usuarios han visto una zona hasta que la seleccionan (con un clic si es una página web, con una pulsación si es un teléfono, con una pulsación si hay un control remoto de TV, etc.) . Mide la capacidad que tiene un elemento para dar a entender que es ahí donde hay que clicar (el call to action).

La ratio de parpadeos (si es alta indica estrés).

El diámetro de la pupila durante ciertos momentos de la navegación. La dilatación es un indicador de estrés.

¿Cómo debe ser la sala de testeo? Es importante contar con una iluminación que evite los focos de luz directos al usuario o a la pantalla, pues los reflejos interfieren en la grabación. De hecho, es preferible que haya luz artificial de tipo fluorescente y que se mantenga constante durante todas las sesiones de grabación.

La sala debe contar con el número de enchufes necesarios para poder conectar el ordenador, el ET, y otros dispositivos que se vayan a utilizar de forma paralela. En caso de necesitar conexión a internet, preferiblemente será vía cable para que sea más estable, evitando la conexión inalámbrica.

En caso de usar un ET remoto, la silla que donde se sienten los usuarios durante el test no debe tener ruedas para evitar que el usuario se desplace, ya que podría acercarse o alejarse de los sensores más de lo que el ET puede registrar. Una distancia de 60 cm es la óptima.

¿Hay que configurar el ET para cada usuario? El primer paso que se realiza en un test con eye tracker es la llamada calibración. Se trata de un proceso que apenas tarda unos segundos, y que consiste en que el usuario siga con su mirada un dibujo que se mueve en la pantalla, o en caso del modelo montado sobre gafas, unas piezas que el moderador mueve en la pared. La calibración permite que el ET registre la distancia a la que estará haciéndose la grabación y la distancia entre las pupilas del usuario.

¿Para qué contratiempos debemos estar preparados? Como en cualquier test en el que se usa tecnología, pueden darse problemas técnicos, como errores en el funcionamiento del ET, del software de grabación, del sistema operativo del ordenador o del propio PC que se esté usando, problemas de conexión a internet (en caso de ser necesario estar conectado), problemas de electricidad como un corte de energía en el edificio o en el barrio, etc. Si alguno de estos imprevistos ocurre durante la grabación, en la mayoría de los casos el test se invalidará y lamentablemente habremos perdido una grabación para nuestra muestra.

En otras ocasiones la grabación se habrá realizado aparentemente sin problemas, en cambio al revisarla podemos observar que no se grabó bien. Puede ser porque el usuario movió la silla hasta un lugar donde no alcanzó a grabarse su mirada, o se reclinó mucho hacia delante, o porque sus gafas han reflejado mal los infrarrojos, o simplemente porque hay personas en las que por motivos aun desconocidos no se graba bien su mirada con un ET. Si algún usuario no ha quedado grabado con un mínimo de completitud, será mejor desechar el test.

3. Análisis de los datos obtenidos con un eye tracker

Una vez realizados los tests comienza la etapa de análisis. Los resultados que se pueden obtener con un dispositivo de este tipo, como ya adelantábamos, pueden ser cualitativos y cuantitativos, en función del objetivo del test.

3.1. Análisis cualitativo

Cuando el objetivo del test es entender cómo navegan los usuarios, el análisis cualitativo puede ser una buena opción, ya que no precisa análisis estadístico, y por tanto con una muestra pequeña (por ejemplo de 10 usuarios) se obtiene la información necesaria. El storytelling y el liveviewing son dos técnicas de utilidad para este tipo de tests.

El storytelling consiste en narrar mediante palabras, capturas de pantalla y videos de partes de la sesión lo que ha sucedido durante los tests. La “historia” la puede contar el moderador, o bien o se le puede pedir al usuario que lo haga en voz alta mientras ve el vídeo que se ha grabado de su test; en este último caso se trata de un Restrospective Think Aloud (RTA) 1, y el usuario comenta qué pensaba mientras navegaba, cuál era su intención en cada momento, por qué decidió clicar en un lugar, qué problemas le presentó cada interfaz, etc.

La otra técnica, el liveviewing, consiste en “ver a través de los ojos del usuario”. Su objetivo es saber qué ve el usuario, nada más. No se realiza un análisis de datos, sólo se trata de entender cómo se ha producido la navegación y por qué el usuario ha tomado ciertas decisiones. La forma de llevar a cabo este tipo de análisis consiste en grabar la sesión con el ET y reproducirlo para ver las distintas interfaces con las fijaciones superpuestas, y de ahí se seleccionan los fragmentos más interesantes. También en este caso se puede realizar un RTA para que el propio usuario comente su navegación. Se trata de una técnica rápida, ya que se hace en el momento.

Las técnicas cualitativas presentadas resultan especialmente útiles para testear interfaces con contenido dinámico, por ejemplo páginas web con menús desplegables o con banners o videos en Flash, ya que por la forma en la que se recoge la información con el ET no siempre se pueden obtener datos cuantitativos de estas partes cambiantes de la interfaz. En estos casos, los videos son la mejor forma de analizar lo que ha ocurrido porque muestran las fijaciones y sacadas sobre la interfaz.

3.2. Análisis cuantitativo

Datos numéricos

Cuando hablamos de obtener resultados cuantitativos estamos hablando de números, de estadísticas, en definitiva de métricas. En el caso del ET, estas métricas vienen dadas por la propia forma de funcionamiento de este dispositivo y del software que le acompaña. El interés de obtener métricas reside en que permite comparar varias interfaces -o una misma en dos momentos distintos-.

El análisis cuantitativo implica dos dificultades en sí mismo: por un lado, requiere un número de participantes mayor del que necesita un estudio cualitativo. Si se van a realizar cálculos estadísticos, recomendamos trabajar con muestras de al menos 30 usuarios de un mismo target. En caso de querer comparar los resultados entre diversos targets, esta cifra se multiplica, ya que se necesita tener una muestra de cada uno de ellos, lo que hace que el test sea más costoso tanto en dinero como en tiempo.

Como es de esperar, para la obtención de datos cuantitativos quedan totalmente excluidos los Concurrent Think Aloud (CTA), ya que si el usuario habla mientras realiza las tareas se ralentizan sus acciones y por lo tanto se introduce un sesgo en las mediciones. Sí se puede utilizar la técnica RTA, pero supone un tiempo y un trabajo adicional importantes, por lo que su aplicación debe valorarse.

Dado que la intención es obtener resultados cuantitativos, es muy común aplicar un análisis estadístico a los datos recogidos del eye tracker. Algunos los proporciona el propio software del ET, por ejemplo el promedio de fijaciones por zona, la duración de éstas o el tiempo que transcurre hasta la primera fijación en un área. Pero si se quieren calcular otras medidas estadísticas será necesario exportar los datos a programas específicos de estadística y realizar en ellos las operaciones necesarias. El software proporciona también algunos gráficos a partir de las estadísticas mencionadas.

Mapas

Los programas de análisis de datos de ET suelen contar con una presentación en forma de mapas en los que se muestran las fijaciones de cada usuario o bien de un grupo de usuarios. Estos mapas superponen a la interfaz un gráfico que muestra el comportamiento visual de las personas grabadas con el ET.

Como ya mencionábamos, hay un problema para obtener datos de interfaces que cambian de forma dinámica, como sucede cuando se ejecuta un programa de JavaScript –por ejemplo para generar menús desplegables-, o con una presentación en Flash. Esto afecta a la obtención de mapas, dado que la captura de pantalla de la interfaz sobre la que se muestran las fijaciones no puede captar todas las variantes. Es más, en caso de que se ejecute un programa en JavaScript, sólo se guardará captura de pantalla de la página al abrirse, antes de que se ejecute el programa; y en el caso de Flash, la zona de la animación aparecerá en blanco en la captura de pantalla. Si se van a usar mapas en situaciones así, habrá que interpretarlos con la ayuda de los videos.

Hay tres tipos de mapas: de calor o heatmaps, de opacidad o gaze opacity, y de recorrido o gaze plot (figura 4).

Los mapas de calor y los de opacidad reflejan uno de estas tres datos: el número de fijaciones, la duración total de las fijaciones, o el tiempo que cada persona destina a mirar una determinada área en relación con el tiempo que dedica a toda la página. Los mapas de calor representan esta información usando distintas intensidades de color: rojo indica un valor alto, verde uno medio y amarillo uno bajo. Las zonas que no han registrado fijaciones aparecen sin superponer en ellas ningún color. Los mapas de opacidad lo hacen de una manera similar pero cubriendo con una capa negra aquellas zonas que no han recibido fijaciones, dejando entrever con cierta transparencia las que han registrado cierta intensidad de miradas, y de forma nítida las zonas que registran mayor actividad visual.

Los mapas de recorrido, a diferencia de los anteriores, muestran el movimiento de los ojos de cada usuario. Las fijaciones se muestran con círculos y las sacadas con líneas que unen las fijaciones. El tamaño del círculo es un indicador de la duración de cada fijación (a mayor tamaño mayor tiempo dedicado). Cada círculo lleva un número secuencial que permite seguir la dirección de la mirada de una fijación a la siguiente. Dado que el mapa representa las miradas de cada usuario -no el promedio de un grupo-, no se puede visualizar bien a muchos usuarios al mismo tiempo, por lo que suelen ofrecerse mapas con pocos usuarios.

Hasta aquí se ha explicado en qué consiste la tecnología eye tracking y cómo se aplica en un test de usuarios. A continuación se presenta un test de usuarios realizado para medir la usabilidad de varias interfaces de televisión.

4. Caso de estudio: eye tracking y usabilidad en TV conectada

La televisión conectada es una tecnología que utiliza dos canales para recibir información: por un lado la señal de televisión digital terrestre (TDT o DVB-t, digital video broadcasting-terrestrial) para recibir contenidos televisivos y por otro lado datos de Internet, lo que hace posible disponer en el televisor de servicios que proceden de la Red, por ejemplo televisión a la carta (video on demand, VoD), redes sociales, Youtube , navegador web, etc. Al tratarse de una tecnología reciente, no hay un consenso en el diseño de las interfaces de sus menús, así que cada fabricante y cada cadena llegan a una solución, y por ahora con poca coincidencia entre sí.

Un estudio de usabilidad realizado por la Universitat Pompeu Fabra (Mansilla y Marcos 2013; Marcos y Mansilla 2013) aplicó la tecnología de ET a cuatro modelos de televisión conectada: un televisor Sony Bravia, una caja TDT Engel que utiliza el sistema HBB-TV, hoy un estándar de TV conectada en Europa, una caja TDT Blu:sens, y una consola PlayStation3. Los cuatro dispositivos permiten acceder al servicio de televisión a la carta, y todos, salvo la consola, cuentan con señal de televisión.

En este estudio, que ahora resumimos, participaron 70 personas. En primer lugar se realizó un test de usuarios con 50 personas; en este test no se aplicó la tecnología de ET y se usó el CTA. En él se detectaron errores de usabilidad en las interfaces tanto de la pantalla como de los mandos a distancia. Los usuarios realizaron varias tareas en dos de los cuatro dispositivos: localizar la programación de una cadena, encontrar un programa en la TV a la carta, hacer una búsqueda en la web y ver un vídeo en Youtube, en caso de que el sistema dispusiera de esas funcionalidades. Un investigador del equipo moderaba la sesión de test mientras otra tomaba notas de lo sucedido en una hoja de observación (figura 3).

Los resultados del test pusieron de manifiesto problemas de usabilidad relacionados con la comprensión de las opciones de los menús de navegación, con la complejidad de los íconos de los mandos a distancia, pero también con la frustración al encontrar que estos televisores no cumplen sus expectativas: la carga es lenta, no están todas las aplicaciones que les gustaría, la navegación es críptica, etc.

Uno de los problemas más recurrentes observados en este primer test fue que los usuarios no lograban acceder fácilmente al servicio de TV a la carta. En unos casos estos canales estaban en el menú “TV” en el mismo grupo que las radios y Youtube, en otros bajo el menú “videos” y en otros bajo “internet”. Pero el dispositivo que menos eficacia presentó para esta tarea fue la caja Engel, precisamente la que usa el protocolo europeo HBB-V: para acceder a la TV a la carta es necesario que el usuario entre al canal correspondiente por TDT, y una vez ahí lea -y comprenda- un mensaje en pantalla que indica que debe pulsarse un botón del mando a distancia. La mayoría de los usuarios no finalizaron la tarea. Para esta tarea y este dispositivo, se decidió testear con 20 usuarios más, esta vez grabando las sesiones con un eye tracker, y así poder profundizar en los motivos por los que esta tarea no se completaba de forma eficaz, eficiente y satisfactoria. Se utilizó el sistema Tobii Glasses.

En este segundo test cada usuario realizó la tarea en los cuatro dispositivos. Se quería saber cuántos usuarios veían el mensaje en pantalla, y de éstos cuántos lo entendían. La muestra final se vio reducida a 14 usuarios por problemas técnicos de la grabación: los rayos infrarrojos de los mandos a distancia interferían con los rayos infrarrojos del eye tracker, lo que impedía que la sesión se grabara correctamente.

Los resultados fueron muy interesantes: solo 4 usuarios fijaron su mirada en el mensaje en la interfaz para acceder a la TV a la carta (figura 5), y de ellos sólo uno lo comprendió y pulsó la tecla del mando que se indicaba.

Es interesante decir que el análisis de los datos del ET presentó varias dificultades. Por un lado, los ficheros de vídeo eran muy pesados, lo que requirió disponer de un disco externo de gran capacidad para gestionarlos, además de más memoria RAM para el ordenador que computaba los datos, y una tarjeta gráfica dedicada que soportara esta información. Por otro lado, el marcado de los videos para obtener datos cuantitativos se tenía que realizar manualmente. Eso fue así porque se trataba de interfaces dinámicas, es decir, el acceso a la TV a la carta en este caso no se hacía desde un menú previo, sino que el mensaje en este tipo de televisor aparecía mientras se estaba viendo el programa de la cadena de la que se quiere acceder a la carta. Eso requirió de este marcado manual para el que había que visionar cada grabación, detectar en qué momento se cargaba el mensaje en pantalla y cuándo desaparecía. Considerando que los usuarios entraban en la pantalla, salían de ella para buscar en el menú, entraban de nuevo en ella, y así sucesivamente, un mismo usuario podía tener frente a sus ojos el mensaje sobre cómo ir a la TV a la carta varias veces. El marcado fue por tanto un trabajo minucioso que se tuvo que hacer para cada vídeo.

5. En resumen

El eye tracking es una tecnología de seguimiento de la mirada utilizada para conocer y analizar el comportamiento visual. Existen modelos de eye tracker que van montados sobre la cabeza de los usuarios (casco o sobre gafas) y modelos remotos, en los que el detector está en un dispositivo frente al usuario. Con esta tecnología es posible estudiar la mirada en entornos (en una tienda, en la calle, etc.) o en laboratorio (estudios de interfaces web, de televisión, etc.). Los profesionales del diseño de interfaces utilizan esta técnica para entender el comportamiento de los usuarios en sistemas interactivos como sitios web, móviles, interfaces de TV... y detectar problemas de usabilidad.

Los datos que se obtienen son cualitativos como cuantitativos. Los primeros permiten observar cómo se comporta el usuario, y el vídeo de su mirada es un buen complemento al test de usabilidad. Los cuantitativos precisan una muestra relativamente alta para poder realizar cálculos estadísticos y permiten detectar patrones de comportamiento visual.

En el caso de realizar un estudio cuantitativo, el eye tracking proporciona una gran cantidad de métricas. Las más utilizadas son: tiempo hasta la primera fijación en un área de la interfaz (mide la atracción del elemento estudiado), tiempo de permanencia en un elemento (mide el interés del elemento), y en el caso de analizar sitios web, el tiempo desde la primera fijación en un área hasta realizar un clic en ella (mide la facilidad para comprender el elemento o, según el caso, la conversión).

Los tests con eye tracking deben evitar que los participantes hablen durante la grabación (CTA), ya que pueden distraerse y cambiar su comportamiento visual. Es preferible que realicen la prueba, y después durante la entrevista final se puede reproducir el vídeo y comentar sobre él sus percepciones (RTA).

El eye tracking puede aplicarse a estudios de interfaces de distintas tecnologías, entre ellas las de televisión. En casos como este, en que la información a menudo es dinámica, la tecnología de ET requiere un pre-procesado manual de datos que resulta costoso en tiempo.

Referencias

1. El Retrospective Think Aloud se contrapone a otra técnica, el Concurrent Think Aloud (CTA), en el que el usuario habla mientras hace las tareas. El CTA no debe aplicarse en estudios con ET ya que es posible que el usuario se despiste al hablar y cambie su comportamiento natural, lo que afecta a cómo mira la página ,y por lo tanto al número de fijaciones y a la duración de estas.

Bibliografía

Barnum, C., Usability Testing Essentials: ready, set… test!, Morgan Kaufmann, 2011.

Bojko, A., Eye tracking the user experience, 2012. [Ver en línea]

Duchowski, A., Eye Tracking Methodology, Springer, 2009.

Dumas, J.; Redish, J., A practical guide to usability testing, Norwood: Ablex Publishing Corporation, 1999.

Hassan, Y.; Herrero, V., Eye Tracking en Interacción Persona-Ordenador, No solo usabilidad, 2007. [Ver en línea Hassan y Herrero]

Jacob, R.; Karn, K., “Eye Tracking in Human-Computer Interaction and Usability Research: Ready to Deliver the Promises (Section Commentary)”, en: Hyona,J., Radach, R., Deubel, H. (eds.), The Mind’s Eye: Cognitive and Applied Aspects of Eye Movement Research, pp. 573-605, Elsevier Science, 2003, [Ver en línea Jacob Eye Tracking]

Mansilla, V., Marcos, M.C., “User experience en Televisión Conectada: un estudio con usuarios”, en: El Profesional de la Información, vol. 22 (2), 2013, pp. 122-127.

Marcos, M.C., Diseño de experimentos con usuarios: lecciones aprendidas, Anuario Hipertext.net, vol. 11, 2013, [Ver en línea Marcos, M.C]

Marcos, M.C., Garcia-Gavilanes, R., Bataineh, E., Pasarin, L., “Using Eye Tracking to Identify Cultural Differences in Information Seeking Behavior”, Workshop “Many People, Many Eyes”, CHI 2013 (París), [Ver en línea Marcos, M.C Usando Eye Tracking]

Marcos, M.C., Mansilla, V., “Video on Demand: Usability challenges for Connected TV”, Workshop “Exploring and Enhancing the User Experience for TV”, CHI 2013 (París), >

Marcos, M.C., Nettleton, D., Sáez, D. (2012), Evaluation of User Search Behaviour using a Web Search Log and Log and Eye Tracking data. Proceedings of the BCS HCI 2012, People & Computers XXVI (Birmingham, UK), 262-267,

Nielsen, J., Pernice, K., Eyetracking Web Usability, New Riders Press, 2009.

Nielsen, J., Pernice, K., Técnicas de Eyetracking para Usabilidad Web, Anaya Multimedia, 2010.

Pernice, K., Nielsen, J., Eyetracking Methodology: 65 Guidelines for How to Conduct and Evaluate Usability Studies Using Eyetracking, 2009, [Ver en línea metodología de Eye Tracking]

Poole, A., Ball, L.J., “Eye Tracking in Human-Computer Interaction and Usability Research: Current Status and Future Prospects”, en: Ghaoui, C (Ed.), Encyclopedia of Human Computer Interaction, Idea Group, 2004, [Ver en línea Eye Tracking in Human-Computer Interaction]

Rello, L., Marcos, M.C., An Eye Tracking Study on Text Customization for User Performance and Preference, LA-Web 2012 (Cartagena, Colombia, Octubre 2012), 2012.

Rello, L., Pielot, M., Marcos, M.C., Carlini, R. Size Matters (Spacing not): 18 Points for a Dyslexic-friendly Wikipedia.,W4A2013, Technical May 13-15, 2013, Río de Janeiro, Brasil, Co-Located with the 22st International World Wide Web Conference .

Sauro, J., Measuring Usability, http://www.measuringusability.com

Tullis, T.; Albert, B., Measuring the user experience: collecting, analyzing, and presenting usability metrics, Morgan Kaufmann, 2008.

Capítulo 14: Accesibilidad de un recurso educativo: El caso de la Mapoteca, por Manuel Razzari

Mini biografía del autor

Licenciado en Tecnología Multimedial. Co-fundador de Con Vista Al Mar, un estudio de diseño de interfaces web pionero en el abordaje integral de la usabilidad y accesibilidad. Desde 1996 conceptualiza y desarrolla sitios web, trabajando con estándares web y accesibilidad desde 2002. Miembro activo de IxDA, la Asociación de Diseño de Interacción y co-fundador del Movimiento de Diseño Inclusivo, dedicado al apoyo y difusión de iniciativas sobre estas temáticas. Ha dictado cursos y presentado conferencias sobre accesibilidad Web, maquetado y marcado semántico.

Más información:

Ingresar al sitio web del autor

Twitter: @mrazzari

Accesibilidad de un recurso educativo: El caso de la Mapoteca

Acerca del proyecto

Este capítulo describe como caso práctico la experiencia con el proyecto “Mapoteca” de educ.ar, una aplicación web para que estudiantes de nivel medio interactúen con mapas escolares. Será distribuida en las 3,5 millones de netbooks que el gobierno argentino brinda a alumnos de escuelas secundarias públicas mediante el programa “Conectar Igualdad”.

La Mapoteca permite navegar mapas de las provincias argentinas, con las herramientas a las que estamos acostumbrados para un mapa interactivo: acercarnos y desplazarnos dentro de un visualizador, para recorrerlo.

Cada provincia tiene una decena de mapas, que incluyen no sólo los clásicos político, mudo, y físico, sino también mapas temáticos: históricos, económicos, ambientales, demográficos, turísticos.

Estos mapas se presentan como capas, que el alumno puede superponer con transparencias para “calcar” de un mapa a otro. Por ejemplo puedo superponer el mapa climático sobre el económico, y ver como la lluvia en una región ha influido sobre su producción agrícola.

El visor de mapas interactivos incluye una serie de herramientas básicas de dibujo: lápiz, texto, rectángulos y círculos, polígonos, y una paleta de colores. Esto permite al docente dar tareas de dibujo en el mapa, como trazar los ríos sobre un mapa político, o etiquetar las ciudades en un mapa mudo. Estos mapas intervenidos pueden descargarse como imagen, para entregar por e-mail, o imprimirse.

Se trata de más de 300 mapas que se complementan con 200 actividades didácticas específicas a cada provincia y temática, con ejercicios de investigación en línea y pautas para el trabajo con los mapas. Las actividades se relacionan entre si por etiquetas y meta-datos.

Ilustración 1 / Un primer prototipo del visualizador de mapas, en su etapa de wireframe.

El equipo

La creación de esta aplicación estuvo a cargo de “Con Vista Al Mar 1”, un estudio de diseño y desarrollo de interfaces web que trabaja con estándares web, usabilidad y accesibilidad.

El equipo del proyecto podría considerarse pequeño: un programador front-end, un programador back-end, un diseñador, y un líder de proyecto. Cabe destacar que no hay un rol específico de especialista o consultor en usabilidad o accesibilidad. Son roles que permean la labor de cada miembro del equipo, es decir, cada uno debe conocer e incorporar las técnicas que informarán transversalmente las decisiones en su trabajo cotidiano 2.

El proyecto fue encomendado por educ.ar 3, el portal educativo del Estado argentino, destinado a ejecutar políticas definidas por el Ministerio de Educación en materia de integración de las TIC en el sistema educativo.

El equipo de Con Vista Al Mar se complementó con el equipo dentro de educ.ar coordinando y supervisando el proyecto, y con un equipo externo de cartógrafos y contenidistas especializados en la materia 4.

Límites de un estudio web

La mayoría de los proyectos “para clientes” llevados a cabo por estudios o agencias se encuentra con límites prácticos a la hora de incorporar usabilidad y accesibilidad en un proceso de diseño o desarrollo.

Los tiempos asignados siempre parecen cortos. Los costos son estimados por hora de trabajo, con muchos clientes cuestionando cada hora del presupuesto en el afán de bajar costos. Se genera la sensación de que apenas hay tiempo para cumplir con los requerimientos, es decir “que funcione”, que no haya errores visibles. No hay tiempo para el diferencial de calidad que genera el diseño centrado en el usuario. A diferencia de lo que sucede en los grandes sitios o “punto com”, el retorno sobre la inversión (ROI) no es tenido en cuenta, por lo que resulta difícil presentar una propuesta de valor enfocada en el largo plazo 5.

Del mismo modo, no siempre es posible un control “punta a punta”. Hay actores externos al estudio que influirán en lo que termina publicado en el sitio. Cuando hacemos un sistema de gestión de contenido, no podemos asegurar que van a escribir texto alternativo apropiado, o que cargarán imágenes con suficiente contraste, o que no pondrán media docena de enlaces “clic aquí” en una misma página.

El desafío entonces es encontrar formas de hacer más en menos tiempo, mediante lineamientos, mejores prácticas y componentes re-utilizables; que nos permitan trabajar con una base sólida y nos liberen el poco tiempo restante para optimizar los detalles. Esto es, una parte común a todos los proyectos, que podemos llamar “de base”, y cuestiones específicas que deberán evaluarse y ponerse a prueba en cada proyecto.

Un marco de trabajo para accesibilidad cotidiana

Las mejores prácticas en maquetado y programación front-end son el pilar de la accesibilidad web. Hoy en día hemos dejado atrás la diagramación con tablas, y mediante propiedades de CSS como gradientes, bordes redondeados, sombras, y fuentes personalizadas, se vuelve prácticamente innecesario el uso de imágenes para representar el diseño. El uso de marcado semántico, técnicas de JavaScript no invasivo y mejora progresiva, es un requerimiento para empezar a trabajar la accesibilidad de un proyecto. Sin ésto, el resto de las mejoras que realicemos tendrá poco sentido.

La selección apropiada de un gestor de contenido es fundamental a la construcción de una web accesible. En principio, debe tener un editor de texto enriquecido (también conocido como “RTE” o editor visual) que genere HTML válido, anidando apropiadamente los elementos, evitando etiquetas deprecadas o espacios de nombres XML no estándar (frecuentes al copiar y pegar desde procesadores de texto).

Pero el editor no sólo debe generar HTML sintácticamente válido: debe proveer ayudas para el marcado semántico. Es importante no darle a los autores herramientas que les permitan tomar decisiones sobre el formato visual del texto. Es decir, no pueden elegir fuentes, tamaños y colores. En lugar de ésto, el editor de texto les permite elegir niveles de encabezados, u otras etiquetas con apropiado valor semántico como citas, listas, y destacados. Y provee cuadros de diálogo para definir texto alternativo en las imágenes y meta-datos para tablas.

El programador debe evitar patrones difíciles de mantener, como la generación de HTML mediante concatenación de cadenas (strings) en el back-end o en JavaScript, o el uso de “controles” que generen grandes fragmentos de HTML no modificables. En su lugar, debe trabajar con plantillas que separen la lógica del back-end del HTML, de forma tal que el maquetador pueda trabajar con su parte del código directamente. De lo contrario, es difícil aplicar y sostener en el tiempo las mejoras de accesibilidad.

Componentes accesibles

Tan importante como la elección de componentes adecuados en el back-end, resulta la selección de fragmentos de código, plugins y librerías que usemos en el front-end.

Por ejemplo al elegir un plugin de jQuery, en general hay muchas alternativas para resolver una misma funcionalidad, y la búsqueda se centra en la que más se parezca al diseño visual, o que sea más completa de acuerdo al requerimiento, o esté mejor documentada, o simplemente sea conocida y popular. Si nuestro proyecto prioriza la accesibilidad web, entonces éste debe ser un factor clave a tener en cuenta, evaluándolo al mismo nivel que otros. ¿Qué llevará más tiempo, hacer accesible un menú desplegable bonito, o hacer bonito un menú accesible?

A veces nos apresuramos a descargar un plugin y utilizarlo, cuando en realidad resulta sencillo hacer una serie de pruebas básicas mediante los ejemplos provistos por el mismo. Estas pruebas incluyen probarlo en todos nuestros navegadores objetivo, incluyendo lector de pantalla; verificar que podemos usarlo íntegramente con el teclado (teclas tabulación, intro, espacio, atajos con letras); hacer zoom del texto para saber rápidamente si es escalable; y controlar que si hay enlaces, éstos apunten a una URL real (y no a un onclick o “javascript:...”). Por supuesto, mejor aún si dice cumplir con las recomendaciones WCAG o WAI-ARIA.

En el caso de aplicaciones web complejas, hay librerías que tienen una base de accesibilidad muy sólida: jQuery UI, Dojo Toolkit, o YUI de Yahoo, entre otras. Una vez más, si la accesibilidad es una prioridad o un requerimiento, el uso de éstas nos ayudará a no “empezar de cero”, y poder enfocar nuestro limitado tiempo en los detalles de accesibilidad específicos a nuestra problemática.

Definición de problemas y prioridades

Una vez que la aplicación o página web está mínimamente funcional, y consideramos que hemos hecho lo mejor posible en cuanto a una base sólida, utilizando mejores prácticas, marcado semántico y componentes accesibles, es necesario saber dónde estamos parados y cómo seguir.

Para este proyecto contamos con tres instancias de pruebas con usuarios, en sucesivas etapas: wireframe, versión alpha y beta de la aplicación. Se probó con personas representativas del usuario final, es decir alumnos de cuarto y quinto año de colegios secundarios estatales de Capital y Gran Buenos Aires.

Sin embargo, no tuvimos la posibilidad de hacer pruebas con alumnos con discapacidad. Es preciso entonces valernos de otras técnicas que nos permitan identificar los problemas de accesibilidad pendientes, detalles que se nos escaparon e, igualmente importante, poder definir con qué prioridad debe solucionarse, o no, cada problema.

Como primera medida utilizamos eXaminator 6, que nos apunta rápidamente los errores y omisiones más groseros. Luego utilizamos otras herramientas como T.A.W. 7, AChecker 8, y la eficaz barra de Herramientas de Accesibilidad 9 de Firefox para hacer una revisión más exhaustiva. Al haber realizado el maquetado con marcado semántico, verificar directamente contra pautas WCAG 2.0 de Nivel AA resulta un objetivo alcanzable. Por supuesto, si encontramos problemas de Nivel A, éstos tienen prioridad.

Pero así como los validadores de HTML o CSS del W3C no pueden decirnos si la página “se ve” correctamente, y entonces el maquetador verifica visualmente las páginas en diversos navegadores y dispositivos, de igual forma debemos sumar un programa lector de pantalla a esa matriz de verificación multi-navegador, ya que los validadores de accesibilidad no podrán saber como realmente “se escucha” la página.

Para esta tarea elegimos habitualmente la combinación de Firefox y el lector NVDA 10, que combinan la gran disponibilidad de herramientas de depuración de errores del primero, con la simplicidad de instalación y gratuidad del segundo. Si bien la combinación de navegador y lector de pantalla más utilizada en el mundo es, por un amplio margen, Internet Explorer y JAWS, el uso de NVDA nos permitirá detectar las principales barreras que presenta nuestra página a las ayudas técnicas. En el caso específico de este proyecto se suma el dato, no menor, de que NVDA es el lector de pantalla que se instala por defecto en las netbooks de Conectar Igualdad.

Una última brújula para definir prioridades es la encuesta anual que hace la organización WebAIM 11 a usuarios de lectores de pantalla, entre los que se destacaron en 2012: Flash, Captcha, enlaces sin sentido e imágenes sin texto alternativo como los ítems más problemáticos, seguidos de los cambios inesperados de pantalla, formularios complejos, mala navegación por teclado, falta de encabezados (h1, h2, ...) y el exceso de enlaces y navegación.

Como aprendimos del proceso de diseño centrado en el usuario, ninguna de estas técnicas reemplazará las pruebas con personas reales, y nos ponen más bien del lado del cuestionado “diseñador genio” que imagina en base a su gran experiencia y conocimiento, sin levantarse de su escritorio a conocer a los usuarios 12. Pero en el campo de la accesibilidad resultan sin lugar a dudas fundamentales al permitirnos hacer mucho, con poco, efectivamente mejorando el día a día de las personas que utilizarán el resultado de nuestro trabajo.

Accesibilidad en la Mapoteca

A continuación describiremos algunos problemas puntuales que surgieron en este proyecto en relación a los mapas, y a la accesibilidad en proyectos educativos en general, de cómo los solucionamos, pero también cómo fallamos en anticipar algunos inconvenientes, o de cómo algunas soluciones estaban fuera del alcance del proyecto.

Imágenes de texto

Tradicionalmente la accesibilidad de los mapas en la Web se ha relacionado con la posibilidad de navegarlos utilizando el teclado, es decir con los cursores para desplazarnos, y las teclas más/menos para acercarnos o alejarnos. Esto cubre un área de la accesibilidad para nada menor, ya que da acceso a los usuarios con movilidad reducida que no usan el mouse, sino que sólo el teclado, ya sea físico, en pantalla, o pulsadores. También permite a los usuarios con visión reducida ampliar el texto para poder leerlo.

Pero como dice el cuento, “el emperador va desnudo”. Todos los mapas en la web funcionan mediante un servidor de mapas que convierte los datos geo-espaciales a un caché de mosaicos que son enviados al cliente visualizador 13. Esto es lo que vemos en cualquier mapa en línea: que carga por partes, “en cuadraditos”. Cada uno de estos cuadraditos es una imagen JPG, y aquí estamos dejando de lado uno de los principios más caros a la accesibilidad, que es el de las alternativas textuales.

Toda el área del mapa es, para el lector de pantalla, un agujero negro. No hay forma de que el navegador pueda transmitirle al lector de pantalla los nombres de ciudades y ríos que estamos viendo, simplemente porque el mapa no es más que una gran imagen con texto.

Una de las personas que más sabe de accesibilidad Web en el mundo de habla hispana me dio tranquilidad respecto a esta clara limitación en nuestro proyecto: “la accesibilidad no pide milagros”, me dijo 14. Es bueno saber hoy, sin embargo, y sin temor a ser grandilocuentes, que el milagro existe, aún si un poco lejano a nuestra realidad. Me refiero a la aplicación de mapas presentada por Apple en la versión 6 de su iOS. En lugar de mosaicos de imágenes, ésta usa datos vectoriales que pueden ser leídos por VoiceOver, el lector de pantalla incorporado al teléfono. El usuario puede entonces tocar el mapa, y le serán leídos los nombres de calles y ciudades mientras desplaza el dedo, en lo que representa un salto sin precedentes en la accesibilidad de información cartográfica.

Mapas y ceguera al color

No todos los factores se tienen en cuenta con la debida anticipación, y este fue el caso del uso del color en algunos mapas. El ambiental de la Argentina, por ejemplo, está dividido en casi 20 climas, y por lo tanto colores. Resulta frecuente que colores contiguos en el mapa se vean como un mismo color por personas con algún tipo de daltonismo o ceguera al color. Se suma a esto la dificultad de vincular visualmente la referencia al pie del mapa, indicando qué representa cada color.

Si tenemos en cuenta que el daltonismo afecta a más de uno de cada diez hombres, este problema no resulta nada trivial. Por ejemplo, alguien con dicromacia roja (o protanopia), verá estas 20 regiones distintas del país, como apenas variantes de azules y marrones, perdiendo por completo la utilidad del mapa y de la referencia.

Este problema resultó un claro ejemplo donde, si no se tiene en cuenta la accesibilidad desde el comienzo y por todos los actores involucrados en un proyecto, resulta demasiado costoso volver atrás una vez que el inconveniente fue detectado.

Las alternativas textuales y los contenidistas

Antes de dar comienzo a la carga de contenidos, se capacitó a los contenidistas en el manejo de imágenes dentro de WordPress, el sistema de gestión de contenidos que elegimos. No sólo en su diagramación y posicionamiento, sino que se hizo especial hincapié en la importancia de asignarles un texto alternativo, con qué criterio hacerlo según el contexto, y la diferencia entre éste, el epígrafe, y el título de la imagen.

A pesar de ésta capacitación, se nos presentó aquí el clásico problema de “texto invisible” que genera el atributo “alt” de las imágenes, a saber: ausencia total de texto alternativo, texto con el nombre del archivo de imagen, e incluso errores de tipeo y ortografía. Al no ser visible éste texto a simple vista, resulta trabajoso integrarlo en el proceso de corrección por un editor, y de auto-corrección por parte del mismo autor.

Tomó asimismo mucho tiempo de revisión y diálogo el aclarar las diferencias entre el texto alternativo, que describe la imagen, y los epígrafes, que se complementan con la imagen y le dan sentido.

Una vez que empezamos a recibir los contenidos, nos dimos cuenta de algo imprevisto para nosotros, que no habíamos contemplado en la capacitación. Al tratarse de materiales educativos, muchas de las imágenes caen dentro de la excepción que proveen las Pautas de Accesibilidad para imágenes cuyo contenido es una prueba o ejercicio para el usuario 15, que dejarían de ser válidos como evaluación si los describimos. Si una consigna es “observen las siguientes imágenes de paisajes áridos e identifiquen el factor erosivo”, es necesario ser muy cuidadosos para no dar la respuesta en el texto alternativo que proveemos.

La conclusión aquí es que, si bien es importante proveer un sistema que posibilite o incluso requiera la carga de texto alternativo, es igual de crítico capacitar a las personas que estarán haciendo esa carga en su uso apropiado, e incorporar a este texto invisible como parte integral del proceso de corrección de los contenidos.

Accesibilidad y usabilidad

Si consideramos la accesibilidad como un área de la usabilidad, con objetivos de “efectividad, eficiencia, y satisfacción” cuyos usuarios específicos son los discapacitados, y cuyo contexto específico son las ayudas técnicas 16, no resulta difícil observar que muchas de las Pautas de accesibilidad están muy cercanas a las recomendaciones de usabilidad. Especialmente en cuanto a legibilidad, predictibilidad, consistencia, y prevención de errores.

En este proyecto no hicimos pruebas con personas con discapacidad, pero si hicimos pruebas de usabilidad con nuestros usuarios objetivo, alumnos de colegios secundarios. Estas pruebas arrojaron algunos resultados por si mismos interesantes, desde el punto de vista de la educación mediante plataformas web, y que además resultan próximos a las problemáticas de la accesibilidad.

La primer sorpresa con que nos encontramos es que estábamos probando una interfaz de usuario, pero en realidad muchos alumnos tenían falencias básicas en geografía. Queríamos probar si se entendía como funcionaba el superponer un mapa físico con uno político, y el problema no fue de diseño, sino que desconocían la diferencia misma entre un mapa físico y uno político. Otros factores similares afectaron las pruebas, como el desconocimiento del Río de la Plata o la diferencia entre una bahía y un río.

Algunos elementos estándar les resultaron extraños, no estaban familiarizados con el comportamiento de las casillas de verificación (checkboxes) por lo que necesitamos simplificar la interacción a botones grandes de selección simple, dejando la selección múltiple para “uso avanzado”. Tampoco resultaron intuíbles los botones para expandir y colapsar información. Sí les resultó natural, en cambio, explorar rápidamente la página completa, de arriba hacia abajo y de nuevo hacia arriba, usando la barra de desplazamiento (scroll bar) del navegador.

Se sumó a esto un imprevisto relacionado con el dispositivo de entrada. Para dibujar sobre los mapas, cuando probábamos en la oficina mientras desarrollábamos, usábamos el mouse con absoluta ingenuidad, satisfechos con la posibilidad de trazar el curso de un río, resaltar una región con un polígono irregular. Al llegar a las pruebas con usuarios, el problema fue evidente. Los alumnos usaban el trackpad de las netbooks. Al no tener mouse, muchas acciones que resultan triviales con éste, se vuelven un pequeño desafío motriz: arrastrar y soltar, o dibujar, con un dedo deslizándose sobre el trackpad mientras la otra mano mantiene el clic presionado. En este caso tuvimos que resignarnos, ya que la solución al problema requeriría volver muy atrás en el proceso de desarrollo.

En definitiva, si bien no probábamos específicamente accesibilidad, la información y el manejo de la interfaz de usuario se hizo más comprensible, que es aquí uno de los principios más directamente influenciados por la usabilidad como disciplina.

Conclusión

Mostramos aquí que resulta posible incorporar estas prácticas sin desbarrancar el presupuesto, pero no resulta trivial: partimos de una base, de aprendizajes previos, de decisiones tomadas sobre formas de hacer las cosas. En definitiva ganar experiencia, que podremos obtener precisamente al hacer de la usabilidad y la accesibilidad parte de un proceso iterativo, cotidiano y orgánico; que no opere en forma aislada sino que se integre y fluya junto al trabajo de redactores, diseñadores y programadores.

Aprendimos que es elemental definir desde un primer momento cuales son los roles involucrados en el proyecto, y asegurarse de que cada uno conozca las pautas sobre accesibilidad que competen a su rol. Esto tiene dos ventajas. En principio, nos permite realizar “accesibilidad preventiva”, ya que identificado el problema de antemano, en general su solución será de muy bajo coste, porque pueden buscarse alternativas, no hace falta rehacer lo que todavía no está hecho. En segundo lugar, la separación por roles ayuda a dividir la tarea y que no sea algo inabarcable, a la vez que obliga a cada uno a asumir responsabilidad por la parte que le corresponde, sin depender del “evangelizador” o experto en accesibilidad que hay en el equipo.

Vimos la importancia de identificar y generar componentes accesibles que podamos reutilizar en sucesivos proyectos, no sólo en los planos de diseño y desarrollo, sino también en lo que respecta a herramientas de capacitación de los “invitados” a nuestro proyecto, desde contenidistas contratados hasta líderes de proyecto en el equipo del cliente. Una vez elegido el gestor de contenido podemos, por ejemplo, hacer un breve video explicando sus características de autoría accesible.

Entendimos que las Pautas de Accesibilidad y en particular el documento “Comprender las Pautas 17” nos dan una perspectiva exhaustiva sobre las barreras que ponemos a las ayudas técnicas, perspectiva que nos sería imposible adquirir por medio de nuestra propia experiencia, y que nos permite dar accesibilidad a casos de uso que no tenemos la capacidad de verificar por cuenta propia. Pero este mismo carácter exhaustivo ha resultado históricamente intimidante para la comunidad de diseño y desarrollo, que se vale de herramientas de validación como acceso directo a la identificación de barreras más evidentes, a veces sin comprender del todo el problema subyacente.

En este sentido la adopción del lector de pantalla como un agente de usuario más en la matriz de navegadores que soportamos y verificamos nos permite dar el siguiente paso, al pasar de lo que es correcto en teoría, a lo empíricamente verificado. Esto sin olvidar que nuestras pruebas de laboratorio, aunque bienintencionadas, complementan pero no reemplazan el probar con usuarios reales, que nunca han visto nuestra aplicación, que no están familiarizados con la estructura de la página. 18

A nivel organizacional, en un equipo informado por múltiples disciplinas y múltiples motivaciones de sus miembros, donde los valores más preciados para unos estarán en franca contradicción con las necesidades de las personas con discapacidad, resulta imperativo que se priorice la accesibilidad a nivel gerencia, en las contrataciones, y en la gestión de proyectos; ya que sólo con prioridades claras podrán despejarse conflictos de intereses, a favor de individuos y no de estadísticas, a favor de la inclusión.

Referencias

1. Web de Con Vista Al Mar, http://convistaalmar.com.ar .

2. Veáse al respecto: Denis Boudreau, Desglose de responsabilidades sobre la accesibilidad por roles, [borrador del W3C WAI, en inglés, consultado en mayo de 2013].

3. Web de educ.ar, http://educ.ar.

4. El proyecto Mapoteca fue diseñado y desarrollado en Con Vista Al Mar por Juan Allona, José Allona, Camilo Kawerín y Manuel Razzari, en conjunto con el equipo de Educ.ar coordinando y supervisando el proyecto, y un equipo externo de cartógrafos y contenidistas, según consta en http://mapoteca.educ.ar/creditos. El esfuerzo y la intensidad creativa de todos ellos hizo posible este proyecto, del que la accesibilidad es solo un fragmento.

5. Veáse respecto al ROI del DCU el clásico de Aaron Marcus, Return on Investment for Usable User-Interface Design: Examples and Statistics, [Ver en línea ROI y DCU] [en inglés, formato PDF, consultado en mayo de 2013]

6. El eXaminator es un servicio de evaluación de accesibilidad desarrollado por el argentino Carlos Benavidez. Puede usarse en forma gratuita en http://examinator.ws para un informe rápido en relación a WCAG 2.0.

7. Test de Accesibilidad Web de la Fundación CTIC, España, en http://tawdis.net .

8. Servicio de Evaluación de Accesibilidad del Centro de Investigación en Diseño Inclusivo de la Universidad de OCAD, Canadá, en http://achecker.ca.

9. Barra de Herramientas de Accesibilidad, extensión de Firefox, del Centro de Tecnologías de la Información y Accesibilidad Web de la Universidad de Illinois, Estados Unidos, en [Ver en línea barra de herramientas] .

10. NVDA es un lector de pantallas gratuito y de código abierto para Windows, en http://nvda-project.org.

11. WebAIM es una organización del Centro para Personas con Discapacidad de la Universidad Estatal de Utah, puede accederse a los resultados de su encuesta anual en http://goo.gl/DXvVq .

12. Veáse Jakob Nielsen, The Myth of the Genius Designer, 2007, [Ver "The Myth of the Genius Designer"] en contraposición a Cennydd Bowles, Looking Beyond User-Centered Design, 2013,

13. Dos populares clientes de mapas son OpenLayers (usado en Mapoteca por su espectro de funcionalidades y su soporte multi-navegador) en http://openlayers.org y Leaflet (de más sencillo uso e integración) en http://leafletjs.com .

14. Comunicación personal con Emmanuelle Gutiérrez y Restrepo, coordinadora del Seminario SIDAR, durante la 5ta. Jornada “Por una Web Sin Barreras para las Personas con Discapacidad”, junio de 2012, UTN Buenos Aires.

15. W3C, Pautas de Accesibilidad para el Contenido Web 2.0, Pauta 1.1.

16. Parafraseando la definición de la norma ISO 9241-11 que aconseja sobre usabilidad.

17. Ver bibliografía recomendada, W3C Consorcio World Wide Web, Comprender las Pautas de Accesibilidad para el Contenido Web 2.0.

18. Veáse Yusef Hassan Montero y Sergio Ortega Santamaría, Informe APEI sobre usabilidad, http://nosolousabilidad.com/manual que alerta sobre la dificultad en comprender el modelo mental del usuario cuanto más está involucrado el diseñador con el producto.

Bibliografía

Jim Thatcher, et al., Web Accessibility: Web Standards and Regulatory Compliance, Estados Unidos, Friends of Ed, 2006. En inglés. En este libro participan los principales autores y pioneros de la accesibilidad Web, es una excelente introducción a la problemática, aunque necesita una actualización.

W3C Consorcio World Wide Web, Comprender las Pautas de Accesibilidad para el Contenido Web 2.0, [en línea], en su traducción al español por Sofía Benavidez para SIDAR.org http://goo.gl/1aD7o – o en su versión oficial más reciente en inglés http://goo.gl/qXJ22 [consultados en mayo de 2013]. Nos aclara casi cualquier duda que podamos tener sobre la teoría o práctica de la accesibilidad Web.

Gez Lemon, pionero de la accesibilidad web y miembro de Paciello Group, ha escrito una completa introducción a la especificación WAI-ARIA que se encuentra disponible en español en [Ver WAI-ARIA en español] [consultado en mayo de 2013].

Weblogs recomendados

http://accesibilidadenlaweb.blogspot.com - Sergio Luján Mora es Profesor e investigador en la Universidad de Alicante. Tiene una introducción al tema .

http://olgacarreras.blogspot.com - Olga Carreras es consultora, referente para la comunidad de habla hispana. Publica artículos propios; y resume y traduce artículos, papers e informes de actualidad internacional.

http://blog.paciellogroup.com - Escriben, entre otros, Mike Paciello, uno de los fundadores de la WAI, y Steve Faulkner, uno de los editores de la especificación HTML dentro del W3C. En inglés.

http://deque.com/blog - Deque Systems es una de las grandes consultoras en accesibilidad, desarrolladores de herramientas profesionales y gratuitas de validación. En inglés.

http://www.marcozehe.de - Marco Zehe es un desarrollador que trabaja para Mozilla en Accesibilidad. Previamente trabajó para la empresa que desarrolla JAWS, el popular lector de pantalla. En inglés.

Capítulo 15: Elaboración de una Normativa de Usabilidad y Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires, por Verónica Traynor

Mini biografía del autor

Diseñadora web con orientación en comunicación visual, a su vez estudió Gestión de Recursos Humanos y Marketing. Durante el año 2009 llegó a ser responsable del área de Usabilidad y Accesibilidad Web del Gobierno de la Ciudad de Buenos Aires (GCBA), donde colaboró en la normativa que explaya en este capítulo. Luego continuó especializándose en usabilidad de e-commerce y sitios bancarios. Es Profesora Invitada DIEAU: Especialización en Diseño de Interacción con estándares de accesibilidad y usabilidad en la Universidad Tecnológica Nacional. Actualmente trabaja como Consultora Independiente de Usabilidad y Experiencia de Usuario para clientes en Estados Unidos, Europa y Latinoamérica.

Más información:

Ingresar al sitio web del autor

Ingresar al LinkedIn de la autora

Twitter: @verotraynor

Elaboración de una Normativa de Usabilidad y Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires

Introducción: El objetivo y el contexto tecnológico

En el año 2009 como responsable de la incipiente área de Usabilidad y Accesibilidad Web del Gobierno de la Ciudad de Buenos Aires (GCBA), mi labor era validar los sitios que pronto serían publicados. La mayor parte era diseñada y desarrollada por empresas externas y al momento de hacer las evaluaciones, los proyectos se encontraban en su fase de cierre.

En esos años, las empresas de software contratadas carecían de conocimientos sobre usabilidad y accesibilidad web.

Sus equipos estaban, en su mayoría, conformados por ingenieros ajenos desde su formación a cuestiones vinculadas con relaciones humanas y, por diseñadores gráficos nuevos en el mundo de Internet, orientados a cuestiones estéticas o a paradigmas del mundo no Web. Sus procesos no contaban con pruebas con usuarios, sus decisiones de interacción no se basaban en investigaciones empíricas y su enfoque no era la construcción de un diálogo humano-computadora.

La arquitectura de la información (AI) de los sitios se formulaba de acuerdo a los modelos mentales de la propia gente del proyecto; por lo tanto la psicología considerada no era la de las personas que iban a interactuar, sino la de sus propios fabricantes.

Ejemplo de un sitio para mamás, cuyo el mensaje de ayuda dice: “Debes tener un bebé como mínimo”. ¿Se encuentra adaptado a la comunicación necesaria para una madre?

El usuario - en caso de ser nombrado - funcionaba como un ser justificador imaginario. Los miembros del equipo solían asegurar en base a presuposiciones, de qué modo iría a razonar el ser humano ajeno al proyecto y cómo sería su interacción con la interfaz. Nos encontrábamos frente a mecanismos proyectivos, autorreferenciales y arbitrarios. El paradigma implicaba que eran las personas quienes debían esforzarse para comprender y aprender la lógica impuesta por la interfaz con el fin de intentar lograr sus objetivos.

La usabilidad como requisito

En ese entonces, la usabilidad de las interfaces no era planteada como requisito para los proveedores desde el inicio de los proyectos. Por lo tanto, a la hora de hacer la evaluación, su legítimo cuestionamiento era: “¿Acaso el usuario no debe hacer el esfuerzo de aprender? ¿Cómo se mide la usabilidad? ¿Dónde se encuentra definido?”.

Ejemplo de una ventana que les permite a los usuarios subir imágenes. Las personas deben comprender que el botón “Close this window” es el que les permitirá continuar con su navegación.

Esto creó la oportunidad y el desafío de escribir una normativa que resultara de guía para los desarrolladores y los acompañe durante el proceso de trabajo; en lugar de aparecer de un modo sorpresivo e intimidante en el momento de intento de cierre.

Comprensión de las características de los usuarios: escenarios humanos

Al plantear una interfaz, el primer interrogante a definir es quiénes serán los sujetos que necesitarán entablar un vínculo con la máquina. Esto implica la necesidad de comenzar cada proyecto con una etapa de investigación que le explique y le cuente al equipo interdisciplinario, en qué escenarios se encontrarán las distintas personas al momento de necesitar o desear interactuar con la interfaz; cuáles son sus características físicas, culturales, tecnológicas y sociales; y con qué expectativas tanto funcionales como emocionales se acercarán al producto. Nos referimos entonces a acercarnos a los usuarios para comprender sus problemáticas y sus escenas reales de uso. Se trata de una etapa para comprender al otro interlocutor, con el fin de humanizar la lógica del sistema y humanizar el diálogo.

El nuevo foco de este paradigma

Para diseñar interfaces centradas en los usuarios, es necesario replantear el proceso de desarrollo en cascada para convertirlo en algo más semejante a un espiral.

En la forma tradicional, las interfaces se analizaban y diseñaban en abstracto, desenfocadas de las necesidades para el aprendizaje de las personas; y se desarrollaban para que los sujetos se adapten.

En la filosofía del Diseño Centrado en el Usuario (DCU) el paradigma cambia. La construcción de los flujos y las interfaces pasa a ser un momento lúdico donde la metodología de trabajo incluye pruebas con usuarios y el eje pasa a ser el ser humano con sus necesidades de percepción, comprensión, operabilidad y aprendizaje.

Valentín Muro, quien se refiere a la ética del juego, nos dice: “Si nos consideramos ‘jugadores’ y no meros ‘trabajadores’ ampliamos inmediatamente la idea que tenemos de nosotros mismos y de lo que somos capaces de hacer. Cuando jugamos existe un desafío, algo que se resiste, que nos invita a indagar, por eso el juego es una de las mejores formas de aprender. Se comprende jugando”.

El objetivo de los creadores de interfaces al construir una interacción, es aprender sobre el ser humano. Y desde mi percepción: este aprendizaje se logra jugando. Por lo tanto, las decisiones dejan de basarse en cuestiones accidentales, verticalistas o arbitrarias. Todo gira en torno a la observación empírica y metodológica de personas aprendiendo e interactuando. Esta forma de trabajo evolutiva y en espiral les permite a los integrantes del equipo avanzar y aumentar la calidad de sus bocetos de un modo más certero; según los modelos mentales ya no de ellos mismos, sino de los usuarios finales.

En conclusión, en este paradigma el foco es el vínculo que se genera entre las personas y las interfaces; la metodología es la observación empírica de esa dialéctica y la forma de trabajar es evolutiva y lúdica.

La observación como metodología

Resulta importante señalar que en nuestro proceso de investigación, necesitamos distinguir entre las opiniones de los usuarios y la operabilidad observada. Existe una diferencia significativa entre lo que les sucede a los usuarios, lo que interpretan sobre lo ocurrido y lo que opinan que les sucedió. El análisis del discurso sirve para medir la percepción, pero no nos será suficientemente útil para comprender la raíz del problema del vínculo, del cual los usuarios pueden llegar a no ser conscientes. Valentín Muro, en la misma plática, habla sobre desarmar las cosas para comprenderlas:

“Hablo de entender como cuando desarmábamos los juguetes para ver cómo funcionaban. Creo que la importancia de entender cómo funcionan las cosas está en el poder que nos da para cambiar cómo funcionan”.

Cuando trabajamos en diseño de interacción es lo mismo: desarmamos con nuestra observación los mecanismos del diálogo que se está generando, para poder adaptar nuestra máquina a lo humano. Esto nos permitirá comprender en profundidad la dialéctica generada, hacer modificaciones en las interfaces y volver a hacer pruebas para validar la efectividad del cambio. Se trata de un proceso cíclico, ágil y dinámico basado en la observación de los seres humanos interactuando.

Los colores como parte del diálogo

Una vez definida la arquitectura de información y los mecanismos de navegación, se deberá definir la estética. En este paradigma, la razón de ser de los colores experimenta una metamorfosis de su función tradicional, ubicándose al servicio de la señalética.

Me remito a dos conceptos del signo lingüístico.

La arbitrariedad: el vínculo que une el significado con el significante es arbitrario.

La inmutabilidad: el signo precisa quedar instalado y no ser mutante.

Los elementos interactivos pasan a ser signos lingüísticos que precisan ser aprendidos; por lo tanto son arbitrarios, pero necesitan consistencia para generar estabilidad, orientación y diálogo.

En una interfaz, la función fundamental del color es la colaboración en el aprendizaje y la comprensión del ser humano. Por lo tanto, dejamos de hablar de pintar un cuadro y pasamos a construir un semáforo. Bello, pero fundamentalmente claro.

Aquí, sumado a la usabilidad, incorporamos los Lineamientos Internacionales de Accesibilidad Web -que se explican debajo- como referencia y respaldo: La accesibilidad como un derecho humano.

Primera versión de la Normativa de Usabilidad y Accesibilidad Web

Aquí detallo la normativa de Usabilidad y Accesibilidad Web publicada el año 2010 junto con su breve guía para desarrolladores. La misma es digna de ser leída, pero con una necesidad suprema de ser actualizada. Los lineamientos de accesibilidad y usabilidad web son:

1. Ámbito de Aplicación

Las disposiciones a las cuales se refiere la presente resolución son de obligatorio cumplimiento para todos los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

2. Objetivos

Los objetivos de la presente resolución son:

2.1. Garantizar un acceso equitativo a la información.

2.2. Contribuir con la construcción de un Gobierno que preste mejores servicios a los ciudadanos, facilitando a los usuarios el alcance de objetivos con eficacia y satisfacción a través de la optimización de las tecnologías de información y comunicación.

3. Definiciones de usabilidad y accesibilidad web

Un sitio web es accesible cuando sus contenidos son perceptibles, comprensibles y operables para todo tipo de usuarios, independientemente de sus capacidades, tipo y dispositivo de acceso a internet, sistema operativo y/o programas utilizados.

La usabilidad es una medida empírica que califica qué tan fácil, rápido y agradable es un sitio web para un cierto tipo de usuario, evaluando determinado tareas y contextos de uso.

4. Definición de políticas y estándares de accesibilidad

El Consorcio W3, organismo internacional encargado de crear y supervisar los estándares en la Web, ha publicado una serie de pautas denominadas Directrices1 de Accesibilidad del Contenido Web 2.0. (Versión en inglés Web Content [Ver en línea Accessibility Guidelines WCAG-2.0] . Traducción recomendada (aunque no oficial en español), las cuales son aceptadas internacionalmente.

Las Pautas se organizan en cuatro principios básicos que constituyen su base filosófica (perceptible, operable, comprensible y compatible). Las mismas se encuentran clasificadas por niveles de conformidad (A, AA, AAA).Las aplicaciones y sitios web pertenecientes a los organismos mencionados, creados a partir de abril de 2010, deberán alcanzar el nivel de conformidad AA. Las aplicaciones que ya se encuentran en vigencia deberán adoptar dichas pautas en un plazo de dos años a partir del momento en que la presente resolución entre en vigencia. Para verificar este aspecto deberán utilizar como referencia las herramientas de validación descritas en la de Guía de Usabilidad y Accesibilidad Web detallada debajo.

5. Adopción de una Guía de Usabilidad y Accesibilidad Web

El área de Usabilidad y Accesibilidad Web creará una Guía para los desarrolladores la que deberá ser solicitada al inicio de cada proyecto. Debido a la dinámica propia de las tecnologías de comunicación, la información de esta Guía, podrá actualizarse periódicamente. Para cada proyecto se establecerá cuál es la versión de los lineamientos a aplicar los que serán de obligatorio cumplimiento por parte de las entidades a las cuales se refiere la presente resolución.

1. Requerimientos de Usabilidad

Se solicita a los diseñadores que entreguen al área de Usabilidad y Accesibilidad Web del GCBA, los informes detallados debajo durante el proceso de desarrollo, con el fin de garantizar que las aplicaciones y sitios web del GCBA - ya sean de Internet o Intranet - cuenten con las siguientes propiedades:

Facilidad de ser aprendido: que sean lo suficientemente fáciles de aprender, de modo que los usuarios puedan rápidamente comenzar a utilizarlos sin mayores inconvenientes.

Eficiencia: que permitan un alto grado de productividad.

Recordabilidad: que la modalidad de uso sea tal, que un usuario que no los ha utilizado por un tiempo, pueda volver a utilizarlos, sin tener que aprender nuevamente sus operatorias.

Baja tasa de errores: que al utilizarlos, los usuarios tengan una baja tasa de errores y en caso de cometer equívocos, que el sistema disponga alternativas sencillas para solucionarlos.

Satisfacción: que dejen una impresión subjetiva positiva en el usuario.

1.1. Informe 1: Perfiles, tareas y objetivos de usabilidad

A partir de los objetivos establecidos en el inicio de la contratación, el informe deberá contener los siguientes contenidos:

Análisis de los perfiles de usuarios que ingresarán al sitio.

Tareas principales.

Tiempo máximo estimado para efectuar cada tarea.

Tasa de errores aceptables para el usuario que ingresa por primera vez al sitio.

Este informe deberá ser consensuado y validado por el área de Usabilidad del GCBA, para luego testear los prototipos con usuarios reales.

1.2. Informe 2: Reporte de pruebas con usuarios y documentación de cambios

Se deberá entregar un informe de las pruebas realizadas a los usuarios en las distintas etapas del proyecto. Además, éste incluirá la documentación sobre los cambios efectuados a partir del análisis de las mismas.

1.3. Evaluación de resultados de pruebas con usuarios

El Área de Usabilidad y Accesibilidad Web del GCBA comparará los resultados de los informes de los proveedores contra los realizados por personal del gobierno, para verificar su validez; pudiendo solicitar modificaciones sobre el diseño de la interfaz.

La evaluación del GCBA estará basada en los siguientes lineamientos:

1. Lenguaje: El lenguaje utilizado en las interfaces debe corresponder con el lenguaje del usuario, tanto en idioma como formas de éste. El nivel del lenguaje a utilizar estará determinado por los perfiles previamente definidos.

2. Visibilidad del estado del sistema: La aplicación deberá mantener informado al usuario sobre lo que está ocurriendo en cada momento.

3. Consistencia: Es necesario mantener la consistencia de la interfaz en todos los aspectos y dimensiones de la interacción.

4. Flujo de trabajo y prevención de errores: El diseño de la interfaz debe estar focalizado en guiar al usuario a cumplir su objetivo, evitando divergencias que obstaculicen su tarea.

5. Prefiera elegir antes que recordar: Evite utilizar la memoria del usuario como recurso.

6. Simplificación de las interfaces: En las interfaces debe predominar la simplicidad por sobre la complejidad para facilitar la ejecución de las tareas a los usuarios.

7. Ayudas: Las ayudas deben estar dispuestas, de un modo contextual y visible, en el momento y lugar que sean necesarias.

8. Correcto uso de opciones por defecto: Las opciones seleccionadas por defecto deben ser acordes al uso más frecuente o recomendado.

9. No brindar información que pueda desorientar al usuario: La información que se presenta debe ser la que el usuario requiere en el momento.

10. Mensajes de error: Todo mensaje de error debe señalar el campo en cuestión (la indicación no basarse sólo en el color, sino debe estar acompañado de un ícono). La explicación de lo ocurrido debe evitar un lenguaje técnico y debe ofrecer soluciones.

2. Requerimientos de Accesibilidad

2.1 Herramienta de validación automática

Para verificar la accesibilidad, se deberán utilizar como referencia las siguientes herramientas de validación:

http://tawdis.net

W3C Tool

2.2 Listado de verificación de accesibilidad adaptado a las necesidades del GCBA

Como herramienta de verificación, hemos redactado un listado adaptado a las necesidades del Gobierno de la Ciudad Autónoma de Buenos Aires dividido por las áreas de trabajo de diseño y maquetación.

2.2.1. Listado de verificación para el área de diseño

Navegación: En caso de contar con sub-secciones ¿Incluye Mapa de Sitio o Tabla de Contenidos?

¿Los elementos comunes están localizados en la misma posición en todas las pantallas?

¿Los elementos interactivos se comportan de la misma forma todas las veces que aparecen?

Textos: ¿Se distingue el color de los textos de su color de fondo?

Enlaces: ¿Se diferencian los enlaces del resto de los textos por su color, subrayado u otra característica?

¿Cuentan todos los enlaces – ya sean textos, botones o íconos – con estado Roll Over? (Se satisface con el atributo de CSS a:hover)

¿Queda señalada la solapa (botón/enlace) dónde se encuentra el usuario?

¿Los textos de los enlaces son lo suficientemente explícitos en su destino?

¿No existen hipervínculos distinguidos con las frases “click aquí” o “+ info”?

¿Cambian los colores de los enlaces ya seleccionados?

Colores: ¿La información transmitida a través de los colores también está disponible sin color?

2.2.2. Listado de verificación para el área de maquetación

HTML Y CSS

¿Las etiquetas utilizadas son sintácticamente correctas?

¿Están íntegramente independizados los estilos a través de CSS?

¿El uso de tablas se restringe a la tabulación de datos y no para diagramar el contenido del Sitio Web?

¿Se puede navegar el Sitio íntegramente (incluyendo objetos incrustados) a través de un teclado?

¿Existe alguna función crítica del sitio incluida en algún objeto de Flash y está verificado que sea accesible?

Identificación del lenguaje:

El lenguaje está identificado de esta forma: <HTML lang=”es”>

Las abreviaturas se encuentran señaladas con el atributo <abbr>? (Ejemplo “Alte”: <abbr title=”Almirante”>Alte.</abbr>)

Las abreviaturas se encuentran restringidas a las definidas por la Real Academia Española (RAE).

¿Los acrónimos se encuentran señalados con el atributo <acronym>? Ejemplo: “GCBA”: <acronym title=”Gobierno de la Ciudad de Buenos Aires”> GCBA </acronym>)

Imágenes y animaciones:

¿Todas las imágenes y animaciones cuentan con un texto alternativo?

¿Los textos alternativos representan una alternativa válida para transmitir la misma información que comunica el formato no textual? (NOTA: Quien elabore el contenido debe proveer el texto alternativo para las imágenes informativas, de forma que el programador pueda incluirlas) Ejemplos: El texto alternativo de un banner debe incluir la descripción de los objetos y/o textos que figuran en la imagen. No debe decir “banner”.El texto alternativo de una flecha (botón) debe decir “siguiente” o “volver”. No debe decir “flecha”.

¿Todas las animaciones pueden ser controladas (pausadas) por el usuario?

Multimedia

¿Los audiovisuales o archivos de audio se encuentran subtitulados o incluyen el texto en un archivo tipo HTML u RTF?

¿La voz principal se distingue con facilidad del sonido ambiente?

PDF

¿Los documentos PDF pueden ser interpretados por un lector de pantallas para no videntes? (validar con un lector de pantallas como NVDA)

Las imágenes del PDF ¿cuentan con un texto alternativo?

Si un documento PDF no fuera accesible, ¿existe una versión alternativa accesible en HTML u RTF?

¿Todos los enlaces se encuentran acompañados con el ícono identificativo de Adobe PDF?

Formularios: Carteles de error

¿Evitan el lenguaje técnico?

¿Señalan el campo en cuestión (basándose no sólo en el color sino acompañándolo también de un ícono)?

Conclusiones

Las principales conclusiones del caso de Elaboración de una Normativa de Usabilidad y Accesibilidad Web para la web de la Ciudad de Buenos Aires han sido:

Que una interfaz es un objeto comunicacional que necesita profesionales y procesos centrados en la psicología de los usuarios.

Que el diseño centrado en el usuario implica un cambio de paradigma y precisa un replanteo de los flujos y roles de trabajo, justamente porque es un proceso cíclico, ágil y dinámico basado en la observación de los seres humanos interactuando.

Bibliografía

Norman, Donald, The design of Everyday Things.

Web Content Accessibility Guidelines (WCAG) 2.0, W3C Recommendation, 11 Diciembe 2008.

Capítulo 16: Internacionalización Web, por Claudio Segovia

Mini biografía del autor

Difusor de temas relacionados con Internet, el software libre y la presentación de la información en forma equitativa y accesible para todos. Investigador, docente y consultor en accesibilidad en Internet. Miembro del grupo de expertos de Seminario Iberoamericano de Accesibilidad a la Red ( SIDAR ). Miembro del grupo de Accesibilidad del capítulo argentino de la Internet Society. Disertante en eventos nacionales e internacionales sobre accesibilidad web e internacionalización en Internet.

Actualmente es docente de computación, tecnología, matemáticas y diseño web y coordinador del club de ciencias “Misterios de la ciencia”.

Más información:

Ingresar al sitio web del autor

Correo electrónico: Enviar mail al autor.

Internacionalización web

Introducción

Lo deseemos o no, vivimos inmersos en algo llamado globalización, intentando aprovechar sus beneficios y también sufriendo sus consecuencias.

Los últimos años nos han hecho cada vez más conscientes de la unidad pero, al mismo tiempo, de la diversidad de la sociedad mundial. Por más que algunos hayan insistido, no todo el mundo festeja Navidad, ni habla un mismo idioma, ni comprende lo mismo con un gesto. La Web, desde sus inicios, tiene una estructura internacional, por lo que en el transcurso del diseño de un sitio web nos encontramos con una de sus consecuencias, que es la forma en que debemos manejarnos ante las diversas culturas de los distintos usuarios.

Conviene recordar que, una vez que creamos nuestra primer página web, y aunque hablemos en ella de temas locales, será visitada por usuarios de lugares muy diversos, en donde la cultura y todo lo que esto genera (modo de hablar, escribir, medir el tiempo, formas de comparación y ordenamiento, de usar el calendario... y un extenso etc.) puede ser muy distinto.

¿Por qué nos puede interesar la Internacionalización web?

Para que nuestra propuesta llegue a más clientes / usuarios / votantes / colaboradores / asociados / fans / donantes / seguidores… etc..

Porque se utilizan los recursos de forma más eficiente, ya que implementar la internacionalización como parte del proceso de desarrollo original requiere menos recursos para pruebas y desarrollo que si se agrega la compatibilidad después de comenzado el trabajo de desarrollo inicial.

Para promover un acceso a la información más amplio y justo para mayor cantidad de personas.

Porque constantemente se suman nuevas herramientas que permiten usar este conjunto de técnicas.

Se puede agregar rápidamente compatibilidad para nuevas referencias culturales, ya que una vez finalizado el sitio inicial, no se necesitará ningún desarrollo adicional para crear versiones traducidas. Sólo será necesario traducir los recursos del sitio para la referencia cultural de destino.

Por curiosidad intelectual.

Una vez definidas las razones para “tener en cuenta al otro” (frase que guía también otras áreas, como la accesibilidad web o la web semántica), veamos qué pautas hay que tener en cuenta para hacer esto.

La Iniciativa de Accesibilidad a la Web (Web Accessibility Initiative – WAI)

Existen varias pautas que intentan indicar de qué forma debemos tener en cuenta la internacionalización web, pero se recomienda, por su origen, tomar las incluidas en la Iniciativa de Accesibilidad a la Web 1, del Consorcio W3C 2.

Como se sabe, hubo, en 1999, una versión 1.0 de estas pautas y en el año 2008, teniendo en cuenta los problemas y nuevas tecnologías que fueron apareciendo, salieron las pautas versión 2.0. Veamos qué dice esta versión.

WAI versión 2.0 3 Pauta 3.1: “Legibilidad: Cree contenidos legibles y fáciles de entender.”

Criterio de cumplimiento 3.1.1, nivel A: “Idioma de la página: El idioma humano predeterminado de cada página web puede ser determinado por un programa.”

Criterio de cumplimiento 3.1.2, nivel AA: “Idioma de las partes: El idioma humano de cada pasaje o frase en el contenido puede ser determinado por un programa, excepto los nombres propios, términos técnicos, palabras en un idioma indeterminado y palabras o frases que se hayan convertido en parte natural del texto que las rodea.”

Criterio de cumplimiento 3.1.6, nivel AAA: “Pronunciación: Se proporciona un mecanismo para identificar la pronunciación específica de las palabras cuando el significado de esas palabras, dentro del contexto, resulta ambiguo si no se conoce su pronunciación.”

¿Cómo hacer esto?

La internacionalización de un sitio web, como vimos, no se refiere solamente a crear un sitio multilingüe. Enumeremos los distintos aspectos, para luego entrar en detalles:

Codificación de lenguas.

Negociación de contenidos.

Despliegue de caracteres e ideogramas.

Dirección del texto.

Uso semántico.

Evitar la ambigüedad lingüística.

Formatos de fechas y calendarios.

Preferencias del navegador.

Direcciones web multilingüales.

Comparación de cadenas o reglas de ordenación.

Ruby.

Otros: Colores , símbolos, gestos, direcciones postales, localismos...

Codificación de lenguas

Normas. Cada lengua tiene un código unívoco que la identifica y diferencia del resto. En el principio, se intentó hacer esto a través de una norma ISO: la ISO 639. Esta norma es de 1988 que actualmente consta de 6 partes. Además hay otras normas que intentan complementarla o mejorarla.

Código. Una vez que sabemos de dónde sacar los códigos correspondientes a cada lengua, veamos cómo “hacer la etiqueta” para los distintos lenguajes:

HTML. Si todo el texto de la página está escrito, por ejemplo, en guaraní, agregaremos a la etiqueta <html> lo siguiente: <html lang=”gn”> Donde gn es el código correspondiente al guaraní En el caso que insertemos en un texto de un idioma una palabra o frase de otro, deberemos agregar el atributo lang en la etiqueta span, por ejemplo: <p>En mapuche, gente o pueblo se dice <span lang=”arn”>che</span>.</p>

XHTML. Por compatibilidad entre HTML y XML, usaremos la siguiente sintaxis: <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”es” lang=”es”>

XML. Usaremos la etiqueta xml:lang de la siguiente forma: <p>En mapuche, gente o pueblo se dice <span xml:lang=”arn”>che</span>.</p>

Negociación de contenidos

Uso de HTTP. El protocolo HTTP es el más usado por la Web. De hecho, es el que nos permite ver y navegar las páginas web. Cuando un navegador se conecta con un servidor web remoto, no sólo le solicita la página cuya dirección el usuario ha escrito sino que le informa de detalles del navegador, de la página solicitada, etc.

Luego, una vez que la conexión se realiza, el servidor también contesta enviando una respuesta HTTP y a continuación la página solicitada.

Uso de HTTP desde el servidor. Es importante asegurarse de que toda información sobre idioma y codificación de caracteres enviada por el servidor web sea correcta, dado que la información incluida en el encabezado HTTP anula la información que contiene el documento mismo.

Codificación de caracteres

La información de codificación inadecuada no sólo perjudica la capacidad de lectura de un texto que se visualiza, sino que, además, puede significar que sus datos no se encuentren en una búsqueda o que no se puedan procesar de manera confiable de diversas formas.

Algunos ejemplos de caracteres incluyen la letra latina acentuada “á”, el ideograma chino “請” o el caracter devanagari “ह”.

Los caracteres se agrupan en un conjunto de caracteres o set. Cuando a cada carácter se le asigna un número en particular, a eso se lo denomina un set de caracteres codificados.

Desafortunadamente, existen muchos sets y codificaciones de caracteres, por lo que se intenta corregir con la iniciativa Unicode.

Unicode. Es un estándar de codificación de caracteres hecho para ayudar en la visualización de textos de múltiples lenguas. Actualmente, la última versión de Unicode es la 6.3.

La forma de codificación de datos de Unicode simplifica el desarrollo de aplicaciones y sitios web de uso internacional, porque permite que todos los caracteres internacionales estén representados con una única codificación.

Declaración del conjunto de caracteres. El Consorcio W3 dice 4 que todo documento transmitido por HTTP que sea de tipo texto (texto plano, HTML, etc.) debe tener un parámetro charset que especifique la codificación de caracteres del documento.

<meta http-equiv=”Content-type” content=”text/html; charset=ISO-8859-1 “ />

<meta http-equiv=”Content-type” content=”text/html; charset=utf-8” />

Dirección del texto. Conviene recordar que existen varias lenguas que se leen de derecha a izquierda:

Hebreo.

Árabe.

Sirio.

Persa.

Etc.

Además, algunas lenguas ideográficas, como el japonés, coreano, mongol o el chino mandarín, son más flexibles en su dirección de escritura. En algunos casos se escriben de izquierda a derecha o verticalmente de arriba hacia abajo, aunque también se escriben (verticalmente) de derecha a izquierda. Algunos diarios chinos, por ejemplo, a veces combinan todas esas direcciones de escritura en una misma página 5.

¿Cómo trabajar con ellas?

Declarar Unicode para la página: <meta http-equiv=”Content-type” content=”text/html; charset=utf-8” />

Si no todo el texto está escrito en una lengua, declarar el cambio de dirección cuando se produce en el código: <p>Texto en español <span dir=”rtl” lang=”ar” xml:lang=”ar”>مفتاح معايير الويب</span> texto en español.</p>

También podemos agregar una traducción para el caso que algún usuario use un navegador que admita la opción title: <p>Estos países son Bahrein, <span dir=”rtl” lang=”ar” xml:lang=”ar” title=”Significa: ‘Egipto’”>مصر</span> y Kuwait.</p>

Además, conviene recordar que, como occidentales, la costumbre de ver una imagen o la estructura de un diario o sitio web de izquierda a derecha tiene que ver, en parte, con que aprendimos a leer en esa dirección. Por esto, también debemos pensar que deberemos cambiar la estructura de nuestro sitio web si el mismo está destinado a un público habituado a leer de derecha a izquierda 6.

A esto último (inversión del diseño de las ventanas, los menúes, los cuadros de diálogo y demás elementos visuales de un sitio web) se lo llama, en diseño web, reflejo 7.

Uso semántico

Ya en accesibilidad web se ve la necesidad de tener en cuenta el marcado semántico. En internacionalización también se puede ver el resultado de esto.

Asi, por ejemplo, debemos recordar que si enfatizamos un texto, debemos usar la etiqueta <em> y no la etiqueta <i>. Esto se volverá más evidente si el texto no está en una lengua occidental conocida, sino en otras como el japonés, donde los ideogramas etiquetados con <i> no mostrarán visualmente ninguna diferencia con el resto del texto. En cambio, si usamos <em>, luego podremos darle con CSS2 un recuadro sombreado a esos ideogramas (una de las opciones usadas en japonés, llamado amikake), o indicarle que muestre un pequeño círculo sobre cada ideograma con CSS3 (la opción más común en japonés para mostrar énfasis, llamado Wakiken 8):

Si nuestro texto está en tibetano, pasará algo parecido. En esta lengua se usan dos pequeñas marcas debajo de cada sílaba enfatizada, por lo que un buen uso del marcado semántico nos ayudará 9:

En cirílico, el énfasis puede aparecer de varias formas:

Como un símbolo parecido a la tilde de nuestra ñ (й, ў).

El texto puede adoptar formas redondeadas 10.

Puede cambiar completamente de forma 11.

Evitar la ambigüedad lingüística

Una palabra puede ser muy clara en un idioma, pero no tanto al traducirla a otro, por lo que debemos tener en cuenta esto a la hora de programar y diseñar.

Por ejemplo, la frase “Empty folder” puede resultar un texto claro en inglés, pero puede resultar una construcción ambigua al intentar traducirla a otro idioma, ya que las cadenas se pueden traducir de forma diferente según las funciones gramaticales de los componentes de dichas cadenas. Así, “empty” puede ser tanto un verbo como un adjetivo y esto puede llevarnos a traducciones diferentes en idiomas como el italiano o el francés.

Se recomienda, dependiendo de cada caso, que los sitios web tengan referencias culturales e idiomáticas neutras.

Formatos de fechas y calendarios

El carácter internacional de Internet hace que nos encontremos con diversas formas de representar las fechas, además de los calendarios no gregorianos:

Estados Unidos: 11/08/2012

Europa y parte de Latinoamérica: 08/11/2012

Japón: 2012年 11月 8日

China: 2012年 11月 8日12

Esto nos recuerda que, por más que nos parezca común, nuestra forma de mostrar una fecha no es la común para todos en el mundo.

Calendarios. Actualmente coexisten en el mundo más de 40 calendarios 13:

Gregoriano.

Hebreo.

Árabe.

Japonés.

Coreano.

Chino.

Persa.

Etc.

¿Cómo atender a las necesidades de tal variedad de usuarios?

Usar un formato local neutro. La norma ISO 8601 especifica que las fechas se deben mostrar en el formato AAAA-MM-DD.

A favor: No resulta ambiguo. Es amigable para los usos informáticos que deseemos darle a la fecha (bases de datos, búsquedas, ordenamientos, web semántica, etc.).

En contra: No es un formato amigable para las personas. Ocupa más espacio que una fecha en formato común.

Resulta confuso para los usuarios de países que tienen un calendario alternativo, como por ejemplo en Tailandia, donde usan el calendario budista. Explicitar los meses y años hasta la obviedad. Usar nombres para los meses (abreviados o no) y 4 dígitos para los años.

A favor: No resulta ambiguo. Es amigable para los usuarios.

En contra: Es muy poco amigable para los usos informáticos. Ocupa más espacio.

En algunas lenguas el uso de tres letras para el mes puede resultar problemático (en francés, Junio y Julio son Juin y Juillet). No siempre los meses serán fácilmente reconocibles en distintas lenguas (para un español no hablante de inglés, Jan no le significará Enero).

Usar la cabecera de HTTP Accept-Language. La cabecera HTTP Accept-Language, especifica las preferencias de la lengua del usuario, pero también es usada para determinar preferencias locales 14.

A favor: No resulta ambiguo. Es amigable para los usuarios.

En contra: Este método funciona principalmente para páginas web dinámicas, donde se inserta la fecha desde un almacenamiento externo. No todos los servidores permiten configurar esta opción.

Preferencias del navegador

Cuando un navegador pide un documento a un servidor, y el servidor tiene varias versiones de una página en distintos idiomas, esta información puede usarse para recuperar la página en el idioma preferido. Si hay una única versión de dicha página en ese servidor, esa es la que se recuperará.

La mayoría de los navegadores permiten cambiar las preferencias del idioma, cuyo valor, como ya dijimos, es definido por las normas ISO 639, que le brinda un código de dos o tres letras a cada idioma, seguido por un subcódigo opcional de dos letras por país, por ejemplo: es para español y es-AR para el español de Argentina.

En algunos navegadores es posible establecer más de un idioma, dándoles un orden de preferencia, como se muestra a continuación:

Direcciones web multilingüales

Una dirección web es usada para apuntar a un recurso en la Web, como una página web. Estas direcciones se expresan a través de Identificadores Uniformes de Recursos. La sintaxis de las URIs restringe las direcciones web a un pequeño número de caracteres:

Letras mayúsculas y minúsculas del alfabeto en inglés.

Numerales europeos.

Un pequeño número de símbolos.

Esto se debe a que la Web comenzó a desarrollarse en el ámbito angloparlante. Pero al poco tiempo se vio que este ámbito se ampliaba a pasos agigantados haciendo necesario el tener que usar caracteres de cualquier lenguaje en las direcciones web. Una dirección web en nuestra propia lengua es fácil de crear, recordar, transcribir, interpretar y relacionar. Y esto nos lleva a mejores negocios, mejorar las búsquedas y las comunicaciones. En resumen, mejora la Web.

Para lograr esto existe algo llamado Identificador de Recursos Internacionalizado o IRIs. Actualmente varios formatos soportan IRI, pero desgraciadamente, no muchos protocolos. Así, es posible encontrar una dirección como la que sigue: http://納豆.例.jp

En donde la declaración del protocolo (http://) debe estar en caracteres ASCII, mientras que el dominio es una mezcla de caracteres ASCII con japoneses. Aquí aparece Unicode, transformando la dirección web en caracteres ASCII de la siguiente manera: http://xn--jp-cd2fp15c.xn--fsq.jp … para luego poder resolver dicha dirección en una dirección IP numérica.

Y esto no sólo es necesario para lenguas orientales. Veamos, por ejemplo, la siguiente dirección sueca: http://räksmörgås.josefsson.org/mål/franzén.html

Comparación de cadenas o reglas de ordenación. Supongamos que desde nuestro sitio ofrecemos la opción de mostrar, de acuerdo a las necesidades del usuario, datos ordenados de acuerdo con diversos parámetros.

Bueno, no habría problemas si nos guiáramos solamente con nuestra lengua y nuestro calendario. Pero si queremos tener en cuenta otras culturas, nos encontraremos con algunas cositas más a tener en cuenta.

Fechas y calendarios. De acuerdo a lo que leímos anteriormente, no hay UNA fecha ni UNA sola forma de mostrarla, asi que esa es una de las opciones básicas a tener en cuenta. Si vamos a elegir una de las formas y calendarios para mostrarlos ordenadamente, y siguiendo las pautas de accesibilidad a la Web, deberemos informar de esto al usuario que hace la consulta y, dentro de lo posible, darle la posibilidad de elegir otros calendarios o formatos.

Caracteres distintos a los que usamos. De acuerdo a nuestra experiencia cotidiana, ya sabemos que si nos piden ordenar determinados nombres en orden alfabético, deberemos poner la A antes que las B (salvo que nos pidan en orden inverso, claro.

Pero... ¿qué pasa si nuestros posibles clientes o usuarios hablan chino mandarín, japonés o hindi, por citar tres lenguas MUY populares?

Bueno, deberemos tomarnos el trabajo de averiguar qué sistema usa cada cultura.

El chino mandarín, por ejemplo, tiene dos formas distintas de ordenar (obviamente que ninguna es “alfabética”, ya que no tiene un alfabeto, tal como lo entendemos los occidentales): una por pronunciación y otra por el número de trazos. La elección de uno u otro depende de la región del usuario.

Aunque tampoco debemos irnos muy lejos en las distancias, para tener problemas de ordenamiento.

Veamos los siguientes caracteres que aparecen en el teclado: ß, Æ, â, ë, ñ, ç y muchos otros, dependiendo del origen del teclado o el mercado al que va dirigido.

Algunos sabemos, o imaginamos, dónde deberemos colocarlos a la hora de ordenar.

Pero... ¿estamos seguros de dónde irán ß o Æ?

Tomemos la ß. No es la letra griega beta (β) ni una B deformada. Se llama ezeta, ese-zeta o ezsett. Es de uso muy común en los idiomas alemán y danés. Es una letra minúscula y no hay versión en mayúscula. Se usa la misma letra, con la misma forma, tanto en un texto en mayúscula como en minúscula. Esto es algo que deberemos tener en cuenta si una decisión de seguridad, por ejemplo, se basa en el resultado de una comparación de cadenas o una operación de cambio de mayúsculas y minúsculas.

Además, en alemán la ß y la ss son consideradas equivalentes, por lo que un orden alfabético aceptado en alemán es el siguiente:

kasse

kaßt

kosse

Ahora veamos el carácter Æ. Este carácter se usa en los idiomas inglés, alemán, sueco y danés. Pero mientras que en el alemán se lo ubica luego de la A, en el danés y sueco, se lo ubica luego de la Z. Y otra diferencia surge en la forma en que se lo trata. En danés, se lo trata como carácter individual, pero en inglés como símbolo especial, asi que las palabras “Apple” y “Æble”, en danés irán en ese mismo orden, mientras que en inglés será al revés, ya que a los símbolos especiales se los ordena antes de la A en el alfabeto.

El uso de las diéresis también tienen sus características. En el sueco, crean caracteres que son vistos como letras independientes del alfabeto, que aparecen luego de la Z, por lo que un orden alfabético sueco sería:

cabe

cube

cäbe

Además, el orden de acentos y diéresis cambia en el francés, en comparación con otras lenguas. Veamos el orden “común” y el orden del francés:

General Francés

cabe cabe

cábé cäbe

cábë cábé

cäbe cábë

En checo, la secuencia “ch” es usada como una unidad simple y única para ordenar, por lo que las palabras comenzadas con “ch” van luego de la “h” y no luego de la “c”. Un orden alfabético normal en checo sería:

cabe

dabe

chabe

Ruby

Además de un lenguaje de programación muy conocido, Ruby es un tipo particular de anotación que provee de transcripción fonética de caracteres que el lector puede no comprender. Este tipo de anotaciones se realiza a través de un etiquetado específico, que se agrega al etiquetado estándar HTML, XHTML o XML. Es ampliamente usado en materiales de educación escritos en lenguas del este asiático. También es usado en textos para estudiantes occidentales que desean aprender lenguas orientales por su pronunciación 15.

Por ejemplo, veamos la línea de una fecha con Ruby indicando la pronunciación (en chino mandarín):

èr líng líng wû nián shíyî yuè bã rì

2011 年 11 月 8日

¿Eso es todo?

No, es sólo el comienzo. El tema de la internacionalización web excede los alcances de un capítulo y merecería un libro entero, al menos. Falta todavía recordar, por ejemplo, que las diferencias culturales pueden a veces resultar más sutiles.

Colores. El uso de los colores puede resultar distinto. Por ejemplo el luto, en la cultura japonesa, es representado por el blanco, y no el negro. De la misma forma que no es lo común que una novia se vista de negro en Occidente, cosa que no es raro en Oriente 16.

Símbolos. No siempre los símbolos tienen el mismo significado en todo el mundo. Un buen ejemplo es nuestra conocida marca de tilde (√). En algunos países significa incorrecto, no correcto. Otra diferencia a tener en cuenta es que en Japón, los círculos (O) reemplazan estas marcas de tilde, tal como se ve en la siguiente imagen 17:

Gestos. También el lenguaje corporal o los gestos pueden dar lugar a problemas. Cada uno de los siguientes gestos pueden resultar ofensivos en alguna parte del mundo.

Direcciones postales. Para un ruso o un japonés, las direcciones en las cartas se escriben de lo general a lo específico, lo opuesto a nosotros. Asi que ellos pondrán primero el país, luego la provincia, el código postal, la localidad, la calle y número y, por último, el nombre del destinatario. Recordemos esto cuando ofrezcamos, a través de una base de datos, formularios de ingreso de datos, etiquetas postales u otra forma relacionada.

Otro tema es el uso del nombre y el apellido. Los chinos, y otros pueblos, cuando escriben su nombre, ponen primero su apellido y luego su nombre. Por ejemplo Mao Zedong, tenía por apellido Mao, no Zedong.

Localismos. Si en nuestros textos, información o publicidades vamos a hacer referencia a chistes que se ven en la televisión o se oyen en la radio de nuestra ciudad, es muy probable que el otro se “quede afuera” y no entienda (o peor: entienda mal y se ofenda) el sentido de lo que queremos transmitir.

En resumen. Ya citamos la frase “tener en cuenta al otro” para pensar en la internacionalización web. Esto lo podemos tomar de dos formas. Por un lado, como “otro problema” en el que tendremos que adentrarnos para intentar solucionar las necesidades de los usuarios en aumento de nuestro sitio web.

Pero por otro lado, es una oportunidad de ver el problema como el comienzo de nuevas y apasionantes experiencias, en donde, a medida que nos comencemos a interiorizar por la cultura “del otro”, también comenzaremos un viaje interior, a nuestra propia cultura, y si tenemos la suficiente paciencia, quizás descubramos, como a mí me ha pasado, que en el fondo no hay un “ellos” y “nosotros”, sino que vivimos en una sociedad mundial compleja y variadísima... pero única, fascinante y siempre dispuesta a enseñarnos algo nuevo y alternativo con qué enriquecer nuestra pequeña existencia.

Referencias

1. http://www.w3.org/WAI/

2. Además, hay una sección específica de este consorcio especializada en la internacionalización, que se puede [Visitar sitio en línea].

3. http://www.w3.org/TR/WCAG20/ (hay una versión en español en [Ingresar en la versión en español] ).

4. Configuración del parámetro charset de HTTP [Ver en línea]

5. La imagen es aportada por Richard Ishida en la siguiente dirección: [Ver imagen en línea] , y forma parte del artículo que está en la página: [Ver sitio completo] .

6. Esto se puede ver hasta en gráficos, tablas, hojas de cálculo, etc., como la imagen que aparece adelanta, cuya fuente es: [Ver la fuente en línea], de Richard Ishida.

7. Un detalle que puede resultarnos curioso y que puede llegar a influir a la hora de diseñar una página, es que si justificamos un texto, no se mostrará de la misma forma en todas las formas de escritura. Mientras que en las lenguas occidentales, el justificado se realiza agregando espacio a los espacios entre palabras, en lenguas como el árabe, lo que se “estira” es la palabra, tal como podemos ver en las siguientes imágenes: Texto árabe sin justificar . El mismo texto en árabe justificado .

8. El origen de las imágenes es: [Ver en línea la imágen] de la nota a pie de página 8 , que forma parte de la página: [Ingresar al sitio Web] , de Richard Ishida.

9. La imagen, provista por Richard Ishida, está en: [Ver en línea la imágen] de la nota a pie de página 9 y forma parte de la página: [Ingresar al sitio Web] de la nota a pie de página 9

10. La imagen de la derecha proviene de una provista por Richard Ishida que se encuentra en: [Ver en línea la imágen] de la nota a pie de página 10 .

11. La otra imagen fuente de la de la derecha se encuentra en [Ver imagen en línea] .

12. La fechas pueden también aparecer con el formato europeo, pero no es lo más común (Mazel Sussman, Julie, “I can read that! A traveler’s Introduction th Chinese Characters”, China Books & Periodicals, Inc., 1994, San Francisco, Estados Unidos, página 31).

13. Un detalle de los mismos se puede leer en la página: [Ver texto completo en línea]

14. En la página http://goo.gl/TLyGcK encontraremos la forma de configurar esta cabecera en Java/JSP, ASP y Perl.

15. La especificación oficial de Ruby en el sitio del Consorcio W3 está en la siguiente página: http://www.w3.org/TR/ruby/ .

16. Ishida, Richard, “Color”, en presentación “Introduction to Writing Systems”, diapositiva 39, 10 de junio de 2003 http://goo.gl/33mTL2 .

17. Ishida, Richard, “Color”, en presentación “Introduction to Writing Systems”, diapositiva 75, 10 de junio de 2003 http://goo.gl/3RdflV.

Bibliografía

Mazel Sussman, Julie, I can read that! A traveler’s Introduction th Chinese Characters, China Books & Periodicals, Inc., 1994, San Francisco, Estados Unidos.

Ouane, Adama (editor), Towards a Multilingual Culture of Education, UNESCO, 2003.

Paolillo, John, Pimienta, Daniel, Prado, Daniel, Mikami, Yoshiki y Fantognon, Xavier, Measuring Linguistic Diversity on the Internet, UNESCO, Francia, 2005.

Xi, Xiandai, Han, Han, Cidian, Xi, Diccionario moderno español - chino, chino - español. 1992.

Crystal, David, The Scope of Internet linguistics, 2005.

Holzschlag, Molly E., Internationalization: awakening the sleeping giant, 2006.

Ishida, Richard, Practical & Cultural Issues in Web Design, 2003.

Ishida, Richard, Internationalizing the Web, 2005.

Valero, Pedro, Internacionalización, Universitat de València.

Capítulo 17: Prácticas participativas en el Diseño de Interacción: El caso del Design Museum, por Mariana Salgado

Mini biografía del autor

Diseñadora e investigadora. Doctorada en Diseño de Interacción de la Universidad de Arte y Diseño de Helsinki. Dirigió la Maestría en administración de negocios, con especialización en diseño centrado en el usuario, en la Universidad de Ciencias Aplicadas, Laurea. Trabaja actualmente en el Media Lab, Facultad de Arte, Diseño y Arquitectura de la Universidad de Aalto. Le interesan las prácticas relacionadas a la participación porque cree que son claves en la formación de espacios democráticos y abiertos.

Más información:

Ingresar al sitio web de la autora

Correo electrónico: Enviar mail al autor.

Prácticas participativas en el Diseño de Interacción: El caso del Design Museum 1

Comentar la exposición

Estuve explorando el tema de comentar la exposición en previos proyectos en Ateneum Museum 2 y en Kunsthalle 3. En estos casos diferentes grupos comentaron la exposición. En el caso de “Trazos sonoros” fue un grupo de discapacitados visuales y en el caso de “Mapa en diálogo” fueron todos los visitantes a la Bienal de Arte Joven, Pequeño paraíso. La idea principal es exponer los comentarios de otros visitantes para permitir acercarse a las obras expuestas desde diferentes perspectivas. Normalmente, cuando se visita un museo es solo el material interpretativo que provee el curador el que se expone en la sala. Este material tiene un carácter formal y objetivo. Entonces la experiencia de la visita cambia dependiendo de quién nos acompaña. La visita al museo sigue siendo solo para una elite que puede entender y disfrutar el registro del material interpretativo del curador. Salgado trabajó sobre la hipótesis que si en el museo provee comentarios de carácter subjetivo que muestran a los visitantes que está permitido disfrutar las obras expuestas de muchas maneras, entonces aparece un museo abierto. Un museo abierto es un museo accesible e inclusivo de las diferentes voces de nuestra sociedad. Es un museo que invita a participar y interactuar con su contenido no solo desde lo intelectual sino también desde lo afectivo y lo creativo.

La vida secreta de los objetos

El eje de este proyecto fue el contenido generado por los visitantes: comentarios que se expondrían en la galería del museo para complementar los textos del curador y para enriquecer la experiencia de la visita al museo por medio de la inclusión. Se redefinió la noción de comentario para incluir relatos, opiniones, recuerdos o sentimientos, no sólo en forma de texto escrito, sino también de sonidos o imágenes. Para comunicar las nuevas posibilidades asociadas a los comentarios, creamos talleres en los que los visitantes escribían poemas, componían canciones, hacían dibujos y sacaban fotos en relación con los objetos de la exposición permanente, y exhibían esos ejemplos de comentarios a través de un mapa interactivo ubicado en un stand que vinculaba el objeto con los comentarios e invitaba a realizar nuevos aportes. Los talleres y eventos proporcionaron el material inicial (relatos, ideas, recuerdos y nuevos objetos) para incluir en el mapa y para impulsar el agregado de comentarios de los visitantes ocasionales.

Al mapa interactivo se podía acceder en línea y en la sala de la exposición a través de un stand montado especialmente. Así, los visitantes podían sumarse, desde la galería misma o desde una estación remota, en sus hogares, a conversaciones iniciadas por quienes participaron de los talleres o eventos. Además del mapa interactivo, creamos un weblog para describir y comunicar la evolución del proyecto. 4

El primer taller, Esa and the Objects, fue diseñado para niños de cinco años y se realizó en un jardín de infantes y en el museo. Consistía en cinco sesiones dedicadas cada una a un objeto y estaba coordinado por tres facilitadores del museo. En el taller se les proponía a los niños que hablaran de las propiedades y el uso de los objetos de diseño y de la familiaridad que tenían con ellos, y se les proporcionaban datos sobre el contexto histórico de cada uno. Los niños crearon dibujos, móviles y otras interpretaciones basados en los objetos.

El segundo taller, Sound of Objects, fue diseñado para un grupo de adolescentes de once y doce años que estudiaban guitarra. Los alumnos fueron al museo e hicieron una visita guiada en la que les hablaron sobre seis objetos de diseño; luego improvisaron melodías a partir de ellos. Estas melodías fueron grabadas y se podían escuchar desde el mapa.

El tercer taller, Odes for Objects, fue diseñado para dos grupos de adolescentes que asistían a un taller literario. Después de hacer una visita guiada centrada en seis objetos de diseño de la exposición, los adolescentes escribieron un cuento basado en uno de ellos. Como cierre, cada uno escribió una oda inspirada en otro de los objetos. Estas odas se podían leer en línea desde el mapa y en el museo también estaban en las paredes colgadas cerca de los objetos expuestos.

Los participantes del taller Ode to Objects escribieron los siguientes poemas:

Oda a una luz (Ode to Objects)

La luz en bloque / brilla; / Calidez / Frescura / Alegría / el pasado / su forma / Misteriosa / nos llama / lo revela todo / Iina

Oodi valaisimelle (Oodi Esineille)

Palikkavalaisin / se loistaa; / lämpöä / kylmyyttä / Alegría iloa / mennyttä / sen muoto – / on salaperäinen / luokseen kutsuva / kaikenpaljastava / Iina

Anti oda a una lámpara (Ode to Objects)

Un hombre inventa una lámpara / que no es una lámpara / La esconde / en el hielo. / No entiendo / ya tengo frío / quiero una luz cálida, amarilla y elegante. / Una mujer inventa una nueva lámpara / la coloca dentro / Todas las mañanas / le sonríe / por entre las cortinas. / Nana

Anti Oodi Lampulle (Oodi Esineille)

Mies keksi lampun / joka ei ole lamppu / Hän piillottaa lampun – piilottaa / jään sisään. / Minä en ymmärrä / minulla on muutenkin kylmä / haluan lämmintä valoa keltaista / ja sulavaa / Nainen keksi uuden lampun / hän laittaa sen auringon / sisään. / Joka aamu se hymyilee / hänelle / Nana 5

Etapas del Proyecto

El proyecto se desarrolló en dos etapas. En la primera (de octubre de 2007 a febrero de 2008), se implementó el mapa interactivo como parte de un stand de la exposición permanente del Design Museum, que desde hace seis años ocupa el subsuelo del museo. En la primera etapa, en el mapa sólo se incluía una pequeña selección de los objetos de la exposición. Hicimos un seguimiento del modo en que fueron surgiendo las conversaciones en distintas ocasiones (un fin de semana en familia, un evento y la inauguración de una exposición) desde noviembre de 2007 hasta febrero de 2008. Cuando el stand estaba abierto había una persona que invitaba a los visitantes a probarlo y los ayudaba a usar el mapa interactivo.

En la segunda etapa (iniciada en marzo de 2008 y todavía en curso en mayo del mismo año), surgió la posibilidad de armar una versión temporaria de la exposición permanente del museo, la cual llevó el nombre de nuestro proyecto: ‘‘La vida secreta de los objetos, mapa interactivo del diseño finlandés’’ (The Secret Life of Objects, an Interactive Map of Finnish Design). Para esa etapa creamos un nuevo mapa (en tres idiomas: finés, sueco e inglés) y un nuevo stand, mejoramos el software, creamos nuevos textos para el mapa y conseguimos una conexión a Internet más rápida. Esta vez, la mayoría de los objetos de la exposición (40 de los 50 objetos) estaban también en el mapa para que los visitantes opinaran acerca de ellos. Durante la exposición, que comenzó el 18 de marzo y terminó el 1 de junio, el stand con el mapa interactivo estuvo en la galería sin ningún facilitador. En esa etapa, mientras los visitantes ocasionales agregaban comentarios al mapa, nosotros seleccionábamos algunos, los imprimíamos y los colocábamos en el espacio de la exposición. Los comentarios de los visitantes ocasionales aportaron una visión pluralista basada en los objetos.

El stand también tuvo dos versiones, una en la primera etapa del proyecto y otra en la segunda, durante la nueva exposición. En la segunda había una mesa, dos sillas, una computadora, un reproductor de DVD, folletos, un cartel de ayuda (con la explicación básica de cómo usar el mapa), un mouse, un monitor de computadora y dos pantallas grandes.

Todos los componentes del proyecto −el weblog, el mapa interactivo, el stand, la exposición, los talleres y los métodos que se utilizaron para documentarlos− proporcionaron una combinación de recursos que posibilitó la creación de una plataforma participativa que motivó a los visitantes a hacer comentarios.

El contenido creado por los visitantes en un mapa interactivo

Los museos están incorporando a sus sitios web y a sus galerías herramientas que motivan a los visitantes a crear material basado o inspirado en las colecciones. Actualmente existe una gran cantidad de proyectos en los que se exhibe el contenido generado por los visitantes en el espacio de la exposición y en los sitios web de los museos, y en el marco de los cuales se exploran las posibilidades que ofrecen los weblogs, podcasts u otros recursos web 2.0. 6, 7, 8

En ‘‘La vida secreta de los objetos’’, el contenido generado por los visitantes se reunió y exhibió usando los recursos disponibles. Por ejemplo, se usó YouTube para mostrar en línea videos grabados durante los talleres, como parte de un concepto más amplio: la creación de una WebTV del museo. El software de código abierto ImaNote 9 nos permitió crear notas y navegar por el mapa que contenía la disposición de la muestra. Entre las funciones de ImaNote se incluye la capacidad de agregar comentarios y de asociarlos a una imagen (en este caso, el mapa de la exposición). Los comentarios muestran, entre otras cosas, mensajes de texto, enlaces a recursos multimedia en la web (como la música compuesta por estudiantes de guitarra en el taller) e imágenes. El software –desarrollado como proyecto de investigación– nos permitió llevar a cabo la prueba y explorar los desafíos que el contexto del museo planteaba.

En este caso particular, se usó un mapa como interfaz entre los objetos de la exposición y los comentarios del público. Los visitantes podían hallar fácilmente los objetos y el material basado en ellos. Salgado y Díaz-Kommonen pusieron a prueba este concepto con anterioridad en un museo de arte de Helsinki. 10 Por medio del mapa, reunimos y exhibimos paralelamente los comentarios de los visitantes y los de los curadores.

La experiencia de los visitantes

Aunque el concepto de museo como foro de debate 11 es conocido, la práctica concreta de comentar activamente sobre una exposición es nueva para los visitantes. Por lo tanto, hace falta tiempo para instalarla como práctica generalizada en la visita a un museo. El público no está acostumbrado a tener esa posibilidad. En nuestro caso, durante los casi tres meses en que el mapa interactivo estuvo en la exposición, obtuvimos alrededor de cien comentarios.

Hay muchos tipos diferentes de comentarios. Los visitantes criticaron o elogiaron los objetos o a los diseñadores, enviaron un mensaje personal al diseñador, contaron recuerdos o relatos que los vinculaban con los objetos (como qué uso le daban a un objeto), hicieron preguntas, agregaron material relacionado con el objeto y les dieron sonido a los objetos. Por ejemplo, Otto, de 6 años, agregó el siguiente comentario a una obra llamada Spider (araña): “fgyhfgcbvgfhdg ffetrrdfvggbvvcg ffddsdsfsssssdvc cdbdcvdfgghhghghfhghh”. Hay ejemplos de comentarios que plantean preguntas filosóficas, como ‘‘Las arañas me dan escalofríos pero también me fascinan… es rarísimo; les tengo miedo, pero al mismo tiempo quiero mirarlas bien de cerca… ¡¿Será que el miedo y la admiración van de la mano?!’’ o ‘‘Una vez tuve un sueño donde vi la misma araña y me sorprendió que alguien haya soñado lo mismo antes que yo y decidiera hacerlo realidad. ¿Ya está todo inventado, entonces?’’.

Después de observar y entrevistar al público durante la exposición, los investigadores del equipo advertimos que la mayoría de los visitantes no necesariamente tratan de usar el mapa interactivo a menos que se los anime a hacerlo. Así y todo, la mayoría de los que lo usaron se llevaron una impresión positiva. Los visitantes que entrevistamos leyeron los comentarios impresos en la exposición y disfrutaron de que se integrara una visión personal y multifacética a la exposición. El hecho de mostrar las reacciones de los visitantes frente a las piezas del museo nos permitió explorar el proceso de validación de los aportes y de estímulo de la participación.

El valor de los comentarios

La idea de mantener en el mapa la voz del museo en paralelo a la voz de los visitantes me llamó a considerar qué otras voces no estábamos teniendo en cuenta. Por eso casi al final del proyecto también entrevisté a algunos de los diseñadores que tenían sus objectos en esta exposiciones. Estas entrevistas que fueron documentadas en video no se incluyeron en el mapa. Sin embargo, me ayudaron a considerar que es importante incluir todos en la comunidad del museo, no solo a visitantes y el personal educativo, sino también a investigadores, diseñadores o artistas, personal de limpieza, curadores, educadores, y todos los que tengan historias que se relacionen con los objectos expuestos.

Cabe destacar que no fui yo quien registró los comentarios, sino que los ingresaron las personas que participaron en las exposiciones. Silverman 12 sugiere que la forma en que registramos los datos es “importante porque está conectada directamente con la calidad del análisis” (p. 142). Estos comentarios hechos por la comunidad del museo pueden:

Facilitar el acceso del público nuevo al contenido.

Extender en el tiempo el compromiso de la gente con el material de la exposición.

Contribuir al aprendizaje que tiene lugar en la exposición, invitando a las personas a relacionarse activamente con ella.

Validar múltiples perspectivas y promover debates a partir del material de la muestra.

Generar posibilidades de diálogo e intercambio dentro de la comunidad del museo.

Ayudar a identificar y a integrar nuevos miembros de la comunidad y a entender sus expectativas en relación con los museos y las salas de exposición.

Aportar documentación complementaria y material interpretativo relacionado con los objetos de la exposición.

Conclusión

La alianza entre los diseñadores e investigadores (del Laboratorio de medios) y el equipo educativo del museo le dio un carácter original e instructivo al proyecto. El mapa interactivo y los talleres tuvieron un objetivo común: reunir material audiovisual que contara historias sobre los objetos. Los eventos, los talleres, la documentación multimedia y el mapa interactivo exhibido en el museo fueron co-diseñados como un todo coherente en un grupo multidisciplinario.

El co-diseño sucede cuando los diseñadores aprenden de sus colaboradores y viceversa. En este caso el personal del museo se apropió del mapa, lo re-interpretó, y creó nuevas ideas y material interpretativo más accesible para la colección. En una charla con una educadora que participó en proyecto ella se refirió a este proyecto como una experiencia educativa para el personal del museo porque los hizo pensar el material interpretativo de una manera más accesible. Esta vez usaron un encuadre y un vocabulario que pudiera ser entendido por un público menos especializado. Por otro lado, los diseñadores en el proyecto aprendimos sobre las prácticas del museo y sus valores. Fuimos testigos como el mapa se enriquecía a partir de las ideas propuestas por el personal del museo y los visitantes.

Durante el tiempo de la exposición entrevisté a personal del museo, visitantes y diseñadores. En base a estas entrevistas y a observaciones en la exposición fui proponiendo cambios e implementándolos. Esta actitud activa durante el momento de uso es fundamental para el diseñador de interacción. Botero, Kommonen y Marttila 13 proponen la expansión del espacio de diseño teniendo en cuenta este momento. Según ellos la adopción de nuevas estrategias, nuevos espacios colaborativos de diseño pueden ser explorados en el momento de uso. En muchos casos de diseño de interacción en el museo, el equipo de diseñadores no trabaja durante el proceso de incorporación de la pieza al espacio del museo, sino que su rol termina cuando la pieza interactiva está instalada. Eso imposibilita entender el contexto y encontrar ideas innovadoras para diseños futuros.

Creemos que fue una buena estrategia usar el material proveniente de los talleres como disparador de comentarios entre los visitantes ocasionales. La riqueza y creatividad de los comentarios reunidos se debe en parte a los disparadores que los activaron. Dado que los comentarios incluían el punto de vista de los visitantes, ¿podemos decir que se está construyendo un nuevo museo participativo?. Un museo participativo necesita incluir a los visitantes en el proceso de diseño, desde los primeros bocetos, para que este grupo de co-diseñadores se amplie y no sea solo una colaboración entre el museo y la universidad.

La participación del público sólo se puede medir en función de los comentarios que dejan los visitantes. Sin embargo, podría incluir también otros aspectos relacionados con el interés del público en la exposición, como la lectura de comentarios de visitantes anteriores. Los entrevistados valoran la presencia de los otros visitantes y disfrutan de leer comentarios. Según parece, el público contribuye en mayor medida cuando ve que los comentarios de otros han sido respetados y exhibidos como parte del mensaje de la exposición. Esto es muy diferente a lo que sucede en un libro de visitas donde los comentarios no están expuestos o en las carteleras donde los visitantes pueden escribir pero sobre pequeños papelitos de colores. En este caso los comentarios dejados en el mapa se leían como parte de la exposición.

La participación es un factor de legitimación cuando se relaciona con objetos de la vida diaria como en un museo de diseño y es una manera de que los visitantes y el personal de los museos inicien un diálogo fluido que pueda extenderse más allá de la visita. En muchos museos hay actividades, como talleres, donde esa conversación se inicia. Sin embargo, el diálogo termina junto con el taller. En el caso del proyecto ‘‘La vida secreta de los objetos’’ realizado en el Design Museum Helsinki, nuestro objetivo fue que el diálogo continúe después de la visita.

En este estudio de caso desarrollé estrategias para guiar la producción de contenido consistían en invitar especialmente a diferentes miembros de la comunidad y promover prácticas existentes, como establecer relaciones entre la vida de las personas y la colección del museo. Los talleres llevados a cabo dieron origen a contenidos creativos y personales que influyen en los aportes futuros. Esos talleres fueron una manera de mostrarles a los visitantes que sus aportes eran importantes pero, al mismo tiempo, le demostraron al museo que con otros tipos de invitaciones se pueden incluir en la muestra materiales novedosos y estimulantes, en este caso, poemas y música.

Las prácticas participativas ofrecen enormes posibilidades de ampliar el rol social del museo y también pueden darle un nuevo significado político a una institución cultural tradicional.14 En el futuro, el mapa interactivo de objetos de diseño del Design Museum podría servir de plataforma para una variedad de temas, desde la ética del diseñador y el consumidor hasta proyectos regionales de diseño colaborativo. Los objetivos y el estatus de la interacción con el público dentro de la organización del museo adquieren un carácter central (y este es un debate en curso en el ámbito de los museos). ¿Qué estatus tendrán los documentos producidos por los visitantes? ¿Cómo se preservan y qué valor tienen en la organización del museo?

En el proceso de investigación basada en el diseño, la estrecha colaboración con el departamento de educación del Design Museum fue natural dado el rol tradicional de ese departamento como enlace entre el museo y el público. ¿Cómo pueden integrarse los métodos y herramientas que posibilitan prácticas participativas en todas las prácticas del museo, desde la planificación de una exposición hasta las estrategias de marketing? Las prácticas participativas podrían ser una herramienta que motive a los visitantes a interesarse por la exposición y un recurso en el proceso de diseño.

Referencias

1. Este artículo está basado en la traducción hecha por María Valeria Bech en la residencia Odriozola-Grosman del Instituto de Enseñanza Superior en Lenguas Vivas “Juan R. Fernandez”. L. Su versión original se llamaba Codiseño de prácticas participativas en torno a una exposición del Design Museum. Los autores de la versión anterior de este artículo son Leena Svinhufvud, Andrea Botero, Mirjam Krafft, Hanna Kapanen, Diana DeSousa, Elina Eerola, Anna Louhelainen y Susanna Vakkari.

2. Salgado, M. y A. Kellokoski, “Äänijälki: Opening Dialogues for Visually Impaired Inclusion in Museums”, Proceedings of the International Workshop “Re-Thinking Technology in Museums: towards a new understanding of the people’s experience in museums”, L. Ciolfi, M. Cooke, T. Hall, L. J. Bannon & S. Oliva, eds., Interaction Design Center, University of Limerick, Irlanda, 2005: 10-17.

3. Salgado, M. y L. Díaz-Kommonen, “Visitors’ Voices”, en J. Trant y D. Bearman (eds.) Actas del Congreso Museums and the Web 2006, en Archives & Museum Informatics:[Ver en línea], Toronto, 1 de marzo de 2006. [Fecha de consulta: 15-5-08]

4. Weblog de ‘‘La vida secreta de los objetos’’ (en inglés): [Ver en línea la vida secreta de los objetos]. [Fecha de consulta: 30.05.08]

5. Las traducciones están hechas por mí del finés al castellano.

6. Samis, P. y Pau S., “‘Artcasting’ at SFMOMA: First-Year Lessons, Future Challenges for Museum Podcasters broad audience of use”, en J. Trant y D. Bearman (eds.) Actas del Congreso Museums and the Web 2006, en Archives & Museum Informatics: [Ver actas en línea], Toronto, 1 de marzo de 2006. [Fecha de consulta: 9-5-08]

7. Von Appen, K., Kennedy, B. y Spadaccini, J., “Community Sites & Emerging Sociable Technologies”, en J. Trant y D. Bearman, eds. Actas del Congreso Museums and the Web 2006[Fecha de consulta: 15-5-08]

8. Salgado, M., ‘‘Breaking Apart Participation in Museums’’, en J. Trant y D. Bearman (eds.) Actas del Congreso Museums and the Web 2008, en Archives & Museum Informatics , Toronto, 31 de marzo de 2008. [Fecha de consulta: 9-5-08]

9. Página web con publicaciones relacionadas con ImaNote (en inglés): http://imanote.uiah.fi/ [Fecha de consulta: 30-5-08]

10. Salgado, M. y L. Díaz-Kommonen, op. cit.

11. Duncan, F. C. “The Museum, A Temple or the Forum”, Reinventing the Museum. Historical and Contemporary Perspectives on the Paradigm Shift. Gail Anderson Altamira Press, ed., EEUU., 2004: 61-73.

12. Silverman, D., “Doing qualitative research. A practical handbook”. London: Sage Publications. 2001.

13. Botero, A., Kommonen, K.-H., & Marttila, S., “Expanding Design Space: Design-In-Use Activities and Strategies”. Proceedings of the DRS 2010 Conference. Presented at the Design & Complexity, Montreal, Canada: DRS. 2010. [Descargar .doc], [Descargar PDF] [Fecha de consulta: 15-2-13]

14. Sandell, R., Museums, Prejudice and the Reframing of Difference. Routledge, Nueva York, 2007.

Agradecimientos

En primer lugar, queremos agradecer a todos los participantes de los talleres y a los docentes Rody Van Gemert, Outi-Maria Takkinen, Nana Smulovitz-Mulyana y Onnela Päiväkoti. Un agradecimiento especial a Matti Luhtala, Lily Díaz, Merja Vilhunen, Marianne Aav, Harri Kivilinna, Tommi Jauhiainen, Mikko Laitinen, Ilpo Kari, Atte Timonen y Vennu Nivalainen.

Capítulo 18: Diseño y desarrollo de un editor de texto accesible bajo modalidad open-source, por Nahuel González

Mini biografía del autor

Ingeniero en Electrónica de la Universidad Tecnológica Nacional. Cuenta con más de 15 años de experiencia en el área de tecnología. En el año 2006 crea MANA Desarrollos, una empresa dedicada a la innovación en el área de discapacidad. Diseña dispositivos y software accesible para que todas las mejoras puedan acceder a la información, a la educación y al trabajo. Ha brindado charlas sobre diseño inclusivo en Argentina, Brasil y Turquía. Actualmente se desempeña como Director de MANA Desarrollos, a su vez es docente en el departamento de Electrónica de la Universidad Tecnológica Nacional – Facultad Regional Buenos Aires.>

Más información:

Ingresar al LinkedIn del autor

Traducción: Mariana Inés Calcagno

Diseño y desarrollo de un editor de texto accesible bajo modalidad open-source

Introducción

El diseño de una solución debe involucrar dos conceptos: usabilidad y accesibilidad. A través de su comprensión y correcta implementación podremos lograr que nuestra aplicación sea simple y útil, satisfaciendo así las expectativas del usuario y permitiendo su uso independientemente de las limitaciones funcionales de la persona.

Cuando nos referimos a usabilidad, hablamos de la forma y condiciones de uso por parte de los usuarios, es decir, es una medida de la calidad de la solución [Nielsen, 2012]; este concepto debe ser entendido en relación a usuarios específicos en contextos específicos.

Al tratar el concepto de accesibilidad, se trata de eliminar barreras y que nuestro diseño sea pensado para la diversidad y heterogeneidad de necesidades.

El desarrollo de soluciones open-source permite que ellas puedan ser modificadas, actualizadas y mejoradas por un grupo de personas que no fueron inicialmente los creadores. Este concepto debe utilizarse en los sistemas que tengan como objetivo la creación de herramientas que busquen la inclusión social.

Muchas veces para que un diseño sea accesible se requiere de la incorporación de ayudas técnicas, productos de apoyo o tecnología asistiva. Se trata de elementos como un teclado o mouse alternativos (teclas más grandes, con colores contrastantes, etc.), como así también diferentes formas de realizar la acción de selección, es decir, el click izquierdo (activación por tacto, soplido, pie, pera).

Este artículo plantea la necesidad de diseñar e implementar un editor de texto accesible. A través del trabajo que realizo como profesional en el área de tecnología y discapacidad, he notado las falencias que poseen la mayoría de los programas, y los problemas a los que se enfrentan los usuarios para poder interactuar con el software.

Marco teórico

El diseño centrado en el usuario (DCU) [Norman, 1986] es una filosofía de diseño que persigue la satisfacción de las necesidades de los usuarios con el mínimo esfuerzo de su parte.

El DCU nos invita a preguntarnos acerca de quiénes serán los usuarios, cuáles son sus objetivos o metas, qué herramientas y qué información necesitan para satisfacer sus objetivos.

Olga Carreras Montoto nos plantea en su trabajo “La usabilidad como metodología para el desarrollo de una aplicación”, la existencia de cuatro etapas: plan, análisis, diseño y evaluación, que permitirán llevar adelante una metodología de trabajo para lograr los objetivos planteados.

Yusef Hassan Montero y Sergio Ortega Santamaría, en el “Informe APEI sobre Usabilidad”, describen tres conceptos asociados al DCU: el modelo conceptual (es el que realiza el diseñador del software), la interfaz (imagen que se le presenta al usuario a través del sistema) y el modelo mental (creado por el usuario a través de esa imagen).

Podemos ver al diseño centrado en el usuario como un sistema realimentado que tomará información a través de la participación del usuario y su observación (salida). Dicha información se inyectará en el equipo de trabajo (entrada), el cual tomará decisiones acerca de las mejoras a efectuar. El DCU es un proceso repetitivo que permitirá obtener una mayor satisfacción por parte de los usuarios, a partir de contar con mayor cantidad de opiniones que posibiliten un diseño más inclusivo.

El diseño centrado en el usuario aplicado al desarrollo de productos de apoyo se encuentra apoyado en tres ejes: la necesidad del paciente, el equipo de trabajo de profesionales de la salud (terapista ocupacional, fonoaudióloga, estimuladora visual, maestra integradora, etc.) y el diseñador tecnológico (ingenieros, diseñador industrial, desarrollador de software, etc.).

Objetivos y metodología

A partir del relevamiento de necesidades de algunos pacientes se planteó la necesidad de desarrollar un software de edición de textos que permitiese la interacción del usuario independientemente de si posee o no limitaciones funcionales.

Se investigó acerca de los programas existentes analizando sus ventajas y desventajas [Sánchez Caballero, 2010]. Se encontró que la mayoría atendían a una necesidad o a un conjunto acotado de necesidades.

A partir del trabajo conjunto de un equipo multidisciplinario se generó un listado de necesidades a las que debía atender el software:

Mecanismos alternativos para la escritura (uso de teclado, uso de mouse, uso de producto de apoyo).

Mecanismos para aumentar la velocidad de escritura.

Reproducción oral del texto escrito.

Facilidades para interactuar (generar un documento nuevo, abrirlo, guardarlo, etc.).

Resultados

Desarrollo del sistema

Se desarrolló una aplicación de escritorio que cumple con las funcionalidades de un editor de texto accesible (figura 2). Este fue desarrollado utilizando C# como lenguaje de programación y mySQL como motor de base de datos.

El modelo de programación orientada a objetos facilitó el desarrollo de perfiles de forma que cada texto se adecue de acuerdo a las posibilidades de cada persona.

A su vez, se desarrolló un sistema de predicción de palabras que permitió reducir los tiempos de escritura a los usuarios.

El sistema creado permite ser utilizado mediante:

Un teclado convencional o adaptado

Un mouse convencional o adaptado

Un switch activado por diferentes medios (mano, pie, boca, pera, soplido)

A su vez cuenta con predicción de palabras y utilización de frases habituales. Puede complementarse con sintetizadores de voz (open-source) de forma que pueda reproducirse en forma oral el texto escrito. A través de menúes simples o íconos permite generar un nuevo documento, abrirlo, editarlo, guardarlo, como así también ajustar el tamaño con el que se visualiza el texto escrito.

La aplicación se ejecuta en pantalla completa. A través de la información suministrada por el sistema operativo en relación a la resolución de la pantalla, el contenido se ajusta de forma de lograr una mejor experiencia por parte del usuario (responsive design). Los controles se ajustan y se redistribuyen de forma que pueda mostrarse la información sin necesidades de tener una versión para cada tipo de resolución.

Dentro de las opciones de configuración, al comenzar a trabajar, el usuario o un asistente genera un perfil, es decir, el conjunto de opciones que permitirán que la persona se encuentre cómoda al utilizar el sistema. Entre estas opciones se pueden destacar:

Color de fondo de la aplicación

Color de los botones

Color de las letras

Color del texto

Color del fondo donde se presenta el texto

Tipo de teclado en pantalla a utilizar (qwerty o alfabético)

Velocidad de barrido (en el caso de utilizarlo)

Realimentación visual de la opción elegida

Si utiliza síntesis de voz o no y su correspondiente configuración

Realimentación sonora de la opción elegida

Carpeta donde almacenará sus documentos

Si posee documentos previamente creados y desea importarlos

Configuración de colores y tipografía

Como se ha mencionado, el sistema permite generar un perfil sobre las opciones de preferencia del usuario, entre las cuales se encuentran los colores, tipo de letras y tamaño de las letras y texto.

Configuración del tipo de teclado

El usuario puede optar por dos tipos de teclados estándar y de distribución alfabética. A lo largo de diferentes pruebas, quienes poseían lecto-escritura y no habían sufrido algún tipo de daño cognitivo prefirieron utilizar la distribución convencional.

Tipo de teclado en pantalla a utilizar (qwerty o alfabético)

Velocidad de barrido (en el caso de utilizarlo)

Realimentación visual de la opción elegida

Si utiliza síntesis de voz o no y su correspondiente configuración

Realimentación sonora de la opción elegida

Carpeta donde almacenará sus documentos

Si posee documentos previamente creados y desea importarlos

Una vez establecidas las preferencias del usuario, podrán ser editadas en el momento en que se requiera.

Abrir un documento

Al abrir un documento, el sistema nos permite obtener un listado ordenado por fecha de modificación de los archivos que el usuario creó con este editor o que haya importado (por haberlos creado previamente).

Guardar un documento

Al guardar un documento, si el usuario posee configurado el teclado en pantalla en lugar del teclado convencional, se abre una ventana que permite que se escriba el nombre del archivo por primera vez (“guardar como”). Luego bastará con seleccionar la opción Guardar o el ícono correspondiente.

Agregar nuevas palabras

Si al utilizar el sistema, la palabra no se encuentra dentro de la base, el sistema nos brinda la opción de agregarla. Al hacerlo el sistema aumentará el puntaje de esta palabra para que el usuario deba realizar menor cantidad de acciones la próxima vez que la utilice para poder seleccionarla.

Configuración y utilización de frases

La configuración de frases permite alterar el orden de ellas, editarlas, eliminarlas y solo dejar frases que se ajusten a las necesidades de cada persona. Para poder acceder a las frases se utiliza el botón o ícono de frases. Las frases se muestran en grupos de cinco y luego se cuenta con dos botones para poder recorrer todo el listado.

Configuración y utilización del barrido

El barrido es un sistema que se utiliza cuando el usuario posee movimientos disminuidos o acotados. En lugar de mover el mouse o utilizar un teclado convencional, las opciones se “ofrecen” al usuario de forma que puede “elegir” cual utilizar. Esta elección se realizará generalmente mediante un switch, que puede ser activado de diferentes formas tal como se describió previamente. Uno de los aspectos más importantes es que esta velocidad con la cual se le ofrecen al usuario las diferentes posibilidades sea configurable. Esta velocidad inicialmente se planteó en forma cuantitativa con diferentes pasos; a través del uso del sistema por parte de los usuarios se obtuvo una mejor apreciación al enmarcarlo dentro de dos límites (lento y rápido). Esta cota permitió que la persona entendiese más fácilmente dentro de los parámetros en los que se iba a mover. El valor que se indicaba previamente (número) no era representativo para los usuarios.

Acceso a símbolos y números

Para un mejor aprovechamiento del espacio disponible en la interfaz, se diseñó un acceso directo a los símbolos y números de forma que reemplacen en forma momentánea a las letras solo en el momento en el que el usuario necesita acceder a estos.

Utilización del sistema con barrido

Dentro de las posibilidades que posee el sistema se encuentra su uso a través de la técnica de barrido. A medida que el cursor se desplaza se van encendiendo en forma secuencial las letras que se encuentran en la primera fila, luego en la segunda fila y así sucesivamente. A medida que se seleccionan las letras, comienza a trabajar la predicción de palabras de forma que en el sector superior se van mostrando las palabras disponibles. Al seleccionar una de estas palabras se autocompletan las letras restantes dentro del texto.

Casos de uso

El sistema diseñado ha sido utilizado y evaluado por 21 personas con discapacidad. A través de la información suministrada por cada uno y por su entorno (familia, terapistas ocupacionales, asistentes, etc.) se realizó un listado de mejoras a realizar.

Hoy el sistema se encuentra en su versión 2.0 y entre los usuarios podemos destacar a un estudiante de la Universidad Nacional de Santiago del Estero de la carrera de Ciencias Económicas, que requería de un software que permitiese realizar preguntas a los docentes en forma oral ya que él no podía expresarse de esa manera.

Otro caso fue el de un adulto joven con esclerosis lateral amiotrófica (ELA) que a través de un switch activado con la pera utilizó el sistema para poder comunicarse con su familia y escribir su biografía.

Un tercer caso es el de una joven estudiante de psicopedagogía de la Provincia de Buenos Aires que lo utilizó para poder tomar apuntes velozmente y organizarse para cada materia en particular con una estructura sencilla. La predicción de palabras y frases fue vital para su desempeño.

Un último caso es el de un adulto mayor con ELA que utilizaba el sistema para comunicarse con su psicóloga y con sus nietos. A través de un switch capacitivo activaba el sistema de barrido y hacía uso del software.

Discusión

En base a los resultados obtenidos a lo largo del desarrollo y en su implementación, se ha evaluado la migración del presente sistema para que pueda ser utilizado en Linux y en teléfonos inteligentes.

Hoy por hoy, se estná evaluando las herramientas para poder realizar dicha migración; entre ellas podemos destacar el proyecto mono que permite ejecutar CLI en Linux.

En futuras versiones, se espera poder incorporar dentro de las opciones de configuración del usuario el tipo de botones que desea utilizar por ejemplo, basado en texto, en imagen (ícono) o en una combinación.

A su vez, se prevé la incorporación de herramientas de comunicación aumentativa alternativa que permitan su utilización como parte de un proceso de rehabilitación en el caso de personas con afasia.

Conclusión

El desarrollo de sistemas debe contemplar las necesidades del usuario a través de una visión global. La proporción de personas con discapacidad está aumentando notoriamente, particularmente debido al envejecimiento de la población (expectativa de vida) y las enfermedades crónicas a nivel mundial.

El desarrollo de aplicaciones que persigan como objetivo la inclusión social debe ser en un contexto de software open-source de forma que las mismas puedan ser modificadas y mejoradas para satisfacer necesidades que inicialmente no fueron contempladas.

El diseño centrado en usuarios permite que un equipo multi-disciplinario pueda trabajar con una metodología simple y así juntos lograr comprender los problemas a resolver de forma global.

Bibliografía

Carreras, Olga (2007), La usabilidad como metodología para el desarrollo de una aplicación. [Ver en línea Olga Carrera 2007]

Hassan Montero, Yussef, y Ortega Santamaría, Sergio (2009), Informe APEI sobre Usabilidad. Diseño centrado en el usuario

Nielsen, Jakob (2012), Usability 101: Definitions and Fundamentals

Norman, Don (1986), New Perspectives on Human-Computer Interaction.

Sánchez Caballero (2010), Software libre y accesibilidad

Capítulo 19: Las métricas de accesibilidad desde una perspectiva práctica: eXaminator, por Carlos Benavidez

Mini biografía del autor

Diseñador, Programador y Desarrollador para la web con respeto de estándares de Accesibilidad y Diseño Universal. Profesor de DIEAU: Especialización en Diseño de Interacción con estándares de accesibilidad y usabilidad de la Universidad Tecnológica Nacional. Integra el equipo de Investigación-Acción Sinapsis que depende de DIEAU - UTN. Es Presidente de la Cooperativa de Trabajo Interacción Accesible - IACoop.

Las métricas de accesibilidad desde una perspectiva práctica: eXaminator

Introducción

Los documentos denominados Pautas de Accesibilidad al Contenido en la Web (WCAG) 1 explican cómo hacer que el contenido Web sea accesible para todos los usuarios, incluyendo a las personas con discapacidad. Las WCAG 2.0, publicadas en diciembre de 2008, definen 4 principios que proporcionan los fundamentos de la accesibilidad web: perceptible, operable, comprensible y robusto. Por debajo de los principios hay doce pautas que proporcionan los objetivos básicos que los autores deben lograr con el fin de crear un contenido más accesible.

Para cada pauta se proporcionan criterios de conformidad verificables organizados en tres niveles de conformidad: A (el más bajo), doble A y triple A (el más alto). Para que una página web sea conforme con las WCAG 2.0, se deben satisfacer por completo uno o más de estos niveles de conformidad. El grupo de trabajo de las WCAG 2.0 ha documentado también una amplia variedad de técnicas para cada uno de los criterios de conformidad. Las técnicas son informativas y se agrupan en dos categorías: aquellas que son suficientes para satisfacer los criterios de conformidad y aquellas que son recomendables. También se identifican los fallos más comunes.

De esta manera, existe una compleja trama de técnicas de evaluación que requieren ser revisadas individualmente, con el fin de determinar si una página web logra la conformidad mínima con las WCAG 2.0 (el nivel A). Se debe usar el mismo procedimiento con todos los criterios de conformidad de nivel doble A para determinar si la página logra el nivel doble A y lo mismo sucede con el nivel triple A.

Conformidad con las WCAG 2.0

Para evaluar la conformidad con las WCAG 2.0 se requieren pruebas manuales y el juicio de evaluadores experimentados, porque las herramientas de evaluación de accesibilidad web solo pueden comprobar automáticamente un número limitado de requisitos de accesibilidad. Por evaluador experimentado se entiende una persona que domina las Pautas de Accesibilidad, el diseño de páginas web, las ayudas técnicas y conoce cómo usan la web las personas con distintos tipos de discapacidad.

Es fácil advertir que la evaluación minuciosa de una página web supone un costo elevado ya que debe ser llevada a cabo por un profesional experto en accesibilidad dedicando varias horas de trabajo, considerando no solo la revisión de todas las técnicas sino también la redacción de los informes y recomendaciones necesarias para corregir los errores que se detecten.

Este costo debe multiplicarse por el número de páginas del sitio a evaluar. Como generalmente no es factible evaluar cada una de las páginas de un sitio web, en la Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) 2 se especifican los pasos concretos para definir el alcance de la evaluación, cómo seleccionar una muestra representativa de páginas, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

Evaluaciones automáticas

Algunas herramientas, como Hera 3, sirven de apoyo al proceso de evaluación de un experto. Estas herramientas ofrecen resultados fiables para una serie de pruebas y pueden no solamente acelerar el proceso efectuando determinadas tareas de forma automática, sino también indicar los aspectos donde los evaluadores expertos deben centrar su evaluación.

Por el contrario, eXaminator está diseñada para evaluar grandes cantidades de páginas y tiene un funcionamiento autónomo, ya que en el trabajo masivo no resulta posible la intervención de un experto por la lentitud de las evaluaciones manuales y los altos costos que suponen.

Los proyectos de evaluación global de la accesibilidad web son necesarios para obtener información acerca del estado y evolución de la accesibilidad de los sitios dentro de un dominio específico o de una determinada ubicación geográfica.

Un proceso sistemático y continuo de evaluación de los sitios web no solo ayuda a explorar el nivel global de accesibilidad de los sitios sino que también permite hacer estudios comparativos y alentar a la mejora de los procesos.

Un primer problema a resolver cuando usamos un sistema automático para realizar evaluaciones masivas, comparar los resultados entre los sitios y monitorear la evolución de esos resultados, lo constituye la necesidad de contar con una métrica cuantitativa en reemplazo de la métrica ordinal de las WCAG 2.0.

Métricas de accesibilidad

Para medir la conformidad, las WCAG 2.0 usan una escala ordinal que jerarquiza los criterios de conformidad de acuerdo a un rango (niveles A, doble A y triple A). Los criterios de nivel A son aquellos que, de no cumplirse, pueden provocar que ciertos grupos de usuarios no puedan acceder a la información; por esa razón el nivel A es el mínimo exigible.

Los criterios de nivel doble A son aquellos que pueden hacer muy difícil el acceso a los contenidos a determinados grupos de usuarios y los de nivel triple A son los que pueden crear algunas dificultades a ciertos usuarios.

Pero esto no significa que todos los criterios de determinado nivel de conformidad afecten por igual a todos los usuarios. La ausencia de textos alternativos en los elementos no textuales es un error de nivel A porque los usuarios de lectores de pantalla, que no pueden ver la página, no tienen ninguna otra forma de saber qué información contienen los elementos no textuales; pero hay otros usuarios, con otros tipos de discapacidad, para quienes la falta de textos alternativos no representa ningún inconveniente.

El problema con la escala ordinal de las WCAG 2.0 es su falta de sensibilidad: un sitio que cumple solo con los criterios de conformidad de nivel A y ninguno de nivel doble A, obtendría el mismo valor de accesibilidad que otro sitio que cumple con todos los criterios de nivel A, y casi todos los de nivel doble A. La falta de precisión de esta escala tampoco permite conocer cuánto le falta a un sitio que cumple con el nivel A para alcanzar el nivel doble A.

Para resolver la falta de sensibilidad de la escala ordinal, eXaminator usa una escala numérica de 1 (la puntuación más baja) a 10 (la más alta), logrando que cualquier cambio producido en el contenido de una página provoque un cambio en los resultados, aunque se debe advertir que el paso de una escala ordinal a una escala numérica no se puede lograr sin cierto grado de arbitrariedad.

Por ejemplo, podemos definir una nota subjetiva para la falta de textos alternativos, pero no disponemos de un criterio válido para decidir la relación con errores de otro tipo (por ejemplo, la falta de contraste de los colores de la página) que afectan en distinto grado a otros grupos de usuarios.

Entonces, una primera advertencia es que la accesibilidad no es una cualidad que se pueda medir con valores absolutos y la nota de eXaminator solo se puede considerar un indicador aproximado del estado de la accesibilidad de una página que se utiliza al solo efecto de contar con una escala más sensible y precisa para realizar las comparaciones.

Además, en las evaluaciones de accesibilidad a gran escala es importante que los resultados individuales se puedan resumir en un resultado final que resulte fácil de comprender y tenga una clara interpretación. De este modo se hace posible comparar la situación de los diferentes sitios web o para investigar las diferencias entre distintas versiones de una misma página web.

Limitaciones de las herramientas automáticas

La principal limitación de las evaluaciones automáticas es que solo pueden comprobar la conformidad de un pequeño subconjunto de criterios de conformidad. Existen también criterios que pueden ser evaluados parcialmente pero la mayoría de las técnicas que deben ser revisadas necesitan del juicio de un experto.

La batería de pruebas de eXaminator no está conformada por las pruebas más importantes, sino por aquellas que se pueden resolver automáticamente; esto lleva a que coexistan pruebas muy significativas con otras de menor valor. Un problema adicional es la cantidad de pruebas que se pueden realizar en cada página.

En la web encontramos páginas de gran tamaño, con muchos elementos, junto a pequeñas páginas, con unas pocas líneas de código. La estructura de cada página determina cuántas pruebas se pueden hacer sobre ella, de modo que ciertos documentos recibirán más de veinte pruebas, y habrá otros a los que solo se les podrán efectuar cuatro o cinco pruebas. El problema con esto es que un mismo error tendrá mayor influencia en el promedio general a medida que disminuya el número total de pruebas posibles.

Por otra parte, ya no es común la elaboración por parte de un diseñador de todas y cada una de las páginas de un sitio sino que se usan gestores de contenidos u otros sistemas con plantillas prefabricadas hechas por otros diseñadores. En sitios de cierta envergadura trabajan equipos de personas y hay muchas manos añadiendo o modificando contenidos. Todo esto hace que las páginas tengan una calidad de diseño variable entre sus secciones y las pruebas automáticas pueden coincidir en mayor medida con una u otra sección.

Para evitar que las limitaciones mencionadas sean un factor de desviación de los resultados, es conveniente trabajar con grupos de páginas de un mismo sitio porque así las excepciones y desproporciones que pueden darse en algunas páginas individuales pierden su relevancia y las estadísticas generales resultan indicios más confiables sobre el estado de la accesibilidad.

Se debe tener en cuenta que las calificaciones no miden la accesibilidad general sino el desempeño del grupo de páginas evaluadas con respecto a las pruebas que realiza la herramienta. En general, la experiencia demuestra que se pueden obtener buenos indicios sobre la accesibilidad pero no se puede asegurar que el 8 de un sitio web represente el mismo grado de accesibilidad que la misma nota en otro sitio.

Más importante que la magnitud de las calificaciones es la posibilidad de establecer un marco de referencia con las puntuaciones máximas y mínimas en una muestra de sitios o en los resultados de un mismo sitio a lo largo del tiempo. Es decir, una calificación de 3 para un sitio adquiere mayor importancia si existe otro, dentro de la muestra analizada, con una puntuación de 9. Del mismo modo, si un sitio obtiene un 5 en un determinado momento, esa nota no es tan significativa como la variación que obtendrá cuando se realice la misma evaluación cierto tiempo después.

Las notas tienen el propósito de ordenar y comparar los resultados de grupos de páginas y de sitios web pero la mayor utilidad de las evaluaciones automáticas es que permiten detectar los errores más habituales y poner en evidencia algunos procedimientos erróneos que suelen pasar desapercibidos cuando solo se revisan las páginas individualmente.

Información técnica

Descartada la posibilidad de evaluar automáticamente la conformidad con las Pautas de Accesibilidad, el objetivo principal de eXaminator es obtener el mayor número de pruebas sobre la correcta aplicación de las técnicas recomendadas por las WCAG 2.0.

Con ese propósito, evalúa tanto situaciones negativas como positivas porque se considera que, a los fines de la obtención de indicios sobre la correcta aplicación de las técnicas, la detección de algunas buenas prácticas puede resultar tan valiosa como la comprobación de los errores.

Otras métricas, como la Métrica Cuantitativa de la Accesibilidad Web (WAQM) 4 y la aplicada por la Metodología Unificada de Evaluación Web (UWEM) 5, se basan en la tasa de fallo, es decir, la relación entre el número de errores encontrados y el total de pruebas realizadas. De este modo, la puntuación disminuye cuando una prueba falla más a menudo.

Un inconveniente de las métricas que miden la tasa de fallo es que la fórmula de cálculo (número de errores / total de pruebas) se adecua solo a aquellos casos en los que podemos identificar el total de pruebas, de modo que el número de errores es siempre una porción de ese total. Por ejemplo, en la prueba sobre los textos alternativos de las imágenes, el total de pruebas es el número de imágenes revisadas y el número de errores son las imágenes sin el atributo alt.

La tasa de fallo no se puede aplicar en aquellos casos en los que no existe un número total de pruebas, por ejemplo, en la validación de código HTML de una página. En esos casos, conocemos el número de errores pero no existe un total de pruebas que nos permita calcular el porcentaje de fallos. En otros casos, simplemente no es sencillo determinar el total de pruebas: en la revisión de los atributos HTML obsoletos se podría considerar como total el número de elementos de las páginas o solo el número de elementos que tienen asignados atributos HTML.

En WAQM no se explicita cómo se resuelven estos casos dudosos pero UWEM considera como total de casos el número de errores de validación, o cero si no existen errores. Del mismo modo, considera como total el número de atributos HTML obsoletos, o cero si no se usa ninguno de estos atributos. La consecuencia es que esas pruebas tienen siempre un resultado binario, ya que será cero si no existen errores y uno cuando los hubiera.

Para sortear estas dificultades, eXaminator apela a distintas fórmulas para resolver los resultados. Estas fórmulas definen 4 tipos de pruebas que se aplican en cada caso de modo tal que las calificaciones se correspondan con estos juicios de valor:

Muy mal: 1

Mal: 2 o 3

Regular: 4 o 5

Bien: 6 o 7

Muy bien: 8 o 9

Excelente: 10

Las calificaciones son empíricas, de modo que existe un componente subjetivo en las decisiones y también un cierto grado de arbitrariedad. La escala anterior sirve como guía para determinar las calificaciones pero decidir si un error merece 3 o 5 es siempre discutible.

La repetición de los errores es un dato importante que se debe tener en cuenta en las calificaciones. Un único error se puede deber a un desliz pero varios errores del mismo tipo indican claramente un concepto equivocado de diseño o un gran descuido en el desarrollo. Además, las barreras de accesibilidad aumentan en proporción directa al número de errores.

Cuando existe un total de pruebas bien definido, como es el caso de las imágenes y el atributo alt, se utiliza la tasa de fallo para que la calificación resulte menor cuanto mayor es la cantidad de errores detectados. Para los errores de validación, por ejemplo, se aplica otra fórmula que también disminuye la nota a medida que aumenta el número de errores pero en este caso la escala de disminución es fija.

También hay pruebas que solo pueden tener resultados binarios. Por ejemplo, el error que consiste en usar el elemento meta para refrescar la página solo puede tener dos resultados: bien o mal. En otros casos la contabilización de los errores, aunque posible, no es significativa. Por ejemplo, el uso del elemento marquee es un error grave porque provoca movimientos en el contenido, es un elemento anticuado, no estándar y su uso denota un concepto pobre de diseño. Por eso, poco importa que se use uno o más veces y simplemente merece ser calificado siempre con la nota más baja.

En el cálculo se debe tener en cuenta que no todas las pruebas tienen la misma importancia, de modo que es necesario ponderarlas para que su peso relativo refleje esas diferencias. La Ponderación (P) es el producto del grado de Confianza (C) y el Valor relativo de la prueba (V):

P = C × V

Valor

Indica la importancia relativa de las pruebas de acuerdo al grado en que las situaciones evaluadas pueden afectar a los usuarios. El problema para hacer estas valoraciones es que en accesibilidad no disponemos de un usuario tipo al que podamos tomar como referencia sino que debemos considerar una muy amplia gama de posibilidades.

Para superar esta dificultad, se definieron 5 perfiles de usuarios que reflejan las principales barreras de acceso presentes en la web. Los perfiles seleccionados corresponden a usuarios con:

Limitación total para ver

Limitación grave para ver

Limitación para controlar los miembros superiores

Limitación para comprender

Limitaciones derivadas del envejecimiento

En estos perfiles se intenta incluir a las personas con discapacidad y también a quienes, por razones tecnológicas o de entorno, se encuentran con limitaciones similares. Cada prueba recibe una valoración distinta en cada perfil de usuario de acuerdo con la siguiente escala:

Indiferente. La técnica no afecta al usuario.

Prudente. La técnica puede beneficiar al usuario.

Útil. La técnica resulta de ayuda para el usuario.

Importante. La técnica es importante para el usuario.

Esencial. La técnica es esencial para el usuario.

Confianza

Indica la seguridad que se le otorga a las pruebas. En una escala de 0 a 1, todas las pruebas de eXaminator merecerían un valor muy alto porque aquellas que no ofrecen una alta seguridad de no fallar son descartadas y por eso se toman en cuenta los pasos indicados en los procedimientos de revisión de las técnicas relacionadas para definir la confianza de cada prueba.

Por ejemplo, si el primer enlace de la página tiene como referencia un ancla en la propia página, la técnica G1 6 de las WCAG 2.0 (“Agregar un enlace al principio de cada página que lleve directamente al área de contenido principal”) parece satisfecha pero, observando los procedimientos de revisión manual, vemos que faltaría verificar manualmente si el enlace es siempre visible, si el texto del enlace es correcto y si efectivamente el salto es hacia el contenido principal.

Por cada uno de esos pasos que no es posible verificar automáticamente se disminuye 0.1 y la confianza de la prueba G1 será 0.7. Este criterio no es estricto pero proporciona la estrategia necesaria para resolver con cierta coherencia la confianza de cada prueba.

Tipos de prueba

Para definir los resultados de las pruebas, eXaminator utiliza una matriz de datos con la siguiente información:

Elemento (E)

Identifica un elemento del lenguaje HTML o un conjunto de estos elementos. Por ejemplo, el elemento Controles de formulario que requieren etiquetas asociadas comprende a los input de tipo text, checkbox, radio, file y password, más los elementos textarea y select. La prueba es aplicable solo cuando el elemento existe en la página. El elemento all es especial e indica que la prueba resulta siempre aplicable.

Situación (S)

Identifica un elemento del lenguaje HTML o un conjunto de estos elementos que cumplen determinada condición. Siempre se trata de un subconjunto de elemento, excepto cuando el elemento es all. Se debe encontrar al menos una situación para que la prueba sea aplicable, excepto en las pruebas de tipo falso, en las que se aplica cuando no se encontró ninguna situación en la página.

Nota (N)

Es la calificación de la prueba. En las pruebas de resultado variable, es la calificación inicial a partir de la cual se efectuarán los cálculos posteriores. En otras palabras, es la calificación que se aplica a la primera situación detectada.

Tolerancia (T)

En las pruebas de tipo decreciente indica el umbral de tolerancia a los errores, es decir, el valor a partir del cual se comenzará a disminuir la nota inicial.

Fracción (F)

En las pruebas de tipo decreciente indica la cantidad de errores que disminuyen en un punto la nota inicial. Tolerancia y Fracción son datos exclusivos para las pruebas de tipo decreciente en las cuales cada situación identifica siempre un error.

Pruebas de tipo verdadero/falso

Ambas pruebas consisten en evaluar una condición y, si esa condición se cumple, el Resultado (R) es el producto de la Nota (N) y la Ponderación (P):

R = N × P

Ambas pruebas son idénticas en todo sentido excepto que la condición se debe evaluar como verdadera en un caso y como falsa en el otro para que la prueba resulte aplicable.

Prueba de tipo proporcional

En esta prueba, la nota inicial disminuye en proporción al cociente entre Situación (S) y Elemento (E).

R = N × (1 - S/E) × P

Por ejemplo, en la prueba sobre las alternativas textuales en las imágenes, el Elemento (E) son las imágenes y la Situación (S) son las imágenes sin alt. La prueba es aplicable cuando existen ambos. La Nota (N) es la calificación inicial atribuida a este tipo de errores (en esta prueba la nota es 3 porque se considera que está mal sin importar cuántas imágenes sin alt se encuentren).

Pero la calificación puede aun ser menor si consideramos la extensión de los errores. Entonces, se calcula la tasa de fallo y luego el porcentaje a sustraer de la nota inicial. Si las imágenes son 8 y hay 4 sin alt, sin tomar en cuenta la ponderación, el cálculo sería:

R = 3 × (1 - 4/8) = 3 × (1 - 0.5) = 3 × 0.5 = 1.5

La calificación inicial (3) se reduce a la mitad (1.5) porque el error está presente en el 50% de las imágenes encontradas.

Prueba de tipo decreciente

En esta prueba, la nota inicial va disminuyendo a medida que aumenta la cantidad de errores. La Tolerancia (T) indica cuántos errores se permiten antes de comenzar a restar de la nota; superado el umbral de tolerancia, cada Fracción (F) disminuye en un punto la nota inicial.

R = (N - (S - T) / F) × P

Por ejemplo, cuando existen errores de validación, la nota inicial es 5 y la tolerancia es 10. Es decir, se considera que hasta 10 errores de validación es una situación que se puede calificar como regular (la tolerancia es bastante alta por el efecto de arrastre que tienen algunos errores). Si existen más de 10 errores, la nota comienza a disminuir 1 punto por cada fracción, que en esta prueba también es de 10. Suponiendo que encontramos 40 errores, sin tener en cuenta la ponderación, sería:

R = 5 - (40 - 10) / 10 = 5 - 30 / 10 = 5 - 3 = 2

Entonces, la calificación es 5 cuando existen entre 1 y 10 errores; con 40 errores la nota baja a 2 y así, si se encuentran más de 50 errores de validación la nota sería 1, la mínima.

Promedios

Por último, el resultado de la puntuación de una página es la división de la sumatoria de las pruebas realizadas por la sumatoria de las respectivas ponderaciones. Por ejemplo, si se consideran solo 2 pruebas: la prueba A con ponderación 1 y la prueba B con ponderación 0.1, la sumatoria de las ponderaciones es 1.1.

Si la nota en ambas pruebas es 9, la puntuación final será, lógicamente, 9. El resultado ponderado de la prueba A es 9 (9 × 1) y el de la prueba B es 0.9 (9 × 0.1). La sumatoria de las pruebas ponderadas es 9.9 (9 + 0.9), que al dividirla por la sumatoria de las ponderaciones (1.1) nos da 9 (9.9 / 1.1).

Si la prueba A tuviera un 2 como nota, de modo que la nota ponderada fuera 2 (2 × 1) y la sumatoria de las pruebas fuera 2.9 (2 + 0.9), la puntuación sería 2.6 (2.9 / 1.1) luego de redondear el resultado. Pero si es la prueba B la que tiene 2, la sumatoria de las pruebas nos daría 9.2 (9 + 0.2) y la puntuación sería 8.4 (9.2 / 1.1).

Con este ejemplo muy sencillo se puede apreciar la importancia de la ponderación de las pruebas. Si promediáramos simplemente las notas 9 y 2, obtendríamos 5.5 pero así estaríamos poniendo en un mismo nivel a las dos pruebas cuando las ponderaciones indican que la prueba A tiene un valor muy alto y es de máxima confianza, mientras que la prueba B es mucho menos significativa. Entonces es lógico que la prueba B tenga un peso mucho menor en la puntuación final. Observen que al promediar A, que tiene una nota de 2, con B, que tiene 9, la puntuación final es 2.6, es decir, el promedio queda muy cerca de 2, que es la nota de la prueba con mayor ponderación.

En términos prácticos, las ponderaciones permiten establecer un necesario balance entre las pruebas e impiden que el resultado de una página dependa de una sola prueba, tal vez inexacta. Para obtener una mala puntuación el balance de las pruebas debe ser claramente desfavorable. Es necesario que se detecten varios errores y, por el contrario, que no se detecten buenas prácticas en la cantidad y con la ponderación suficiente como para compensar esos errores. No se puede atribuir a la casualidad una puntuación muy baja así como una puntuación muy alta difícilmente se consiga por un golpe de suerte.

Promedio general

Todas las operaciones descriptas anteriormente sirven para obtener una calificación para cada uno de los perfiles de usuarios. Del mismo modo, en el informe de resultados se indica la importancia que tiene cada prueba para cada uno de los perfiles. Finalmente, la calificación final de la página se obtiene del promedio simple de las cinco calificaciones parciales.

Esta estrategia tiene dos propósitos principales. En primer lugar sirve para identificar los tipos de usuarios que se ven afectados por cada técnica, indicando también en qué medida son afectados. Si bien esta información se puede obtener leyendo la documentación de las pautas, es más evidente y pedagógico si cada resultado incluye las valoraciones por tipos de usuarios.

Las calificaciones por tipos de usuarios permiten, además, realizar estudios sobre la accesibilidad de un determinado sector de la web con relación a uno o más perfiles de usuarios. Por ejemplo, una asociación de personas con discapacidades neurológicas podría investigar el grado de accesibilidad de los periódicos en línea para las personas con limitación para comprender y recomendar a sus asociados los sitios con mejores calificaciones.

Documentación y ayuda

La calificación es solo un indicador cuyo objetivo es, principalmente, ordenar y comparar las evaluaciones de grupos de páginas pero esta función básica se complementa, en eXaminator, con una detallada información sobre cada una de las pruebas realizadas.

Como las pruebas se relacionan directamente con una técnica de las WCAG 2.0, eXaminator proporciona enlaces a los documentos de esas técnicas y a los de los Criterios de Conformidad relacionados. También identifica y señala en las páginas los elementos revisados. Esto no solo permite detectar los errores y ayuda a corregirlos sino que también sirve para comprobar si la información proporcionada por la herramienta es correcta.

La documentación y ayuda adicional que proporciona eXaminator permite que se la use para reparar los errores de accesibilidad de un sitio. En estos casos puede resultar necesario establecer objetivos de trabajo y las puntuaciones resultan un parámetro tentador porque permiten establecer metas claramente definidas: se puede poner como objetivo que todas las páginas del sitio alcancen una puntuación mínima de 7, por ejemplo.

El problema es que no se puede usar la puntuación de un modo escolar, considerando que alcanza con 4 o 6 para aprobar la materia. Para establecer objetivos precisos es más útil concentrarse en la corrección de los errores más importantes o, incluso, de los errores más fáciles de corregir.

El informe de resultados incluye una tabla que muestra el detalle de las pruebas efectuadas, la nota de cada prueba y su ponderación. Esta información permite evaluar cuáles son los errores más importantes y fijar estrategias para el trabajo futuro. También puede servir para llevar un registro del avance de esos trabajos comparando las tablas de una misma página en dos momentos distintos.

Arquitectura de programación

eXaminator está programado en PHP y hace un uso intensivo de la extensión DOM y la clase DOMXPath para revisar la estructura de las páginas. El proceso de revisión tiene tres etapas bien definidas:

Petición de la página

eXaminator actúa como un cliente HTTP para obtener las páginas web mediante el método GET usando fsockopen o, alternativamente, cURL. Aunque con capacidades más limitadas que un navegador web, tiene soporte para un subconjunto de funciones útiles para comunicarse eficientemente con los servidores web.

Una vez obtenida la página solicitada, se extrae alguna información de las cabeceras HTTP y se separa el cuerpo de la respuesta para su procesamiento. La información se guarda en una matriz que almacenará todos los datos de la página, incluyendo las pruebas y los resultados completos.

Análisis de la página

Para el análisis de la página web se utiliza la extensión DOM de PHP5. El DOM proporciona un modelo abstracto del documento y una interfaz estándar para acceder a los objetos de la página y sus propiedades.

Como paso previo a la obtención del DOM se realizan algunas operaciones como la eliminación del BOM (Byte Order Mark) que suelen contener algunos documentos codificados en UTF-8. Para obtener la DTD del documento se recurre a las expresiones regulares de PHP ya que el DOM de la página siempre contiene una DTD, aún cuando el documento original no contenga esa declaración.

Una vez generado el DOM del documento se realiza un recorrido por todo el árbol de nodos y se usa un contador para que cada nodo tenga asignado un identificador único. Este identificador servirá para seleccionar los elementos de la página que deben mostrarse en los informes de los resultados.

El objetivo del recorrido de los nodos del DOM es detectar el número de elementos y situaciones presentes en la página (el significado de elementos y situaciones está explicado antes en Tipos de prueba). Por ejemplo, eXaminator contiene varias pruebas sobre las imágenes y para definir los resultados necesita obtener estos datos:

Cantidad total de elementos img (código: img)

Cantidad de elementos img sin atributo alt (código: imgAltNo)

Cantidad de elementos img con atributo alt nulo (código: imgAltNull)

Cantidad de elementos img con atributo alt muy extenso (código: imgAltLong)

Cuando en el recorrido del DOM se detecta un nodo del tipo XML_ELEMENT_NODE con el nombre img, se utiliza una función con el mismo nombre para analizar detalladamente el nodo. Esta función verifica si el elemento img contiene el atributo alt y, si no es así, suma uno al elemento imgAltNo. Si existe ese atributo pero es nulo, suma uno a imgAltNull y si el texto del atributo alt contiene más de 100 caracteres, suma uno a imgAltLong.

A la vez que se suman los elementos, se anota el identificador del nodo. De este modo, cuando se quieran mostrar las imágenes con alt nulo, por ejemplo, bastará con realizar el mismo recorrido del árbol del DOM usando el mismo sistema para numerar los nodos. Cabe mencionar que eXaminator guarda una copia de la página evaluada para asegurarse de que todas las operaciones futuras se realicen sobre la misma versión del documento.

Definición de los resultados

Como se explicó en Tipos de prueba, existe una matriz para guardar toda la información necesaria sobre cada una de las pruebas. Para definir los resultados, se recorre esta matriz de datos y se comprueba si en el documento existe el elemento y la situación necesaria para que la prueba resulte aplicable.

Cuando la prueba es aplicable, se usa la función específica para cada tipo de prueba (verdadero, falso, proporcional o decreciente) y se calcula la puntuación tomando en cuenta la nota y la ponderación de la prueba.

La ponderación es el producto del grado de confianza y el valor relativo de la prueba pero, como cada perfil de usuario tiene un valor propio para cada prueba, la operación se repite seis veces, una por cada perfil de usuario.

Una vez definidos los resultados de todas las pruebas aplicables, se promedian los resultados correspondientes a cada uno de los perfiles de usuarios. Para obtener la puntuación general de la página se promedian, finalmente, las puntuaciones obtenidas por los seis perfiles de usuarios.

Conclusiones

El Informe de Investigación sobre Métricas de Accesibilidad Web 7 del Grupo de Trabajo sobre Investigación y Desarrollo del WAI 8 plantea que “las métricas de accesibilidad web son una herramienta muy valiosa para los investigadores, desarrolladores, agencias gubernamentales y usuarios finales. Las métricas ayudan a indicar el nivel de accesibilidad de los sitios web, incluyendo el nivel de accesibilidad de los sitios web individuales, o incluso las evaluaciones a gran escala de la accesibilidad de muchos sitios web”. Pero ese informe también advierte que los métodos y ejemplos para evaluar la validez de las métricas usadas en la actualidad son poco frecuentes y que es necesario realizar más esfuerzos dirigidos a investigar su confiabilidad y sus alcances.

eXaminator fue la primera herramienta en línea que, en el año 2005, aplicó una métrica cuantitativa para calificar la accesibilidad de las páginas web. Su metodología sufrió cambios sustanciales producto de la experiencia adquirida, ya que desde el 2006 se utiliza en el monitoreo de miles de páginas de la administración pública de Portugal.

Sin embargo, hasta la realización del Simposio en Línea sobre Métricas de Accesibilidad Web 9 realizado en diciembre de 2011, eXaminator no contó con la documentación necesaria para explicar su modo de operar, ni los conceptos que servían de fundamento a su particular modo de evaluar la accesibilidad.

En este trabajo se ha pretendido brindar la mayor cantidad de información posible acerca de eXaminator como una forma de enmendar esa omisión inexcusable, con la esperanza de que sirva también para acompañar los esfuerzos actuales en la investigación de las métricas de accesibilidad.

Referencias

1 Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0;  SIDAR

2 Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0; W3C

3 Hera; 

4 Quantitative Metrics for Measuring Web Accessibility;  Descargar PDF

5 Unified Web Evaluation Methodology (UWEM);  [Ver en línea WebCluster]

6 Techniques for WCAG 2.0: G1;  WCAG 2.0

7 Research Report on Web Accessibility Metrics;  Accessibility Metrics

8 Research and Development Working Group [Ver en línea RDWG]

9 Website Accessibility Metrics

Glosario

Ayudas Técnicas

El término “ayudas técnicas” (en inglés assistive technologies) ha sido sustituido por el de “producto de apoyo”, tal y como recomienda la Norma UNE-EN ISO 9999:2007: Productos de apoyo para personas con discapacidad. Clasificación y terminología (ISO 9999:2007), que los define como “cualquier producto (incluyendo dispositivos, equipo, instrumento, tecnología y software) fabricado especialmente o disponible en el mercado, para prevenir, compensar, controlar, mitigar o neutralizar deficiencias, limitaciones en la actividad y restricciones en la participación”. Los productos de apoyo son por tanto dispositivos diseñados para ayudar a las personas con discapacidad a realizar tareas que de otra manera no podrían realizar. Dentro de la informática son aplicaciones software o dispositivos hardware empleados para el uso del ordenador y el acceso al contenido de la Web: lectores de pantalla, ampliadores de pantalla, teclados alternativos, líneas braille, etc.

Back-end

El código de una página o aplicación Web que reside y es ejecutado en el servidor. Éste accede a la información en la base de datos, determina cómo y cuando mostrarla, y la entrega al navegador Web en forma de páginas HTML. También se denomina de esta forma al gestor de contenidos o “sistema de auto-administración” que puede tener un sitio Web.

Closed Captions

Sistema de subtítulos destinado a permitir que las personas con problemas de audición puedan ser conscientes de todos los sonidos de una película o videojuego. A diferencia de los subtítulos comunes, que sólo describen los diálogos, este sistema describe todo el audio presente (incluyendo música de fondo y efectos de sonido) mediante palabras o símbolos.

Colapsable

Un patrón de interfaz de usuario en el que la información se esconde y se revela en forma gradual al usuario a medida que éste la solicita. Por ejemplo, un menú desplegable, o un botón con signo “+” que al ser activado despliega más texto en la misma pantalla.

Concurrent Think Aloud (CTA)

Aplicado al test de usuarios, es una técnica que consiste en que el usuario expresa en voz alta sus pensamientos.

Daltonismo

El daltonismo es un defecto genético que ocasiona dificultad para distinguir los colores. El grado de afectación es muy variable y oscila entre la falta de capacidad para discernir cualquier color (acromatopsia) y un ligero grado de dificultad para distinguir algunos matices de rojo y verde.

Dojo Toolkit

Una librería JavaScript con componentes de interfaz de usuario, utilidades y herramientas que facilitan la programación de aplicaciones interactivas complejas.

Etiquetas (meta-dato)

Palabras clave, organizadas en forma no jerárquica, que describen el contenido de un recurso de información, sea una noticia, una foto, un artículo, producto, etc. Permite vincular con otros recursos que compartan las mismas palabras clave.

Etiqueta (lenguaje de marcado)

En un lenguaje de marcado, las etiquetas se ubican alrededor de un fragmento de texto, para diferenciarlo del resto. Por ejemplo se usa <p> para indicar el comienzo de un párrafo, y </p> para indicar donde termina. El lenguaje HTML incluye más de 100 etiquetas como ésta, incluyendo la etiqueta <a> que permite enlazar páginas entre si, elemento esencial a la naturaleza hipertextual de la Web.

Etiquetas deprecadas

Se denomina así a etiquetas que se utilizaban en versiones anteriores de HTML, pero cuyo uso ya no es recomendado por la última versión de este estándar.

Eye tracking

Técnica que consiste en el seguimiento y grabación de la mirada.

Experiencia del Usuario (User eXperience, UX)

Se puede definir como “la sensación, sentimiento, respuesta emocional, valoración y satisfacción del usuario respecto a un producto, resultado del fenómeno de interacción con el producto y la interacción con su proveedor” [Hassan-Montero, Y.; Martín-Fernández, F. J. “La Experiencia del Usuario”: No Solo Usabilidad, nº 4, 2005

Framework

Marco de trabajo para el desarrollador. Se trata de un conjunto de librerías de código, patrones de programación y criterios de trabajo. Esto facilita la tarea del programador, optimiza tiempos, y promueve mejores prácticas.

Front-end

El código de una página Web que se ejecuta en el navegador, de cara al usuario. Incluye HTML, CSS y JavaScript, así como otras tecnologías de la plataforma Web.

jQuery

Una muy popular librería de código JavaScript que facilita el trabajo del programador front-end, simplificando la interacción con el DOM, el uso de AJAX, y otras tareas comunes.

Lector de pantalla

Es un tipo de software incluido dentro de los denominados “productos de apoyo”, que identifica e interpreta lo que se muestra en pantalla y lo presenta al usuario mediante un sintetizador de voz o mediante una línea braille.

Productos de apoyo.

Liveviewing

Aplicado al test de usuarios con eye tracking, es una técnica que consiste en que el moderador “ve por los ojos del usuario”, es decir, observa desde un monitor remoto la sesión, sin grabar o revisar posteriormente los videos.

Marcado semántico

Refiere al uso apropiado de etiquetas HTML a fin de que el sentido de un bloque de texto sea interpretable programáticamente. Por ejemplo, si utilizo CSS para dar formato a una línea de texto de modo que se vea grande y en negritas, entonces un programa (como el motor de indexación de Google) no tiene forma de determinar que esto es un encabezado. Corresponde entonces marcar “semánticamente” ese texto utilizando una etiqueta <h1>, de esta forma está claro para cualquier programa que se trata de un encabezado (heading) de nivel uno.

Mapa de calor

En una grabación con eye tracking, es el mapa que representa por medio de colores las zonas que han recibido más miradas de los usuarios.

Mapa de opacidad

En una grabación con eye tracking, es el mapa que oculta con color negro las zonas que los usuarios no han mirado.

Mapa de recorrido

En una grabación con eye tracking, es el mapa que representa por medio de líneas las sacadas y por medio de círculos las fijaciones de cada usuario, numeradas en el orden en que ocurrieron.

Maquetado

La tarea de convertir el diseño visual de una página Web (hecho en Photoshop por ejemplo) en una plantilla HTML y CSS, que funcione correctamente en un navegador.

Meta-datos

Datos que describen otros datos. En el caso de una página Web, se trata de atributos que se proveen en forma estandarizada o por convención, para consumo de un programa (como el motor de indexación de un buscador, o ayudas a la navegación). Esto incluye información acerca de qué tipo de contenido es, quién es su autor, fecha y otros datos de publicación, relaciones con otros artículos, etc.

MVC, arquitectura

Es un patrón de arquitectura de software, que propone separar el código en “modelo, vista y controlador”. El modelo maneja la lógica de negocio y el acceso a los datos. La vista es una representación de los datos, por ejemplo mediante una plantilla HTML. El controlador recibe datos del usuario, y media entre el modelo y la vista. Algunos frameworks populares que utilizan este patrón o variaciones del mismo son Ruby on Rails (Ruby), Django (Python), Backbone (JavaScript) y Laravel (PHP).

Parálisis cerebral

Trastorno permanente y no progresivo que afecta a la psicomotricidad del paciente. En un nuevo consenso internacional, se propone como definición: “La parálisis cerebral describe un grupo de trastornos del desarrollo psicomotor, que causan una limitación de la actividad de la persona, atribuida a problemas en el desarrollo cerebral del feto o del niño. Los desórdenes psicomotrices de la parálisis cerebral están a menudo acompañados de problemas sensitivos, cognitivos, de comunicación y percepción, y en algunas ocasiones, de trastornos del comportamiento”.

Ratón facial

Programa de ordenador que, unido a una webcam USB estándar o especial diseñada especialmente para esto, es capaz de reproducir las funciones de un ratón (movimiento y pulsación de botones). El movimiento del puntero del ratón se realiza en coordinación con la zona del cuerpo que apunte la webcam y que previamente hemos elegido (generalmente suele ser una parte de la cara). Las acciones de los botones se realizan con gestos predefinidos o con un sonido.

Retrospective Think Aloud (RTA)

Aplicado al test de usuarios, es una técnica que consiste en que el usuario, una vez terminado el test, ve el vídeo de la sesión y comenta en voz alta lo que le ocurría en cada momento, en un storytelling.

RTA

(véase Retrospective Think Aloud)

Sacada

Movimiento ocular que hacen los ojos entre dos fijaciones.

Saccade

(véase Sacada)

Storytelling

Aplicado al test de usuarios, narración de una situación que se ha dado durante el test.

Scroll

cuando una página individual, por la cantidad de contenido que contiene, no entra en la pantalla, el navegador provee al usuario un control de desplazamiento vertical, o scroll bar, que desplaza el contenido como si fuera una larga hoja detrás de una ventana. En dispositivos táctiles, este desplazamiento se logra arrastrando con el dedo la pantalla de un extremo al otro.

SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Special Effect

Asociación sin ánimo de lucro de Reino Unido que se dedica a la investigación y difusión de la accesibilidad en los videojuegos. Ir a la Web de la Asociación.

Unity 3D

Motor y editor de videojuegos multiplataforma creado por Unity Technologies

Visión foveal.

Visión registrada en la fóvea del ojo; es la visión más nítida debido a que la fóvea tiene gran parte de los conos.

Visión parafoveal

Visión registrada en la zona que rodea la fóvea del ojo; es una visión menos nítida que la foveal.

Visión periférica

Visión registrada en las zonas lejana a la fóvea del ojo; es la visión menos nítida.

Wireframe

Boceto esquemático de una página, que permite prototipar a grandes rasgos su contenido, organización y jerarquías; sin adentrarse en detalles de diseño visual.

Web Accessibility Initiative (WAI)

http://www.w3.org/WAI/ Es un grupo de trabajo permanente del W3C que, en coordinación con organizaciones alrededor de todo el mundo, persigue la accesibilidad de la Web a través de cinco áreas de trabajo principales: tecnología, directrices, herramientas, formación y difusión, e investigación y desarrollo.

World Wide Web Consortium (W3C)

http://www.w3.org/ Es una comunidad internacional que desarrolla estándares que aseguran el crecimiento de la Web a largo plazo con el objetivo de guiar la Web hacia su máximo potencial.

XML

Lenguaje de marcado extensible. Permite definir nuevos lenguajes que, como HTML, utilizan etiquetas para marcar fragmentos de texto, y permite el intercambio de información estructurada entre diferentes plataformas. Los nuevos lenguajes hechos posible por XML incluyen, entre muchos otros: SVG (gráficos vectoriales), MathML (ecuaciones), Atom y RSS (sindicación de contenidos) y SOAP (servicios web).

YUI de Yahoo

Librería de interfaz de usuario en HTML, CSS y JavaScript provista por Yahoo como código abierto, para la creación de aplicaciones web de interacción dinámica.