Archivo de Categoría «General»

Estas ideas me vienen dando vuelta desde hace algún tiempo luego de escuchar algunos conceptos erróneos. No pretendo que sean frases para el bronce, sólo me pareció entretenido el formato:

• Usabilidad no es preguntarle a los usuarios qué hacer, es oirlos, observarlos e interpretar sus necesidades.
• Accesibilidad no es ponerle alt a las imágenes, es establecer una política organizacional que asegure la generación de contenido accesible.
• Diseño Centrado en el Usuario no es ponerse en el lugar de los usuarios, es observar a usuarios de verdad y aprender a conocerlos.

El análisis de uso del espacio en una página como herramienta de usabilidad fue coronado por Nielsen en su libro Homepage Usability: 50 Websites Deconstructed, en que analiza las portadas de 50 sitios. He utilizado este tipo de análisis varias veces, y siempre mi problema llegaba a la hora de calcular los porcentajes de las diferentes áreas. No es que sea algo difícil, incluso para los que no somos particularmente dotados con los números, pero es engorroso. Pues bien, hace un par de meses comencé a explorar una solución usando mi viejo amigo Director. Es que Lingo fue mi primer lenguaje de programación y trabajé bastante con él, y aún tengo una licencia no muy vieja de Director acumulando polvo. Puse manos a la obra y les muestro el resultado. Es de esas cosas que a veces se hacen casi por el puro placer de hacerlo. Sin embargo preveo una serie de usos, es más, acabo de utilizarla la semana pasada para evaluar 24 sitios para un benchmark. Casi demasiado jactanciosamente, les presento mi herramienta para analizar el uso de espacio en páginas. Todavía sin nombre, sus características son:

• Permite importar una captura de pantalla en diversos formatos: PNG, JPEG, BMP, GIF
• Permite dibujar múltiples zonas, eliminarlas o cambiar sus criterios
• Utiliza los criterios de Nielsen para definir las áreas
• Permite generar un gráfico de torta con los porcentajes para cada criterio y exportarlo como PNG, JPEG, BMP o GIF
• Puede exportar la captura de pantalla con las áreas dibujadas en los mismos formatos
• Puede exportar los datos en un archivo CSV para uso en planillas de cálculo

Aún faltan muchos detalles por pulir, pero funciona. Aquí van algunas pantallas:

La definición de Technorati sobre los tags comienza con:

What’s a tag?

Think of a tag as a simple category name. People can categorize their posts, photos, and links with any tag that makes sense.

Asumo que la definición intenta simplificar el problema, pero me parece esencialmente incorrecta. Tags y categorías no son lo mismo.

El uso de tags en un rango amplio de sitios es un fenómeno reciente e interesante, pero me sorprende que la diferencia entre ambos no sea suficientemente clara para muchos. Hay sitios que utilizan tags, otros que utilizan categorías y otros que hacen uso de ambos. A continuación trataré de anotar algunos aspectos importantes de ambos esquemas para comentar sus beneficios y algunos casos en que uno sea más apropiado que otro.

Categorías

Las categorías son un sistema de asociación de contenido con uno o más temas. Permitendefinir y agrupar la información estableciendo relaciones. Las categorías tienen estructuras planas (un nivel) o jerárquicas (múltiples niveles). Establecen una relación de dependencia del tipo pertenece a.

Por ejemplo:

• Recetas
  • Postres
    • Fruta
      • Manzanas
      • Peras
      • Naranjas
      • Sandías

Tags

Los tags, o keywords, son términos simples que hablan de una propiedad o característica de la información, pero no la define ni la agrupa jerárquicamente. Es información sobre la información, o un metadato. Un nodo o unidad de información puede tener uno o más tags, relacionados o no, cada uno de los cuales se refiere a una característica específica del objeto, pero que no lo clasifica o categoriza. Por ejemplo:

Manzanas

fruta, vegetales, postre, verde, roja, dulce

En este caso, cada uno de los tags habla sobre una propiedad del objeto Manzana, pero no son categorías a la que éste pertenezca. Se trata de una estructura plana de términos que lo caracterizan, en un esquema de es o tiene.

Dado que ambos esquemas son diferentes, pero no son opuestos, es posible utilizarlos simultáneamente para obtener una mayor riqueza en la organización de la información. Una estructura de clasificación es útil, por ejemplo, para establecer un esquema de navegación jerárquico. Los directorios son un muy buen ejemplo de esto.

Los tags, en cambio, permiten alimentar muy precisamente un buscador, porque identifican los términos más relevantes de un contenido. Esto es particularmente importante para contenido no textual, como fotografías, videos y audio, casos en los que no es fácil extraerlos automáticamente.

Existen casos en que es posible beneficiarse del uso de ambos esquemas por su complementariedad. Por ejemplo, Spurl.net, un organizador de bookmarks, permite organizar los bookmarks en categorías y asignarles tags. Esto facilita el encontrar la información mediante el uso de un buscador o explorando directamente las categorías o los tags.

Un factor adicional de los tags es el uso en esquemas colectivos, conocidos como folksonomía, en que cada usuario puede agregar tags a diferentes contenidos, de modo que se complementan entre ellos y ayudan a describir de modo más completo al contenido.

En el rediseño de una intranet que realicé hace poco, se definieron dos esquemas de categorización diferentes: uno centrado en los contenidos y otro en la estructura de la institución. Por ejemplo, un formulario de solicitud de vacaciones correspondería a la categoría Formularios, según su tipo de contenido y a Recursos Humanos desde la perspectiva de la organización. El primer esquema se utilizó para navegar el sitio y el segundo para aportar un esquema complementario. Adicionalmente, se sugirió el uso de tags para que los propios usuarios pudieran ayudar a definir los contenidos de un modo más eficiente y con una perspectiva centrada en los usuarios, desde abajo hacia arriba (orgánica), antes que desde arriba hacia abajo, como es el caso con los esquemas de clasificación predefinidos.

En este caso, los tags deberían contribuir a alimentar las descripciones
de contenidos mediante los metadatos, y de este modo se pueden mejorar o precisar los resultados de búsqueda.

En suma, hemos visto que:

• las categorías ordenan y agrupan contenido
• los tags hablan de características del contenido, pero no lo agrupan
• las categorías pueden ser jerárquicas
• los tags son planos, sin jerarquías
• las categorías determinan a qué pertenece el contenido
• los tags hablan de qué es o que tiene el contenido

Es cierto que se pueden realizar evaluaciones de usabilidad en las fases finales de un proyecto, pero los riesgos aumentan mucho respecto a incorporar prácticas y pautas de usabilidad desde la etapa de diseño. Si los errores o problemas se detectan de modo temprano, el costo de corregirlos es bajo. Por el contrario, si se detectan problemas al concluir un proyecto, el costo de las correcciones será mucho mayor.

Por esto es importante considerar la usabilidad como una más de las prácticas del diseño de un producto, realizando pruebas desde los prototipos más tempranos y estableciendométricas y objetivos precisos. Así, las revisiones finales y el control de calidad sólo considerará factores menores y se enfocará en comprobar que las pautas se hayan cumplido.

Desde hace bastante tiempo me interesan las metodologías y procesos de desarrollo de proyectos, particularmente las relacionadas con el web, donde la rapidez y flexibilidad es un requisito. Es un hecho que resulta vital contar con un proceso definido y adaptable, que permita resolver los problemas del desarrollo de proyectos de un modo eficaz. Factores como la optimización de procesos, reproductibilidad de las actividades, modularización e incluso manejo de riesgos justifican de sobra la adopción o creación de un proceso de desarrollo. Sin embargo, las metodologías existentes se enfocan al desarrollo de proyectos de software, en los que la funcionalidad es el eje del desarrollo y el factor humano es un dato más dentro de esta perspectiva, pero normalmente bastante disminuído:

• UML con Rational Unified Process
• Feature Driven Development
• Xtreme Programming

Un factor común en la mayoría de los enfoques de la gestión de proyectos es el considerar cuatro etapas o fases principales, en una simplificación extrema esto es aproximadamente como lo siguiente:

Análisis

Como factor común la primera etapa consiste necesariamente en asimilar el problema, conocerlo y dimensionarlo para poder tener una visión completa de él. Normalmente esto significa establecer descripciones simples del problema, para luego ir progresivamente profundizando en sus detalles mediante la definición de requerimientos, identificación de la audiencia, etc.

Diseño o Planificación

Luego de la primera etapa, teniendo una definición completa del problema, se comienza a planificar la solución, tanto desde la perspectiva del manejo de proyecto, considerando la definición de roles, actividades, plazos, costos, etc., así como desde el diseño lógico, la planificación concreta de la solución.

Desarrollo

Con la planificación y diseño conceptual resueltos, se procede a desarrollar las piezas necesarias que compondrán la solución.

Distribución, Transición o Implantación

Finalmente, luego del desarrollo de las piezas que constituyen la solución, se procede a realizar las pruebas finales y se distribuiye el producto al entorno del cliente.

¿Y qué Ocurre con el Factor Humano?

Ninguno de los procesos y metodologías que he conocido considera de modo central el enfoque de diseño centrado en el usuario. RUP incluye algunos roles y actividades relacionadas, pero en rigor sólo se trata de componentes menores del proceso de desarrollo, todo el problema se enfoca básicamente desde la perspectiva de desarrollo, de ingeniería de software.

Por otro lado, el Diseño Centrado en el Usuario o User Centered Design (UCD) es más bien una disciplina, o un conjunto de ellas, que define una filosofía, antes que un proceso concreto de desarrollo. Naturalmente, las herramientas permiten establecer un proceso que se complemente con los procesos de ingeniería de software y permita crear productos más completos, funcionales y fáciles de usar. Ése es el desafío de quienes trabajamos en esta área: hacer notar que el desarrollo de software es importante en la medida que el propósito esté claro, y que no es un objetivo en sí mismo. Hablo de software porque inevitablemente nuestro medio, el web, es en mayor o menor medida un problema de software, pero antes que todo, es un problema de comunicación.

Personalmente procuro sistematizar mis propios mecanismos de trabajo y establecer una metodología lo más clara posible, con un proceso predefinido y adaptable, que contribuya a facilitar el desarrollo de los proyectos actuales y futuros. Esto es un proceso dinámico que permanentemente va evolucionando en la medida que se refinan los procedimientos y se agregan nuevas herramientas.

En concreto, las principales disciplinas relacionadas al diseño centrado en el usuario, al menos en lo que concierne al web, son la Arquitectura de Información, la Usabilidad, elDiseño de Interacción, Diseño de Interfaces y el Diseño Gráfico. En particular, soy de aquéllos que consideran la Accesibilidad como una subdisciplina de la Usabilidad, fundamentalmente porque se trata de usabilidad aplicada a tipos de usuarios con requerimientos concretos comunes.

La relación entre todas estas disciplinas es estrecha y los límites en muchos casos son difusos, pero finalmente contribuyen a generar lo que conocemos como Experiencia de Usuario. Los siguientes gráficos ilustran cómo cada una de estas disciplinas participa dentro del proceso de desarrollo y cómo se relacionan en términos de dependencias y temporalmente:

Este diagrama muestra las curvas de participación de las diferentes disciplinas durante el desarrollo de un proyecto, o de una iteración de un proyecto mayor. Las displinas se extienden en las etapas que identificamos representando el tiempo o el momento en que participan. Así, una de las primeras en intervenir es la arquitectura de información, capturando requerimientos, identificando grupos de usuarios, contenidos, etc. Del mismo modo, su protagonismo declina finalizando la etapa de diseño. El diseño de interacción tiene un rol relevante que en algunos caso puede reemplazar a la AI cuando el foco está más en la funcionalidad que en el contenido. Un muy buen punto sobre esto lo plantea Garrett en el clásico diagrama de Experiencia de Usuario, expandido en su libro The Elements of User Experience: User-Centered Design for the Web. Luego continúa el diseño de interfaces, concretando las definiciones del diseño de interacción. A éste le sigue el diseño gráfico, que debe entregar la experiencia estética junto con potenciar el contenido mediante códigos visuales. Casi transversalmente, la usabilidad participa durante todo el proyecto, cautelando que el resultado sea usable.

Por mucho que intentemos establecer un ambiente familiar y apropiado para los tests de usuarios, es fundamental tener claro que es imposible reproducir en condiciones de laboratorio la forma en que un usuario se comporta cuando utiliza libremente y sin presiones una aplicación. Desde la perspectiva de usabilidad, es importante observar directamente a los usuarios, pero es necesario compensar y tener claro que, por mucho esfuerzo que pongamos:

• Los usuarios no están en su ambiente natural, ni realizando las tareas de un modo real, sino siguiendo las instrucciones de los evaluadores
• En laboratorio el usuario no es interrumpido por sus compañeros de trabajo, ni recibe mensajes instantáneos, ni revisa el email con la misma frecuencia, por lo tanto no tiene que dejar y retomar la tarea como haría en el mundo real
• El usuario se sentirá evaluado, sin importar cuánto insistas en que no es una evaluación de su desempeño, sino del software
• El nivel de tolerancia a los problemas es mayor, y la tarea será abandonada mucho después de lo que lo haría en su entorno natural
• Muchos usuarios se culparán a ellos mismos por lo errores, antes que al software
• La motivación para finalizar una tarea es diferente en el laboratorio, en el que sedesafía tácitamente al usuario a finalizarla

No estoy tratando de descartar el test de usuarios sino simplemente apuntando ciertos factores que deben ser considerados. Aproveché de comentar sobre esto porque coincidentemente me topé hoy, mientras revisaba mis feeds en Bloglines, con dos artículos relacionados de algún modo: When Do Users Really Give Up? , de Heidi Adkisson y Usability Stockholm Syndrome de Jensen Harris.

Después de todo, cualquiera que haya realizado un test de usabilidad sabe lo importante que es, pese a todo, observar a los usuarios de primera mano.

Aunque con unos días de retraso, no puedo dejar de comentar un par de cosas que me parecieron relevantes del fin de semana recién pasado. En Chile las transmisiones de mando de un presidente saliente al recién electo se realizan tradicionalmente los 11 de marzo. Sí, extraña coincidencia con el 11M español. Pero este 11 de marzo fue especial: asumió laprimera mujer electa Presidenta de la República. Esto por sí mismo ya es digno de comentario, aunque en realidad lo que quiero destacar es un detalle: la ceremonia de traspaso fue transmitida por cadena nacional con closed caption y lenguaje de señas.

Hace un tiempo atrás había comentado la iniciativa de algunos canales locales de implementar closed caption en sus transmisiones, inicialmente en los noticiarios centrales y ahora en varios de sus programas. Pero una cadena nacional de televisión ya es otra cosa.

Esto me pareció una señal muy positiva de políticas de accesibilidad y ciertamente una promisoria forma de comenzar un gobierno. Los dejo con algunas fotos de la transmisión, incluyendo el closed caption y la traducción a lenguaje de señas.

Hay problemas que frecuentemente retornan cuando estás diseñando una interfaz, básicamente porque no terminas de darles una solución aceptable. En este momento estoy pensando en particular en un problema muy común: la ejecución de un pago en línea. ¿Cómo etiquetar la acción pagar? Fácil, Pagar. Perfecto, eso lo entiende claramente cualquier hispanohablante. Pero ahora viene el problema: ¿cómo llamas a la acción deabortar una tarea, en este caso un pago? Siempre he creído que abortar tiene más implicaciones que las que quisieras para una interfaz, por lo tanto la omito y busco una alternativa. Cancelar suena razonable. Pero hay un problema: la segunda acepción de cancelar es Acabar de pagar una deuda, según la RAE. No sé realmente qué ocurre en otros lugares, pero en Chile esta acepción es de uso común. No es raro escuchar a alguien decir que ha cancelado una cuenta, refiriéndose a que la ha pagado. En una ronda reciente de testeos de usabilidad observé a varios usuarios dudar ante la presencia de dos botones etiquetados Cancelar y Pagar.

Entonces, la pregunta es obvia: ¿cómo etiquetar la acción Cancelar para evitar la confusión? ¿Alguien ha tenido mejores resultados?

Hace unos días atrás les mostré el equipo que utilicé para realizar y registrar algunas evaluaciones de usabilidad. La ventaja del registro en video es que se puede repasar la sesión de evaluación para observar con más detalle ciertos aspectos o incluso discutirla en grupo con otros evaluadores.

Pues bien, la configuración que les comenté antes estaba compuesta por una cámara de video digital para registrar la actividad del usuario y un software para el registro de pantalla, o captura de pantalla a video. En esa oportunidad utilicé Camstudio, una aplicación open source (al menos hasta la versión 2.0) que permite capturar la pantalla sin afectar la actividad del usuario, aunque obviamente éste debe estar enterado del registro que se realiza y lo debe autorizar. El problema es que posteriormente hay que montar el video y editarlo, y eso puede ser un gran problema.

Finalmente, me decidí a probar una configuración mucho más simple y compacta: Camtasia Studio 3. Camtasia permite capturar la pantalla en video, pero junto con eso, es posible utilizar una webcam para registrar la actividad del usuario e insertarla directamente en el registro de pantalla en un formato picture in picture. Esto, naturalmente, ocurre sin que el usuario esté viendo su imagen en la pantalla, ambos videos se combinan directamente en el software y el usuario no lo percibe. Con una webcam de buena calidad, con micrófono integrado, y un notebook de capacidad razonable (el mío es un Toshiba Satellite, Pentium 4 de 3.2GHz y 512 RAM) se puede conseguir un desempeño impecable y un registro de calidad. La grabación producida por Camstudio se puede exportar a una serie de formatos para distribución o revisión posterior (Flash, avi, QuickTime, etc.), con opciones excepcionales como la posibilidad de generar un menú de navegación basado en marcadores insertados manualmente en el proyecto.

Este tipo de laboratorio resulta altamente portátil y mucho más cómodo que una cámara de video con el correspondiente trípode, más el micrófono y cables extra. Más importante aún, resulta mucho menos intimidatorio y, por lo tanto, permite obtener una reacción más natural de los participantes.

Bien, los dejo con algunas fotos de la disposición de los elementos en esta ocasión.

Durante sesiones de pruebas de usabilidad con usuarios, user testing, he observado que es común que se presenten problemas al momento de ingresar la arroba (@) que forma parte de la estructura de una casilla de correo electrónico. Recordemos que la estructura de una casilla es básicamente usuario X en el servidor Y, donde la parte del en está representada por @ (at en inglés). Pues bien, si la estructura básica de un email es reconocible, y esperamos siempre encontrar el caracter @, ¿por qué exigirle a los usuarios que lo escriban? Lo planteo basándome en lo siguiente:

• el caracter @ siempre deberá formar parte de una casilla de correo electrónico
• el resto de la estructura, usuario y servidor, es variable
• las configuraciones de teclado e idioma hacen que para los usuarios sea un problema encontrar la forma de obtener el caracter @ en un teclado al que no están habituados

Por lo tanto, ¿no sería mucho más razonable utilizar una estructura como la siguiente?

El HTML básico para esto sería:

<form action=”#” name=”test” method=”get”>
<fieldset>
<legend>Patrón de ingreso de email</legend>
<label>Email: <input type=”text” name=”email-name” id=”email-name” /> @ <input type=”text” name=”email-server” id=”email-server” /></label>
</fieldset>
</form>

Para todos los efectos prácticos (validación, almacenamiento, etc.), el email estaría compuesto por la unión de los dos campos, con una @ entre los dos: email-name@email-server. ¿Alguien ve algún inconveniente razonable para no usar esto?