Archivo de Categoría «General»

Cada vez que realizo pruebas de usabilidad con usuarios, o user testing, me sorprende la cantidad de información útil que puedes obtener con el sólo hecho de observar cómo personas reales utilizan un prototipo, un sitio o una aplicación. Sobre la metodología de las pruebas de usuarios podemos hablar después, ahora sólo quería compartir unas fotografías del laboratorio improvisado (en el sentido de no establecido o fijo, porque en esto no te puedes dar el lujo de dejar nada sin planificar) en el que he estado sumergido los dos últimos días.

No había tenido tiempo de escribir al respecto, esperaba que alguien más tocara el tema antes, pero me sorprende que nadie haya hablado de esto.

Pues bien, hace unos días (el 9 de diciembre) escuché que un operador de la bolsa de Tokio accidentalmente realizó una transacción que bien podría ser el error más caro de esta naturaleza. El empleado activó una orden de venta de 610.000 acciones de J-Com por ¥1 (yen) cada una, en lugar de poner a la venta 1 acción por ¥610.000.

Aparentemente el sistema habría advertido al usuario que la orden era poco usual, pero élignoró el mensaje. El error fue notado posteriormente por una llamada telefónica para confirmar la veracidad de la orden, pero el empleado no pudo inactivar la orden de venta.

El error generó un caos financiero que causó pérdidas inconcebibles a la compañía que administraba las acciones y al mercado en general.

Probablemente en este punto ya tendrán muy claro que tras el error hay una serie de problemas de diseño que permitieron que eso ocurriera:

• Un corredor de bolsa es un usuario muy particular: permanentemente estresado y operando contra el tiempo, por lo que el manejo de situaciones como las confirmaciones de acciones y los mensajes debe ser cuidadosamente considerado;
• El sistema permitió que el corredor ejecutara una acción poco frecuente, sin reforzar de modo apropiado la importancia de ésta, esto es una falla del manejo de la confirmación de las tareas y de la comunicación con el usuario, que permite elacostumbramiento ante los mensajes de alerta, probablemente por el uso de un formato estándar de respuesta: seguramente el usuario hizo clic en OK o Aceptar sin leer el mensaje;
• El sistema no permitió la anulación de la orden de venta, desconozco los detalles del flujo de venta de acciones, pero esto es algo que podría preverse;

Por la importancia de un sistema que maneja las acciones y la economía de todo un país, es vital que todos estos detalles se tomen en cuenta, si no las consecuencias pueden ser muy graves. En el caso que les comento, el error principal es del sistema, antes que del usuario: el sistema permitió y facilitó que el error ocurriera.

Este es un caso extremo, en el que las consecuencias de un error son muy caras. Normalmente la situación no es tan dramática, pero nos permite reflexionar sobre la relevancia de un diseño que considere a los usuarios, sus características y necesidades.

Más información sobre el incidente:

• Resultados en Google News
• The unthinkable at the TSE
• Stock Fiasco Damages Exchange’s Reputation
• J-Com’s Tokyo Debut Marred by $2.8 Bln Trading Error
• Too fat, too fast. The £1.6bn finger
• Typing Error Triggers Loss of 240 Billion Won

Desde hace un tiempo vengo observando un problema común que sorprendentemente parece no haber llamado mucho la atención. Me refiero al manejo de claves en los formularios, tanto en sistemas de autenticación y acceso, como en registro de usuarios nuevos.

Como medida de seguridad razonable HTML define un tipo de input, o campo de ingreso de texto especial, definido por el atributo type como password. La propia definición indica que a diferencia del input de texto y los de tipo password es que estps últimos deben enmascarar su contenido mediante caracteres como asteriscos:

Like “text”, but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks).

Si bien esto es razonable y provee una aparente seguridad (sólo aparente, porque el texto de la clave es siempre accesible), es común que los usuarios se equivoquen al ingresar una clave y que la única manera para corregirla sea borrar todo y escrirla nuevamente. El problema es más severo en situaciones como el registro de un nuevo usuario, en que es común solicitar la creación de una clave y el uso de un segundo campo para confirmar la clave original. En estos casos, ante cualquier duda, el usuario debería borrar ambos campos, el de clave y el de confirmación, y escribirlo todo nuevamente.

Pero también es común que ocurra otra situación, que personalmente he hecho y que además he observado en otros repetidas veces: cuando se solicita la confirmación de una clave, el usuario copia la clave escrita originalmente y la pega en el nuevo campo. Si la clave estaba mal escrita, terminará sin poder acceder al sistema porque la clave registrada no era la que pensó que había escrito. Este es un problema severo.

Soluciones

La lógica de ocultar la clave tiene sentido cuando el usuario no está solo, pero si se encuentra en una situación de confianza es perfectamente razonable que pueda ver el texto que está ingresando como clave. Para esto se podría implementar un mecanismo que permita alternar entre un campo de clave convencional, presentado por defecto, y otro que revela el contenido de la clave, para confirmar que se ha escrito correctamente.

El modelo base es simple:

1. Al presentar el formulario, por defecto se muestra un campo de clave estándar, con el contenido enmascarado, acompañado de un botón etiquetado mostrar o algo similar.
2. El usuario puede revelar el contenido del campo presionando el botón mostrar.
3. El campo muestra el contenido de la clave en texto legible y cambia la etiqueta del botón a ocultar.

En términos de interacción todo va bien hasta acá, pero dependiendo de la técnica utilizada para cambiar las características del campo de clave, tendríamos que realizar un paso extra antes de enviarlo al servidor para procesarlo: si se utilizó JavaScript para alternar entre dosinputs, uno tipo password y otro tipo text, es necesario sincronizar el contenido de ambos antes de ejecutar el submit, e incluso, entre cada cambio de estado entre los dos campos porque el usuario pudo haber editado el texto. Por lo tanto, el flujo completo debería quedar del siguiente modo.

1. Al presentar el formulario, por defecto se muestra un campo de clave estándar, con el contenido enmascarado, acompañado de un botón etiquetado mostrar o algo similar.
2. El usuario puede alternar el estado del campo entre enmascarado o descubierto
   1. El usuario hace visible el texto (desenmascara)
   2. Edita el contenido de la clave
   3. Se sincroniza el texto de los dos campos, el enmascarado y el descubierto
   4. Se repite el proceso tantas veces el usuario cambie de estado
3. Usuario presiona el botón submit.
4. Nos aseguramos de sincronizar el contenido de los campos.
5. Se ejecuta el envío de los datos al servidor.

La verdad es que estoy considerando la implementación más compleja que implica usar dos campos y alternarlos mediante JavaScript, pero teóricamente debería ser posible alternar los estados simplemente cambiando el atributo type del elemento, con lo que se conservaría el valor y el ID del input, sin que sea necesario realizar ninguna sincronización. No lo he problado, pero lo haré pronto.

Por ahora, pueden probar el ejemplo que creé para esto. La implementación es sencilla y estándar y requiere de JavaScript y CSS. El ejemplo no separa el comportamiento del HTML, eso es el siguiente paso y lo haré en cuanto tenga un tiempo.

Si hay interés, puedo explicar en detalle la implementación del script del ejemplo. Espero sus comentarios.

Me llegó la semana pasada una parte de los libros que compré en Amazon y entre ellos se encuentra Ambient Findability, de Peter Morville, coautor junto a Luis Rosenfeld de Information Architecture for the World Wide Web, más conocido como el libro del oso polar. Ya desde el principio lo estoy disfrutando, y con sólo unas pocas páginas avanzadas puedo recomendarlo con confianza.

Por ahora quería dejarlos con una cita que me pareció muy relevante, en que Morville enfatiza la atención en los aspectos relevantes de la interacción de los usuarios con la información:

[…] Though our attention is drawn to the fast layers of hi-tech, the map to this maze is buried in the slow layers of human behavior and psychology. It’s not enough to focus on the I in IT. We must also lose the C in HCI. Becauseambient findability is less about the computer than the complex interactions between humans and information.

[…] Pese a que nuestra atención está dirigida a las rápidas capas de la alta tecnología, el mapa de este laberinto está enterrado en las lentas capas del comportamiento humano y la psicología. No es suficiente enfocarse en la I deTI. También debemos soltar la C de IHC. Porque la encontrabilidad ambientales menos acerca del computador que de las complejas interacciones entre los humanos y la información.

Incluyo la traducción de la cita porque me lo han mencionado algunos lectores, pero no termino de convencerme de cómo suena, particularmente el término ambient findability, que en inglés es también un neologismo. Si tienes alguna sugerencia de traducción más apropiada y que suene menos espantoso que encontrabilidad ambiental, pues bienvenido a comentarlo.

En suma, todo el argumento de Morville se refiere a la usabilidad del contenido y la facilidad de encontrar lo que uno necesita en una fuente incontrolable de información, no siempre relevante. Comentaré más adelante si hay otra cosa que me llame particularmente la atención.

Antes que todo, mis más sinceros agradecimientos y felicitaciones para los chicos de Derechos Digitales, el trabajo que están haciendo es notable. Ahora, aquí va mi registro del taller legal para bloggers organizado por la Corporación Derechos Digitales, que se suma a la ya amplia cobertura en los blogs de los asistentes.

Nota: las fotografías, así como todos los contenidos de el factor humano están publicados con una licencia Creative Commons, así que eres libre de pedir prestado, reciclar y republicar según las reglas de la licencia.

El evento local para celebrar el Día Mundial de la Usabilidad fue todo un éxito. Sobrepasó nuestras expectativas de asistencia y de calidad. Las exposiciones y discusiones fueron muy interesantes y constructivas y la asistencia llegó a más de 80 personas, bastante más de nuestros cálculos más optimistas.

Todo partió con una presentación de Javier Velasco y luego Paulo Saavedra habló sobre el rol de la usabilidad en el gobierno electrónico y lo realizado en el Estado chileno al respecto, así como también de los planes futuros.

Siguiendo, Hernán Saavedra, Gerente Banca a Distancia de BancoEstado nos dió a todos una sorpresa por la lucidez de su presentación desde la perspectiva de un cliente, pero de uno que tiene las cosas muy claras.

Para continuar, Felipe Almazán, Coordinador Desarrollo de Sistemas de la Biblioteca del Congreso Nacional presentó la experiencia de aplicar las pautas de Nielsen y Krug para mejorar el sitio web de la Biblioteca.

Después del descanso, continuamos con la primera mesa de discusión, sobre Usabilidad y Negocios, con Juan Carlos Camus (SBIF) y César Romero (BCI), moderada por Juan Luis Martínez. La conversación se centró en la banca y el rol de la usabilidad en los resultados del servicio al cliente y sobre cómo se vende internamente la necesidad de usabilidad en una organización.

Una grata sorpresa fue el contacto de Javier Velasco vía Skype con Steve Krug, con quien conversamos por unos 15 minutos.

Para terminar, la segunda mesa estuvo compuesta por Leo Prieto, Gabriela García (Amable), Jorge Barahona (Ayer Viernes) y yo, Nelson Rodríguez-Peña. La discusión se centró en la relación entre diseño y usabilidad.

Sin más intoducción, los dejo con el registro fotográfico de la jornada.

Motivado por la publicación de Nielsen sobre la usabilidad de los blogs, Vuarnet
(www.isopixel.net) invitó a un grupo de autores de blogs hispanoparlantes para entregar su propia versión de los problemas de usabilidad. Se realizó un trabajo de discusión en línea entre los integrantes repartidos por México, España y Chile y se generó el siguiente listado de problemas comunes de usabilidad en blogs. El grupo está conformado por:

• Gustavo Barron (http://ageku.net/)
• Nelson Rodríguez-Peña (http://www.webstudio.cl/blog/)
• NOlo y Seth (http://alquimistas.evilnolo.com/)
• Raúl Ramírez, Vuarnet (http://www.isopixel.net)
• Yusef Hassan, (http://www.nosolousabilidad.com/hassan/)

Esta lista es un trabajo colectivo que publicamos simultáneamente en
nuestros blogs personales. Los dejamos con la lista, no sin antes saludar a
Vuarnet quien está pasando por un difícil momento personal, un
reconocimiento para él y nuestros mejores deseos a la recuperación de su
hermano, Juan Guadalupe Ramírez.

Enlace a la página principal no disponible

Un error frecuente y complejo es la falta de un vínculo permantente hacia la página principal o portada del blog. Un usuario que entre al sitio directamente a una página interior se verá imposibilitado de acceder a la portada, a menos que modifique directamente la URLbuscando la página principal.

Enlaces que se abren en una nueva ventana

Por razones de interoperatividad e independencia de dispositivos de visualización oficialmente se dejó de incluir el atributo target en XHTML. Esta propieda permitía abrir una nueva ventana al activar un vínculo. Para un usuario puede resultar molesto, desorientador e intrusivo que sin previo aviso se abra una nueva ventana, las consecuencias de accesibilidad son aún más negativas. Es más apropiado dejar que el usuario tome la decisión de navegar en la misma ventana o decidir abrir una nueva.

Enlaces embebidos

Los enlaces que figuran dentro de un texto más extenso deben tener un rótulo descriptivo, que permita predecir hacia dónde lleva el enlace y que a la vez sea significativo respecto al contenido del que trata. Deben ser representados visualmente de un modo distintio y lo más convencional posible. Por esta caracterización especial, no se debe abusar de enlaces en el cuerpo del texto, ya que pueden producir ruido visual y dificultar la lectura.

Acerca de…

No es necesaria una fotografía del autor, pero una breve descripción del sitio y un aviso desde que lugar (país) desde donde se está escribiendo es de gran importancia. Darse a conocer genera confianza y esto aumenta la credibilidad.

Correo de contacto

Un correo de contacto es fundamental, los comentarios en el blog no son suficientes. Si alguien desea preguntar algo en privado, sugerir un tema, o establecer cualquier tipo de comunicación, debe encontrar un mecanismo simple y efectivo para ello.

Enlaces permanentes (Permanent Links) usables

Los permalinks o enlaces permanentes son la URI para identificar un post. El permalink de un post debe ser único y permanente, no cambiar. A esto se aplican las reglas generales de una URI bien diseñada: que sea legible y no una solicitud GET de forma http://miblog.com?postid=12345

Títulos claros y significativos

Los títulos deben ser precisos y concretos además de estar relacionados con el ontenido de un post. Un título como He estado pensando… es ambiguo y poco significativo, en tantoPensamientos sobre diseño utiliza palabras clave relevantes que indican inequívocamente el tema general del que se habla. Esto ayudará a describir mejor el tema, permitirá a los buscadres indexar más apropiadamente, etc.

Títulos de ventanas

El título de la ventana o más apropiadamente del documento (head->title) debería estar construido como Título del post – Nombre del Blog. De este modo se informa apropiadamente al usuario del tema y la ubicación de la página, a la vez que resulta mucho más fácil leer el historial del navegador y las pestañas de las ventanas minimizadas, cuando están disponibles. Un ejemplo de buen uso es Señalética en Baños > Mi blog de diseño.

Enlace a contenido sindicado

Los contenidos sindicados (o feeds) mediante formatos como RSS o Atom son muy utilizados por quienes acostumbran leer blogs. Por lo mismo, es importante ofrecer vínculos claros a este tipo de canales alternativos. Aunque muchas herramientas ofrecen auto descubrimientode feeds, es importante hacer explícita la existencia de estos formatos y disponer de un modo rápido de suscribirse a ellos.

Contenido sindicado: demasiados sabores, demasiados dolores de cabeza

Los formatos de contenido sindicado y sus mecanismos de lectura son conocidos por los usuarios frecuentes de blogs, pero no se debe asumir que todos los letores estarán familiarizados con ellos o su significado. Si a esto agregamos la variedad de alternativas de formatos, tenemos una gran posibilidad de confusión. Es recomendable utilizar herramientas que proveen contenidos optimizados para cada usuario o cliente de modo automático, como por ejemplo Feedburner. Estos servicios permiten entregar un solo formato al usuario final, con una única URL, evitando así traspasar al usuario un problema innecesario.

Entradas previas y Encontrabilidad

Los blogs son sistemas de publicación basados en fechas y con una actualización frecuente de contenidos, por lo que es común que los posts vayan quedando ocultos en los archivos. Resulta útil, con el objetivo de proporcionarles visibilidad, ofrecer sistemas de navegación alternativos al clásico Archivo: Taxonomía de categorías, esquemas de navegación por paginación cronológica (atras/adelante), y elementos como los posts más leídos, destacados, etc. Además de estos sistemas, enlazar desde posts actuales aquellos otros posts relacionados temáticamente y publicados con anterioridad proporcionará encontrabilidad a estos últimos.

Páginas con exceso de información o mal organizadas

Es frecuente el uso de columnas o sidebars de apoyo que contienen información o funcionalidades complementarias, como por ejemplo buscadores, archivos, categorías y otros. Tamien es común la promoción de algunos servicios o campañas. No obstante, el abuso de estos elementos y su disposición indiscriminada puede causar efectos nocivos como lentitud en la carga de las páginas y una gran contaminación visual.

Vocabulario excluyente o demasiado tecnologizado

No todos entienden lo que es un blog, un blogroll, un permalink, un feed, un post ni por qué existen los comentarios o cómo se comenta. Es importante asumir que los visitantes nunca han visitado un weblog, por lo que es preferible pecar de obvio que dejar a los usuarios sin pistas de lo que se está hablando. Si alguien encuentra accidentalmente.

Redacción

Es preferible utilizar un lenguaje sencillo, claro y directo. Resume.

Limpieza y Legibilidad

Es necesario evitar el uso de texto multicolor, el empleo de bajos contrastes entre texto y fondo, tamaños de texto minúsculos, el UsO InjUStificADO de mayúsculas y eskritur4 ko0l. Todos estos recursos dificultan la lectura y van en desmedro del acceso al contenido.

Estética

La estética es uno de los factores de diseño que de forma más directa impacta en la percepción de los usuarios. Cuidar la estética, que no significa añadir elementos decorativos superfluos, contribuirá a persuadir y motivar al usuario. Recordemos además que el minimalismo en el diseño es al mismo tiempo un principio heurístico de usabilidad y una noción estética.

Escribe en tu idioma

Un error de usabilidad bastante común es no usar correctamente el lenguaje. evita los aforismos en la medida de lo posible. Cuando existan términos que reflejen apropiadamente un concepto en castellano, prefiere la opión en castellano. En este documento, hemos optado conscientemente por téminos como blog y post porque creemos que las traducciones no son tan apropiadas. Al incluir una cita originalmente en otro idioma, es importante traducirla. Es un esfuerzo que los usuarios agradecerán.

Intenta seguir estándares

Los estándares en la web (XHTML, CSS…) así como las directrices de accesibilidad (WAI), son importantes para no excluir a nadie de tu blog.

Ya casi me había olvidado de este pequeño juego/experimiento. Hoy me lo recordó un comentario en el post y me fui directo a Google a ver cómo andaba todo. Y como verán, funciona perfectamente.

¿De qué se trata? se preguntarán. Pues bien, hace casi cuatro meses escribí un post tituladoOptimización de Búsqueda, No de Motores de Búsqueda para probar y demostrar el comportamiento de los buscadores, en particular Google. La idea era simple, escribí sobrecómo podemos modelar el contenido para mejorar los resultados de búsqueda. Pero aquí no me refiero a cómo engañarlos para obtener mejores posiciones, sino a cómo guiar a los indexadores para que reconozcan con mayor precisión el contenido y puedan calificarlo apropiadamente. Es decir, no optimizar el contenido para sacar ventajas de un buscador y su funcionamiento maliciosamente, sino optimizar el contenido para asegurar que sea indexado correctamente y de ese modo sea encontrado en un contexto relevante.

Las claves del experimiento eran utilizar repetidamente los términos más relevantes y variaciones del mismo: buscar, buscador, búsqueda, buscando, buscarán junto con Google,Yahoo, MSN, entre otros. Estas palabras claves fueron utilizadas en puntos importantes como el título de la página. Además, se utilizaron discretamente algunos vínculos a páginas externas con temas relacionados, para respaldar el contenido.

Finalmente, y pese a que sólo unos pocos se animaron a comentar (lo que ciertamente hubiera aumentado las posibilidades de mejorar los resultados), la página es el primer resultado retornado por Google en una búsqueda general para los términos optimización de búsqueda, sin indicar idioma, es decir, en todo el universo de páginas indexadas por Google. Sí, primer resultado retornado entre 658.000 encontrados. Impresionante, ¿no? Pese a que el ejercicio estaba orientado a Google, Yahoo también responde a patrones similares, y califica la página en el lugar 13, nada mal. MSN por su parte parece no calificar las cosas del mismo modo, porque ni siquiera pude encontrar la posición en que aparece. Como no estamos hablando de una técnica en particular, sino de cómo construir el contenido para facilitar el trabajo de los buscadores, esto no habla muy bien de MSN.

Conclusión: es muy relevante preocuparse de utilizar los términos apropiados, repetirlos en lugares importantes como el título de la página, los encabezados h1, h2, etc. y validar el contenido con vínculos externos relevantes.

Hoy tuve una de esas experiencias que te toman de la mano y te aterrizan a una realidad que a veces nos elude. Estaba en un cajero automático, ATM o como quieras llamarlo, y a unos tres metros observé a una persona, un hombre relativamente joven, con un aspecto que evidenciaba su falta de recursos. Estaba en una actitud que no era para nada intimidante, pero me llamó la atención.

Cuando terminamos la operación (con Are, mi esposa), nos alejamos del cajero, pero este personaje se me acercó y me pidió ayuda. ¿Me puede ayudar a usar la tarjeta?. Claro, fue más señas y gestos que una frase elaborada. Asumiendo que estábamos en un lugar público, abierto, con algunas personas alrededor y un par de guardias a la vista, accedí. Me pasó su tarjeta. Este simple gesto describe todo el escenario. Este hombre, probablemente un campesino pobre, con toda ingenuidad le pasó a un desconocido su tarjeta para utilizar el cajero automático. Si le pido su clave, seguro me la hubiera dado.

Su actitud era de completo temor al aparato que tenía en frente. Le devolví su tarjeta y lo guié mientras él realizaba la operación, pese a que me pidió que lo hiciera yo para el observar y aprender. Esto me dejó en claro que su nivel de alfabetización era mínimo, apenas podía leer. Quería sacar $10.000, unos U$18 ó €15.

En cada pantalla nueva del cajero su desconcierto era mayor. Sumemos a su condición, el que el dispositivo no tenía alineadas correctamente las opciones de la pantalla con los botones que se encuentran al costado para realizar las selecciones. Esto provocó un par de intentos erróneos en que cualquier persona se hubiera equivocado.

Con ayuda y muchas dudas, logró terminar la transacción.

La situación completa me hizo pensar en muchas cosas, desde la brecha cultural, la famosa brecha digital y el diseño de interfaces para públicos tan disímiles como este extremo, que de seguro es el denominador mínimo al momento de desarrollar una interfaz para usuarios sin discapacidades particulares. Pero claro, planteado así, el analfabetismo es una discapacidad.

Cómo no va a ser un tipo de discapacidad, inmediatamente recordé una situación similar cuando tenía unos 12 años, y una señora mayor me pidió que le ayudara a encontrar el bus del recorrido que necesitaba. Evidentemente no sabía leer. Y en otra oportunidad en que una abuela me pidió que le marcara un número en un teléfono público. Estas situaciones acá son aisladas, Chile es un país con un nivel de analfabetismo bajísimo, 4.4%. Pero son los casos extremos, entre medio hay muchos matices.

Pues bien, esto me hizo ver con otros ojos un proyecto en el que estoy participando que involucra como público objetivo a personas desde el nivel del personaje del cajero automático, hasta personas más preparadas, pero de todos modos de un nivel sociocultural bajo, sin acceso directo al mundo digital. En una situación como ésta, todo lo que damos por sentado hay que cuestionarlo, todo es nuevo, nada es una convención. ¡Vaya desafío de interacción!

Me enteré ayer de la publicación de los resultados de un estudio de las páginas de inicio de las Universidades Españolas. El proyecto está organizado por AIPO, Asociación Interacción Persona Ordenador. El proyecto se coordinó mediante un blog, USABAIPO, Proyecto Usabilidad Páginas Web Universidades Españolas. Revisando los resultados y metodología usados, me surgieron algunos conflictos. Aquí va mi comentario, realizado con el mejor de los espíritus y entendiendo que éste es un esfuerzo notable.

Introducción

El proyecto USABIPO se planteó analizar las páginas de inicio de 69 universidades españolas. Sé personalmente que esto es un esfuerzo monumental. Durante el primer semestre de este año participé en un estudio encargado por el Ministerio de Economía del Gobierno de Chile para analizar la usabilidad de los trámites en línea del Estado chileno. Mi rol en este estudio fue particularmente la planificación, coordinación y ejecución de las evaluaciones heurísticas de 61 trámites, en el que participaron tres evaluadores junto a mí como evaluador y responsable de esa parte del estudio. El proceso fue notable y, aparte de los inevitables problemas de tiempo y recursos de un proyecto como éste, me siento muy satisfecho de haber participado en él.

Pues bien, comento esto para dejar en claro que entiendo el esfuerzo que el proyecto USABIPO implica y lo valoro en ese sentido. Pero como mencioné antes, hay algunos aspectos metodológicos que me sorprendieron, y que paso a comentar como aporte y crítica constructiva.

Metodología

USABIPO plantea el tema de la metodología del siguiente modo:

Se efectuó una evaluación por inspección a través de la aplicación de tres métodos diferentes ampliamente consensuados dentro del ámbito de la IPO:

• Inspección de estándares
• Análisis de zonas de la interfaz
• Evaluación heurística

Inspección de Estándares

Nadie podría decir que los estándares web no me preocupan, pero no creo que deberían ser una parte fundamental de un estudio de usabilidad. Puede ser un complemento, un factor más, pero no una parte del estudio, porque el uso de estándares no garantiza usabilidad. Es cierto que es más posible que un sitio basado en estándares web sea más usable y accesible, pero no es una condición automáticamente adquirida.

Por otro lado, creo que hacer una validación automatizada es sólo una parte: así como ya lo hemos discutido muchas veces respecto a la accesibilidad, las validaciones automatizadas no son suficientes en sí mismas. Es cierto que validar CSS y HTML es más fácil que validar accesibilidad, porque los primeros se basan en las reglas predefinidas de un vocabulario conocido, donde la interpretación es menor. Pero un sitio válidamente formado no es lo mismo que un contenido semánticamente estructurado. Creo que esto último no lo cumple el estudio de USABIPO.

Análisis de Zonas de la Interfaz

Creo que es interesante lo que se ha hecho en esta área, pero me parece que se han entregado sólo datos y no información. Para mejorar un sitio, o la portada de un sitio, no me sirve que se identifique cómo está compuesta mi página, sino que se me entreguen pautas para mejorarla.

Evaluación Heurística

Por mi experiencia es aquí donde tengo más observaciones. El primer detalle que me llamó la atención es algo que pudiera parecer menor, pero que creo que metodológicamente puede tener repercusiones en los resultados: la redacción de las pautas heurísticas no es consistente y no representa criterios positivos. En algunos casos el criterio no queda claramente explicado. Esto puede llevar a inexactitudes al momento de la evaluación, porque es posible que los evaluadores interpreten de modo distinto las pautas.

Con lo anterior me refiero a que las pautas deberían estar compuestas por criterios positivos, cosas que el sitio o sujeto de estudio debería cumplir. Una heurística, entonces, debería ser un listado de pautas que se conocen como buenas prácticas de usabilidad. Si se desea incluir un problema frecuente a una heurística, es mejor transformarlo en algo positivo, por ejemplo, la tercera pauta del criterio Navegación de la heurística de USABIPO dice:

¿Se utilizan instrucciones genéricas (Ej. “Haga clic aquí”) o vínculos genéricos? (Ej. “Más”)?

La redacción es sumamente ambigua, y no es claro si el sitio debe cumplir o no con este criterio. Si respondo que sí, estoy afirmando que hace uso de una mala práctica. Si respondo que no estoy diciendo que el sitio no lo hace, lo que es correcto. Confuso. Quedaría mucho mejor planteada así:

El sitio utiliza vínculos en contexto, con un contenido descriptivo, en lugar de usar instrucciones genéricas (Ej. “Haga clic aquí”) o vínculos genéricos (Ej. “Más”)

Esto se aprecia en varias preguntas, por ejemplo:

¿Se utilizan las ventanas emergentes para dar información importante del sitio Web?

es ambigua respecto de si el uso de ventanas emergentes es bueno o malo. Entiendo que el sistema de puntuación trata de enfrentar esto, pero creo que es mucho más simple calificar usando una escala de 5 puntos y un no aplica.

Finalmente, la presentación de los resultados de la evaluación heurística me resulta sorprendentemente simple. No basta con un gráfico para saber cómo salí en la evaluación, necesito feedback detallado para saber cómo soluciono cada uno de los puntos en que fallé. Espero, e imagino de buena fe que así habrá sido, que a cada una de las universidades se les habrá entregado un resultado más detallado de estas evaluaciones.

Conclusiones

Reitero mi reconocimiento por el esfuerzo realizado, pero debo concluir con una visión un tanto negativa respecto a los resultados: creo que existen algunos problemas metodológicos y que hace falta una retroalimentación mucho más rica que permita conocer los problemas reales y detallados, junto con una orientación respecto a la forma de enfrentar los problemas observados.