Accesibilidad web: Marcador de posición en los formularios

Los marcadores de posición en los campos de formulario son perjudiciales

El texto del marcador de posición dentro de un campo de formulario dificulta que las personas recuerden qué información pertenece a un campo, así como verificar y corregir los errores.
También plantea cargas adicionales para los usuarios con dificultades visuales y cognitivas.
Las descripciones o consejos ayudan a aclarar qué se incluye dentro de cada campo de formulario y, por lo tanto, mejorar las tasas de finalización y conversión.

marcador de posición en los formularios

Desafortunadamente, los marcadores de posición en los campos de formulario a menudo perjudican la usabilidad.

Etiquetas y marcadores de posición

Las etiquetas le dicen a los usuarios qué información pertenece a un campo de formulario determinado y generalmente se ubican fuera del campo de formulario. El texto del marcador de posición, ubicado dentro de un campo de formulario, es una sugerencia, descripción o ejemplo adicional de la información requerida para un campo en particular. Estas sugerencias generalmente desaparecen cuando el usuario escribe en el campo.

Marcadores de lugar que reemplazan etiquetas

Algunos formularios reemplazan las etiquetas de campo con texto de marcador de posición en el campo para reducir el desorden en la página o acortar la longitud del formulario.

A continuación, voy a enumerar 7 razones principales por las que los marcadores de posición no deben usarse como reemplazos de etiquetas de campo.

1. El texto de marcador de posición que desaparece afecta a la memoria a corto plazo

Si el usuario olvida la pista, lo que la gente suele hacer al completar formularios largos, debe borrar lo que escribió y, en algunos casos, hacer clic fuera del campo para volver a mostrar el marcador de posición. En un mundo ideal, los usuarios estarían completamente enfocados al completar un formulario.

En formularios simples, de uso frecuente, con uno o dos campos, como un cuadro de búsqueda o un formulario de inicio de sesión, los usuarios pueden adivinar a qué se deben ingresar.

2. Sin etiquetas, los usuarios no pueden verificar su trabajo antes de enviar un formulario.

La falta de etiquetas hace que sea imposible para los clientes mirar el formulario y asegurarse de que sus respuestas sean correctas.

Del mismo modo, los navegadores que completan automáticamente los campos de formulario pueden completar la información de forma incorrecta. Si no hay etiquetas, o si las instrucciones especiales ya no están visibles, los clientes deben revelar el texto del marcador de posición eliminando el texto de cada campo uno por uno para verificar que coincida con la descripción.

3. Cuando se producen mensajes de error, las personas no saben cómo solucionar el problema.

Si el formulario se ha completado, pero no hay etiquetas o instrucciones visibles fuera de los campos del formulario, los usuarios tienen que volver a cada campo para revelar la descripción a fin de corregir el error.

4. El texto del marcador de posición que desaparece cuando el cursor se coloca en un campo de formulario es irritante para los usuarios que navegan con el teclado.

Las personas que usan la tecla Tab se mueven rápidamente de un campo a otro, y no se detienen a estudiar el siguiente campo antes de buscarlo.

5. Los campos con cosas en ellos son menos perceptibles.

Los estudios de seguimiento de ojos muestran que los ojos de los usuarios se sienten atraídos por los campos vacíos.

6. Los usuarios pueden confundir un marcador de posición con los datos que se completaron automáticamente.

Algunos usuarios suponen que el texto del marcador de posición es un valor predeterminado y saltean el campo por completo. Lo más cómodo es dejar el campo vacío.

7. Ocasionalmente, los usuarios tienen que eliminar manualmente el texto del marcador de posición.

A veces, los marcadores de posición no desaparecen cuando los usuarios mueven el foco de entrada al campo. Si el marcador de posición permanece en el campo como texto editable, los usuarios se ven obligados a seleccionarlo manualmente y eliminarlo. Esto crea una carga innecesaria para los usuarios y aumenta el costo de interacción de rellenar el formulario.

A veces, el marcador de posición se atenúa cuando el cursor se coloca en un campo de texto. Desafortunadamente, este patrón de interacción es raro y los usuarios no están familiarizados con él: algunos todavía piensan que tienen que eliminar el texto manualmente. A menudo se requieren algunos intentos fallidos y muchos clics para darse cuenta de que pueden comenzar a escribir sobre el texto atenuado.

Texto de marcador de posición además de etiquetas

Usar texto de marcador de posición en combinación con etiquetas de formulario es un paso en la dirección correcta. Las etiquetas fuera de los campos del formulario hacen que la información esencial esté visible en todo momento, mientras que el texto de marcador dentro de los campos del formulario se reserva para información adicional.

Sin embargo, incluso al usar etiquetas, colocar sugerencias o sugerencias importantes dentro de un campo de formulario puede causar los 7 problemas mencionados arriba.

Si algunos de los campos requieren una descripción adicional que es esencial para completar el formulario correctamente, es mejor colocar ese texto fuera del campo para que esté siempre visible.

Marcadores de posición y accesibilidad

Un último tema a considerar es que el texto del marcador de posición generalmente es malo para la accesibilidad.

Tres de los mayores problemas de accesibilidad son los siguientes:

El color gris claro predeterminado del texto de marcador de posición tiene un contraste de color pobre en la mayoría de los fondos. Para los usuarios con problemas visuales, el contraste deficiente del color dificulta la lectura del texto. Debido a que no todos los navegadores permiten que el texto de marcador de posición tenga un estilo mediante CSS, este es un tema difícil de mitigar.

Los usuarios con dificultades motoras son los que lo tienen más difícil. Los marcadores de posición pueden ser problemáticos: los marcadores de posición que no desaparecen requieren más interacción con el teclado o el mouse para eliminarse.

Por otra parte, si hablamos de personas con problemas visuales, no todos los lectores de pantalla leen el texto del marcador de posición en voz alta. Los usuarios ciegos pueden perder la pista por completo si el software que utilizan no menciona el contenido del marcador de posición.

 

Accesibilidad web: Cómo funciona un lector de pantalla

Cómo funciona un lector de pantalla

Para aquellos usuarios que usan software de lectura de pantalla como JAWS, NVDA o VoiceOver para acceder a la información en la Web, la experiencia del usuario puede ser bastante diferente de la de quienes pueden ver visualmente el contenido.Pero la gente prefiere pasar directamente a los detalles técnicos:

  • ¿Qué teclas presionar?
  • ¿Con qué lector de pantalla debería probar?
  • ¿Qué navegador debería usar?

 

lector_de_pantalla

Si bien todas estas consideraciones son importantes, lo mejor es dar un paso atrás y preguntarnos:

¿Cómo es la experiencia y cómo puedo simular esa experiencia si puedo ver la pantalla?
Para ello, lo vamos a explicar con un ejemplo muy claro para que se entienda bien.

Una puerta abierta

Imagina que acabas de abrir una puerta y estás mirando una gran sala de conferencias.
En el centro de la sala hay una gran mesa de conferencias con 10 sillas (5 en cada lado de la mesa).

Sentados en la mesa hay 2 hombres y 2 mujeres. Las 4 personas están sentadas en el mismo lado de la mesa (están frente a la puerta en la que estás parado). En el otro extremo de la sala (detrás de la gente sentada en la mesa) hay 3 ventanas grandes que dan a un patio con bancos, flores y árboles pequeños.

En el lado derecho de la sala hay un mostrador con una cafetera y un microondas encima.

El lado izquierdo de la sala tiene un gran televisor de pantalla plana montado en la pared.

Suponiendo que no está familiarizado con el diseño de esta sala, ¿qué es lo primero que haría al abrir la puerta? Escanear visualmente la habitación de izquierda a derecha. Algunos la pueden escanear de derecha a izquierda. Otros pueden primero mirar la mesa en el centro y luego escanear el perímetro de la habitación.

Sin embargo, no importa cómo lo hagas, la mayoría escanearía la habitación de alguna manera con la vista para tener una idea rápida del diseño y el contenido de la sala.
El escaneo sólo puede tomar unos segundos y la mayoría ni siquiera se darán cuenta de que lo hicieron.

A continuación, nos podemos centrar en ciertos elementos de interés, como las personas sentadas en la mesa o en la televisión de pantalla plana.

Una habitación oscura

Ahora, imaginemos la escena y esta vez cuando abramos la puerta, la habitación estará completamente a oscuras. No hay luz y no se puede ver absolutamente nada a primera vista. Sin embargo, nos han dado una pequeña linterna y cuando la encendemos, la luz nos permite ver un área pequeña a la vez.

¿Cómo observarías ahora el contenido de la habitación?

Algunos pueden mover la luz de izquierda a derecha comenzando por los pies y alejándose.
También se puede empezar desde la parte posterior de la habitación y mover la linterna, mientras que otros pueden apuntar la linterna al azar en varios lugares de la habitación sin un patrón en particular. A medida que mueva la luz por la habitación, tendrá que construir un mapa mental o una imagen de lo que hay en la habitación y cómo está distribuida.
La construcción de este mapa mental llevará mucho más tiempo que el escaneo visual de la sala cuando todas las luces estaban encendidas.
A medida que movemos la linterna, tendremos que recordar cada cosa que hemos visto y cómo se relacionan todas juntas.

Si olvidamos dónde se encuentra algo, llevará más tiempo localizarlo:

¿el mostrador con la cafetera estaba en el lado derecho de la habitación o estaba en la parte de atrás? ¿Cuántas personas había en la mesa, 4 o 5?

Responder estas preguntas cuando puede ver toda la habitación a la vez requerirá poco esfuerzo, pero contestarlas cuando solo puede ver un área pequeña a la vez llevará mucho más tiempo.

Un escenario análogo

Este segundo escenario es análogo a cómo un usuario de lector de pantalla revisa una página web o una aplicación de móvil.

Si bien los comandos del teclado o los gestos táctiles pueden mover el software de lectura de pantalla alrededor de la página, solo es posible leer una cosa a la vez.
No hay forma de que el usuario con discapacidad visual tenga una visión general rápida (de 1 a 3 segundos) de la página, similar a lo que podría hacer alguien que pueda ver la pantalla.

Afortunadamente, si se utilizan técnicas de navegación de página accesibles como encabezados o regiones, esto puede ayudar a los usuarios del lector de pantalla a enfocarse en ciertas áreas de la página.

Volviendo a nuestro escenario de habitación oscura desde arriba, imagina que ahora hay pequeños puntos rojos de luz en los elementos clave de la habitación: como la mesa, el mostrador, la televisión y cada persona sentada en la mesa. Hay que usar la linterna para mirar alrededor, pero los puntos rojos le dan una idea de dónde se encuentran las cosas más importantes.

Otro desafío importante que pueden enfrentar los usuarios de lectores de pantalla es cambiar dinámicamente el contenido de una página.

Volviendo a los ejemplos de habitaciones claras y oscuras, imagina que uno de los hombres se levanta y se mueve al otro lado de la mesa.

Ahora hay 2 mujeres y 1 hombre en un lado de la mesa y 1 hombre en el otro lado.
En el ejemplo de la habitación iluminada, lo más probable es que notemos el movimiento mientras sucede. Incluso si no estuviéramos mirando directamente al hombre que se movió, probablemente notaríamos el movimiento por el rabillo del ojo y nos percatamos de lo sucedido.

En cuanto al ejemplo de la habitación oscura, sería muy difícil saber que algo sucedió a menos que tengas el haz de la linterna directamente sobre el hombre que se movió en el momento preciso.
Es más probable que nunca sepa que se movió hasta algún momento después, cuando mueve la luz sobre la silla que dejó libre.

En efecto, esto es lo que sucede cuando el contenido de la página cambia pero no alerta el software de lectura de la pantalla. Es posible que el usuario nunca sepa que algo cambió en la página a menos que se muevan a través de la nueva información y se den cuenta de que ahora es diferente.

Esto que he explicado se resuelve asegurando que con el contenido dinámico se usen técnicas como alertas o regiones en vivo que hacen que el software de lectura de pantalla anuncie la información actualizada al usuario.

En nuestro escenario de la habitación oscura, el hombre puede anunciar verbalmente que se está moviendo de un lado de la mesa al otro. Incluso si la luz no estuviera en él, escucharías el anuncio y entenderías mejor lo que está cambiando.

En una ilustración final, tomemos las ventanas que dan al patio. En el escenario de la habitación iluminada, se podrá ver rápidamente que las ventanas dan a un patio con bancos, flores y árboles. Sin embargo, en el ejemplo de la habitación oscura, incluso si apuntabas la luz hacia las ventanas, no podrías ver lo que estaba afuera.
Esto ilustra elementos visuales como imágenes que no tienen una etiqueta de texto asociada.
Por ejemplo, el software de lectura de pantalla puede identificar que una imagen está presente en una página, pero la única forma en que puede comunicar información sobre la imagen es a través del texto alternativo que se le asigna.
Sin la etiqueta de texto, el usuario del lector de pantalla no tendría idea de qué se muestra en la imagen. En el ejemplo de la habitación oscura, se podría colocar un letrero junto a las ventanas con una descripción de lo que aparece afuera. Cuando usemos la linterna, entonces podremos leer el letrero.

 

Usabilidad web: “Miro y entiendo” – Daniel Mordecki.

En esta entrada voy a hablar del libro de Daniel Mordecki “Miro y entiendo”.

Miro y Entiendo es una guía práctica de usabilidad. Parte de los conceptos teóricos y definiciones básicas, desarrolla las metodologías y técnicas centrales de la disciplina y aporta consejos prácticos para su utilización, con ejemplos y casos de la vida real.

miro_y_entiendoEl libro comienza con una gran pregunta:

¿Qué es la usabilidad?

“La usabilidad es la disciplina que tiene como objetivo reducir al mínimo las dificultades de uso inherentes a una herramienta informática, analizando la forma en que los usuarios utilizan las aplicaciones y sitios Web con el objetivo de detectar los problemas que se les presentan y proponer alternativas para solucionarlos, de modo de que la interacción de dichos usuarios con las aplicaciones y sitios Web sea sencilla, agradable y productiva.”

El autor indica que todos los profesionales de la usabilidad tienen que ser persistentes en la tarea de hacer sitios web fáciles de usar, y de ahí deriva algunos atributos de la usabilidad:

  • Todas las interfaces se pueden usar, por muy difícil que sea.
  • Los problemas de usabilidad nunca son catastróficos.
  • No hay una solución puntual

Nos cuenta que la usabilidad se pone de manifiesto por tres fases: la computación, la percepción y la interacción.

El Diseño de Interacción se basa en 4 pilares fundamentales:

Elementos de la experiencia de usuario

El modelo divide los elementos de la interfaz en 5 grandes grupos, que describiremos partiendo de los cimientos conceptuales y subiendo hacia las capas más concretas, donde se efectúa realmente la interacción en la práctica.

elementos de interfaz de usuario

 

En la primera capa se determinarán los objetivos que se pretenden conseguir con tres preguntas claves:

  • ¿Por qué necesitamos el sitio?
  • ¿Para quién es el sitio?
  • ¿Qué debe suceder para que estemos satisfechos?

El alcance de un sitio Web está determinado por los objetivos que un visitante podrá cumplir en él. Tiene una relación directa con los objetivos, pero mien-tras los objetivos reflejan el punto de vista de la organización, el alcance expresa el punto de vista de los usuarios del sitio.

La arquitectura de la información es la base que permite definir cómo se va a navegar el sitio.hay una fuerte relación entre la organización de categorías y la organización de menús.

El autor también plantea cómo se originan las búsquedas de los usuarios en función de las necesidades que se le presentran en el momento.

Un modelo de interacción supone un conjunto pequeño de funcionalidades básicas o primitivas sobre las que se construyen las funcionalidades más complejas.

Es el conjunto de primitivas que se van a utilizar para construir la interfaz y aplicarlas consistentemente a lo largo de todo el sitio o la aplicación.

La interfaz es, desde el punto de vista estrictamente técnico, el conjunto de puntos de contacto del usuario con el sitio a través de la computadora e incluye todo lo que el sitio emite o muestra (salida o “output”) y todo lo que el sitio recibe (entrada o “input”). Es lo que se muestra en la pantalla, sumado al conjunto de acciones que el usuario puede realizar utilizando el mouse y el teclado. Es la parte sensible (visible, tocable, audible) de la interacción.

Miro, leo, pienso: Tres niveles de interacción

Para crear páginas y sitios Web fáciles de comprender y usar es importante pasar al otro lado de la pantalla e intentar entender cómo los visitantes de esos sitios interactúan con ellos.

La interacción de los visitantes con un sitio web se concibe en tres niveles: mirar, leer y pensar. La interacción se desarrolla simultáneamente en los tres niveles, se combinan e interactúan permanentemente entre sí y el visitante obtiene su experiencia como un todo, sin necesidad de tener consciencia alguna sobre qué nivel fue el que aportó qué dato. Cada uno de estos niveles requiere un nivel de atención particular, un esfuerzo consciente particular y retorna al visitante un nivel de resultados particular. 

En este capítulo, lo que más me ha gustado es la facilidad que tiene para transmitir las ideas y conceptos de una forma sencilla y comprensible para todos, fruto posiblemente de su experiencia docente. Por ello, el libro está lleno de consejos prácticos, ejemplos y casos de la vida real, de la aplicación de la teoría en la práctica cotidiana.

Métodos de evaluación de Usabilidad

El autor nos habla entre otras cosas de Jakob Nielsen y los principios heurísticos, así como de técnicas que se usan para trabajar la usabilidad como el test con usuarios, el card sorting, la ley de Fitts, y las normas ISO.

Redactar para la Web

el autor nos hace una introducción de cómo los navegantes leen en Internet y nos proporciona una serie de consejos y características para leer en la Web (mapas de calor, estilos de escritura, técnicas de escritura y cómo organizar el contenido).

Formularios: la Web interactiva

El autor nos da consejos sobre cómo hacer formularios usables, cómo se estructuran, cómo poner las etiquetas, los mensajes de error, etc…

Por otro lado, para finalizar a modo de resumen, resaltar que Daniel Mordecki a lo largo de todo el libro hace uso de la metáfora para facilitar la compresión de los conceptos.

“Quien se focaliza en la tarea de barrer podrá inventar escobas más livianas, con cerda intercambiable y mango irrompible, pero jamás podrá inventar la aspiradora: esto está reservado a los que se focalizan en el objetivo de tener una casa limpia.”

El mensaje que emerge al final del libro es el absurdo de muchos rediseños web, el absurdo de destinar grandes cantidades de dinero y tiempo a cambiar por cambiar, y no a cambiar para mejorar, que es la misión de los profesionales de la usabilidad.

 

Usabilidad web: Mensajes de error en formularios

Mensajes de error en formularios

En esta entrada os voy a hablar de cual es la mejor manera de colocar los mensajes de error en los formularios.

¿Dónde colocamos los mensajes de error en los formularios?

Es importante conocer donde podemos colocar los errores, ya que si no se colocan donde los usuarios esperan verlos, les será imposible completar el formulario.

Cuando los usuarios cometen errores, deben comprender cuáles son esos errores para poder corregirlos y volver a enviar el formulario. Quieren completar el formulario, pero si hacerlo requiere mucho esfuerzo, se irán del sitio web.

¿En la parte superior o alineados con los campos erróneos?

Las dos ubicaciones más comunes para los mensajes de error se encuentran en la parte superior del formulario y en línea con los campos erróneos.

¿Qué ubicación es más intuitiva para los usuarios?

Mostrar todos los mensajes de error en la parte de arriba del formulario produce mucha carga cognitiva en la memoria del usuario. Esto obliga a los usuarios a recordar cada mensaje de error para cada campo erróneo.

Para reducir la carga cognitiva de los usuarios, hay que mostrar los mensajes de error alineados con los campos erróneos. Así pueden corregir los errores de forma más rápida y sencilla.

Ubicación de los mensajes de error de preferencia del usuario

Colocar los mensajes de error en línea con los campos erróneos es mucho más cómodo para los usuarios. Prefieren que los mensajes de error se ubiquen a la derecha del campo.

Los mensajes de error colocados a la izquierda del campo no son buenos para los usuarios. Los mensajes de error colocados sobre el campo causan mayor carga cognitiva seguida de mensajes de error debajo del campo, por lo tanto dificulta la usabilidad de los campos de formulario.

Por qué a la derecha del campo es mejor

Es importante entender por qué es preferible y esperado colocar los mensajes de error a la derecha del campo. De esta forma, los diseñadores pueden educar mejor a los demás sobre cómo se comportan los usuarios cuando toman decisiones de diseño.

El sistema de lectura occidental va de izquierda a derecha. Cuando los usuarios mueven los ojos de la entrada al mensaje de error, se produce una progresión natural que requiere poco esfuerzo mental y visual. Al mover los ojos desde el mensaje de error a la entrada para la corrección también sigue el flujo natural para releer el texto.

mensaje de error a la derecha del campo

Por qué a la izquierda del campo es peor

Colocar mensajes de error a la izquierda del campo va en contra del sistema de lectura occidental. Los usuarios mueven los ojos en la dirección opuesta al flujo de lectura natural cuando aparece el mensaje de error. En lugar de producirse una progresión natural, es antinatural y no es óptima, cuando los usuarios lo que desean es completar el formulario.

Tampoco es intuitivo porque los usuarios esperan elementos de mayor prioridad en el lado izquierdo. Colocar el mensaje de error a la izquierda lo hace más importante que el campo. Pero el campo es más importante porque los usuarios necesitan enfocarse en él para rellenarlo.

Mensaje de error a la izquierda del campo

Por qué sobre el campo aumenta la carga cognitiva

Los usuarios experimentan una mayor carga cognitiva con mensajes de error sobre el campo (es decir, formularios con etiquetas alineadas en la parte superior). Esto es causado por una combinación del mensaje de error y el texto de la etiqueta del campo que confunde a los usuarios.

La proximidad de los dos textos crea un ruido visual que distrae a los usuarios cuando intentan leer el mensaje de error o la etiqueta. Ver ambos textos en su campo de visión hace que sea difícil concentrarse solo en uno de ellos y puede confundirlos.

Mensaje de error encima del campo

Ubicación de los mensajes de error para formularios móviles

Las pantallas móviles carecen del espacio horizontal para mostrar un mensaje de error y un campo, uno al lado del otro. Esto significa que los mensajes de error a la derecha del campo no son la mejor ubicación en los formularios móviles. En su lugar, hay que colocar los mensajes de error debajo del campo.

Mensaje de error abajo del campo

Aunque no se corresponde con el flujo de lectura natural de izquierda a derecha del usuario, sí se corresponde con el flujo de lectura natural de arriba hacia abajo.

Cuando los usuarios leen texto, mueven los ojos de izquierda a derecha bajando una página. Los mensajes de error debajo del campo son menos incómodos que en el campo, porque siguen la progresión de lectura vertical.
Colocar el mensaje de error demasiado cerca de la etiqueta del campo después puede aumentar la carga cognitiva cuando los usuarios leen el texto.

A la derecha o debajo de campo: ¿Cuál es el mejor?

Ambos, a la derecha del campo y debajo del campo son ubicaciones óptimas para los mensajes de error.

¿Pero qué ubicación se debería usar? 

Si deseamos que la implementación tarde menos tiempo en hacerse para ordenadores y dispositivos móviles, la mejor opción es poner los mensajes de error debajo del campo. Implementarlos para ordenadores también los hará utilizables para dispositivos móviles. Si queremos implementar mensajes de error para ambos dispositivos, la mejor opción es colocarlos a la derecha del campo en el escritorio y debajo del campo para dispositivos móviles.

Colocación de mensajes de error intuitivos

Los mensajes de error deben corresponderse con el flujo de lectura del usuario, por lo que los errores requieren menos esfuerzo cognitivo para corregirlos. Cuando los usuarios trabajan y piensan menos, pueden completar el formulario más rápido. Cuanto más rápido ayudemos a los usuarios a superarlo, antes podrán pasar a lo que quieran hacer.

Si quieres saber más sobre los formularios puedes leer la entrada sobre los marcadores de posición.

 

Usabilidad web: Arquitectura de información. Fundamentos

¿Qué es la arquitectura de información?

La arquitectura de información es la disciplina que se encarga del estudio, análisis, organización, disposición y  estructuración de la información en espacios de información, y de la selección y presentación de los datos en los sistemas de información. Facilita de esta manera la localización (o el acceso) de la información contenida en ellos y mejora, así, su utilidad y su aprovechamiento por parte de los usuarios.

arquitectura de información: fundamentos

Arquitectura de información: Fundamentos

El arquitecto de información es la persona que debe identificar la misión (los objetivos) y la visión (las expectativas de los usuarios) de la pagina web, determinar los contenidos y funcionalidades de la página, facilitar el acceso mediante sistemas de organización, etiquetado, navegación y búsqueda y planificar en previsión de futuras modificaciones y crecimiento de la página.

Durante la fase de “estrategia” identifica los objetivos, en la fase de “alcance” las necesidades de los usuarios, en la fase de “estructura” especifica las funcionalidades y requerimientos de la web, en la fase de “esqueleto” el diseño de los sistemas de navegación, organización, etiquetado y búsqueda y en la fase de “interfaz” prototipa la página.

Tipos de necesidad de información

El objetivo habitual de un usuario al acceder a una web es satisfacer una necesidad de información y/o realizar una transacción (por ejemplo comprar un billete de tren).

Desde el punto de vista de las necesidades informativas, se pueden distinguir tres tipos:

  • Necesidad de información concreta (NIC): por ejemplo, “¿qué precio tiene este producto?”
  • Necesidad de información orientada a problemas (NIOP), por ejemplo, “¿cuál es la relación entre la usabilidad y la arquitectura de información?”
  • Necesidad de información exploratoria (NIE), por ejemplo “quiero escoger un buen hotel para este fin de semana”
  • Necesidad de información sobre búsquedas previas (NIBP), es decir, localizar información que ya había localizado previamente.

 

Las estrategias de las que dispone un usuario para satisfacer estas necesidades de información en una página web son:

  • Búsqueda, utiliza la caja de búsqueda y analiza e interacciona con los resultados.
  • Navegación, explora a partir de los enlaces de la web.
  • Ayuda, por comodidad o desesperación reclama que se le oriente y señale dónde se encuentra el contenido.

Componentes o anatomía de la arquitectura de información

Una buena arquitectura de información se sustenta en tres pilares: el contexto organizacional en el que se desarrolla, el contenido que alberga y los usuarios que la visitan y consultan.

Los sistemas, estructuras o recursos para estructurar una web y que definen la AI de un sitio se llaman componentes o anatomía de la arquitectura de información y son los siguientes:

  • Sistemas de organización
  • Sistemas de etiquetado
  • Sistemas de navegación
  • Sistemas de búsqueda
  • Vocabularios o lenguajes documentales

 

Sistemas de organización

Dependiendo de cómo organicemos la información contenida en una web lograremos que los contenidos que alberga sean más fáciles de encontrar por los usuarios. Para hacer un diseño adecuado del sistema de organización es necesario desarrollar correctamente los componentes que lo conforma:

  • Esquemas de organización: sistemas que organizan los grupos de ítems de información contenidos en una página web en grupos a partir de un criterio concreto:
    • Exactos: grupos bien definidos y mutuamente excluyentes, sirven para conocer cosas previamente conocidas:
      • Alfabéticos
      • Cronológicos
      • Geográficos
    • Ambiguos, para localizar contenidos que no conocemos:
      • Tema
      • Tarea
      • Audiencia
      • Metáfora, de la que no hay que abusar, pues si no está bien desarrollada su alta ambigüedad desorienta al usuario.
      • Híbrido, utilización de varios de los esquemas anteriores.
  • Estructuras de organización: sistemas que organizan los grupos de ítems de información resultantes de los esquemas mostrando las dependencias lógicas que existen entre ellos:
    • Estructura jerárquica, una buena arquitectura de información incluye una jerarquía o taxonomía entre sus componentes. Permiten al usuario ubicarse y obtener un modelo mental de la estructura del sitio que visita:Consejos:
      • Diseñarla teniendo en cuenta a los usuarios.
      • Las opciones principales deben estar siempre visibles.
      • Combinarla con los otros tipos de estructuras para ofrecer al usuario flexibilidad a la hora de localizar la información.
      • Las categorías que la conforman deben ser mutuamente excluyentes. Si muchos contenidos pertenecen a varias categorías la taxonomía termina perdiendo su valor para localizar la información.
      • Sobre la anchura (nº de ítems al mismo nivel) y profundidad de la estructura (niveles de división verticales) recomendada se han escrito ríos de tinta
      • Definir la estructura pensando en la escalabilidad del portal, que sea posible incluir nuevas categorías sin modificarla sustancialmente, sin provocar cambios en la imagen mental que tiene el usuario que ya la ha visitado y sin tener que introducir modificaciones visuales en la home.
    • Basada en registros (o en el modelo de base de datos), idóneo para los contenidos bien estructurados y homogéneos
    • Estructura hipertextual (o en red), que debe ser complemento de otros tipos de estructuras y no la única opción de organización de la información. Permite reflejar relaciones menos estructuradas y más creativas existentes entre los contenidos.
    • Estructura secuencial, con un principio y un final claro y un único itinerario de consulta o exploración
    • Estructura en tabla (o matriz), sólo para aquellos contenidos que admitan su representación en una tabla, y debe ser utilizado en combinación con otras estructuras.

Algunos problemas que debemos resolver al diseñar el sistema de organización son:

  • La ambigüedad del propio lenguaje lingüístico.
  • La heterogeneidad de los contenidos.
  • Las diferentes perspectivas, siendo imprescindible tener en cuenta a nuestro público objetivo.
  • Los intereses de la organización, que es necesario conocer a fondo.

El mejor consejo es que, dependiendo del contexto y los usuarios, elegir y articular aquellos sistemas que sean realmente útiles, intentando simultanear esquemas exactos y ambiguos para ofrecer al usuario diferentes vías para acceder y localizar la información. La combinación de diferentes estructuras, si se combinan adecuadamente, permiten obtener un sistema sólido, coherente y flexible.

Sistemas de etiquetado

A la hora de definir el sistema de etiquetado debemos tener cuidado con:

  • La ambigüedad intrínseca al lenguaje, tanto sintáctica, léxicas (sinonimia y polisemia) como semántica (uso de metáforas, ironía, etc.)
  • La arbitrariedad, evitando utilizar términos con un significado diferente con el que normalmente se asocian.
  • La desorientación que producen las etiquetas que no anticipan ni dan pista sobre lo que esconden.
  • Las etiquetas que utilizamos se asociación al branding de la empresa, y unas etiquetas mal elegidas pueden dar una mala impresión de la misma.

Todo ello puede suponer que el usuario abandone la página porque no encuentra lo que necesita.

Las etiquetas pueden ser textuales o icónicas, estas deben utilizarse siempre junto a las primeras porque son intrínsecamente ambiguas.

Los sistemas de etiquetado con formato textual que deben planificarse son:

  • Enlaces contextuales. Deben identificarse visualmente como tales, diferenciar los que sean externos y utilizarse de forma consistente. No deben ser ambiguos y se debe tener en cuenta el contexto en el que se insertan, siendo además independientes del mismo.
  • Títulos. Deben estructurar coherentemente el contenido y su diseño debe reflejar su jerarquía. Tienen que ser descriptivos y coherentes con los literales utilizados en los otros sistemas de etiquetado. Deben ser consistentes a lo largo del sitio tanto en su ubicación como en su aspecto.
  • Opciones del sistema de navegación. Deben ser consistentes y coherente siguiendo un mismo patrón visual y de ubicación a lo largo de todo el sitio. Deben describir adecuadamente los contenidos que incluyen y ser entre ellos lo más excluyentes posibles.
  • Términos de indización. Son el conjunto de etiquetas utilizadas para describir cualquier tipo de contenido en un entorno web y facilitar su localización, búsqueda y recuperación. Su enlace permite acceder al listado de todos los contenidos indizados con ese término y además alimentan el índice inverso del sistema de búsqueda. Cuando los propios usuarios o los autores de los contenidos proponen las etiquetas (tag) hablamos de marcadores sociales. Una folksonomía es el resultado de la agregación de las etiquetas o tags propuestos por uno más usuarios. Se pueden visualizar en forma de listado, nubes de etiquetas, los más populares, etc.

Consejos y recomendaciones

  • Acotar el significado de las etiquetas teniendo en cuenta a los usuarios.
  • Diseñar el sistema de etiquetado de forma global y no etiquetas de forma aislada.
  • Mantener la consistencia tanto en el literal como en el formato.
  • Usar el mismo registro: si usas “linfoma” no uses “dolor de cabeza” sino “cefalea”.
  • Reconocibles por ser conceptos familiares, el usuario no debe tener que aprender su significado.
  • Utilizar estrategias para desambiguar las etiquetas, por ejemplo mediante el contexto (acompañada de otros elementos similares; mediante un texto que la acompañe, etc.)

Orientaciones metodológicas

  • Crear una tabla con tres columnas: etiqueta, explicación de la etiqueta y contenido que representa, para detectar inconsistencias y duplicidades.
  • Involucrar a los autores de contenidos.
  • Involucrar a los usuarios con pruebas de cardsorting.
  • Ver cómo etiquetan nuestros contenidos los usuarios por ejemplo en Del.icio.us
  • Analizar los términos que utilizan los usuarios en el buscador de nuestra web.
  • Aprovechar tesauros y vocabularios controlados ya existentes que podamos adaptar y refinar, pero siempre deben coincidir con nuestra audiencia.

Sistemas de navegación

Son estructuras que ordenan y agrupan los contenidos de una página web bajo unas categorías que forman una clasificación. Nos permiten:

  • Identificar las relaciones entre los contenidos de la web y entre esos contenidos y la página que se está visitando en ese momento.
  • Habilitar y facilitar la navegación entre esos contenidos
  • Orientarnos, saber dónde estamos, que hay aquí, de dónde venimos y cómo podemos ir hacia donde deseamos ir.
  • Formar una imagen mental del tamaño y estructura del sitio.

 

Los usuarios pueden navegar de formas muy distintas: con dirección, cuando buscan una información determinada, sin dirección, cuando ojean la web sin un objetivo claramente preestablecido, además puede navegar en amplitud o en profundidad.

Tipos de sistemas de navegación

  • Sistemas básicos
    • Sistemas integrados
      • Sistemas constantes (o globales)
      • Sistemas locales, deben estar correctamente articulados con el sistema constante.
      • Sistemas contextuales, que permiten identificar contenidos relacionados y enlazar con ellos. Es importante que los contenidos o páginas críticas se enlaces desde otros contenidos.

      Se deben articular estos tres sistemas sin saturar de enlaces y sin que ocupen todo el espacio de la página. Deben situarse de forma consistente, fija y diferenciada entre ellos.

    • Sistemas complementarios, son recursos para localizar información y para orientarse que suelen ser páginas propias e independientes.
      • Mapa del sitio
      • Índices, listado de términos que representan el contenido del sitio, normalmente ordenados alfabéticamente
      • Guías, para introducir a los nuevos usuarios en los contenidos y la funcionalidad de una parte concreta del sitio: wizards, configuradores, visitas guiadas, tutoriales, etc.
  • Sistemas no básicos
    • Sistemas de personalización, estructuras de navegación proactivas que se autodiseñan en función de lo que espera el usuario, ofreciéndole enlaces a partir de su perfil. El principal problema es que los comportamientos pasados no son garantía de inferir sus comportamientos futuros.
    • Sistemas de customización: estructuras reactivas que permiten que el usuario pueda diseñar su propio sistema de navegación. El principal problema es que a los usuarios les pasen desapercibidas estas opciones, que si sus necesidades cambian deben redefinirlas o que simplemente no tengan tiempo de hacerlo.
    • Sistemas de navegación visual, permiten explorar usando recursos icónicos o visuales.
    • Sistemas de navegación social, inferidos a partir del comportamiento de la mayoría de usuarios que visitan la página (lo más popular, lo más comprado, etc.)

Recomendaciones

  • Utilizar recursos de contextualización que permitan al usuario saber dónde se encuentra, adónde puede ir y la relación del contenido con el resto del sitio: incluir siempre el logo de la organización, marcar visualmente las opciones de menú donde nos encontramos, incluir migas de pan, etc.
  • No anular funcionalidades del navegador. Al posicionar el cursor sobre un enlace la URL debe verse en el pie del navegador; no eliminar las barra de menú del navegador al abrir una ventana nueva; no impedir al usuario que utilice el menú contextual del botón derecho; no impedir que la página muestre el scoll cuando sea necesario; permitir que los enlaces visitados cambien de color, etc.
  • Diseño de navegación: incluir siempre un mapa web. Si se usan menús desplegables es mejor que se desplieguen al activarlos y se mantengan desplegados (Chaparro, Minnaert y Phipps, 2000).

    Sistemas de búsqueda

    Utilizados normalmente para localizar información a partir de una necesidad concreta. Ofrecen los resultados que coinciden con los definidos por el usuario en la ecuación de búsqueda. Los problemas a superar son:

    • Ruido: contenidos recuperados no pertinentes, se mide con el índice de precisión.
    • Silencio: documentos pertinentes no recuperados, se mide con el índice de exhaustividad.

    Los sistemas de búsqueda pueden ser:

    • Reactivos: reaccionan frente a la conducta informativa del usuario.
    • Proactivos: ofrecen proactivamente la información al usuario sin que tenga que reclamarla continuamente:
      • Sistemas de difusión selectiva de información (DSI), ofrecen una actualización informativa automatizada sobre un tema concreto a partir de la sindicalización de contenidos.
      • Sistemas de workshop, suministran automáticamente la información dentro de un proceso a partir del perfil del usuario.
      • Agentes inteligentes: infieren el perfil de interés informacional de un usuario a partir de criterios como su histórico de comportamiento o su similitud con el de otros usuarios.
    • RSS, es reactivo porque has de suscribirte y proactivo porque desde ese momento los recibes automáticamente.

 Recomendaciones

  • Evaluar la necesidad de un vocabulario controlado y definir los metadatos implicados en su descripción.
  • Seleccionar como términos de indización ciertos componentes de los contenidos (título, url, etiquetas de los enlaces o títulos de las imágenes)
  • Si se indiza el texto completo de todos los contenidos, introducir recursos como la búsqueda por campos para refinar el resultado y evitar una tasa de ruido elevada.
  • Evaluar si se indiza sólo algunos contenidos, algunas zonas de esos contenidos o algunos componentes determinados de ellos.
  • Indizar los contenidos según el tipo de usuario o audiencia al que va dirigido.
  • Inferir patrones en el comportamiento de los usuarios.
  • Tratar de indizar las páginas según el tipo de contenido.
  • Incluir siempre que se pueda:
    • corrector ortográfico: corrigen automáticamente la ortografía dando alternativas.
    • herramientas fonéticas: para identificar términos con grafías diferentes pero fonéticamente idénticas
    • herramientas de procesamiento del lenguaje natural: obvian las palabras vacías e introducen AND entre los términos propuestos.
    • en función del proyecto, evaluar la inclusión de sugerencias de términos en la caja de búsqueda, que se va adaptando a lo que se escribe y que permiten identificar las búsquedas con más resultados.
  • Poder refinar y mejorar manualmente los resultados de las búsquedas más habituales.
  • Formar a los autores del contenido sobre cómo deben redactar los títulos o etiquetar el contenido.
  • La caja de búsqueda debe estar identificada como tal y cerca del sistema de navegación.
  • Diseñar la interfaz de búsqueda teniendo en cuenta a los usuarios, el tipo de necesidad informativa, la cantidad de información recuperada y el tipo de contenidos a recuperar.
  • En la página de resultado:
    • indicar los términos por los que se ha buscado
    • indicar el número de resultados mostrados y encontrados
    • poner en negrita las coincidencias
    • permitir refinar la búsqueda (no solo semánticamente sino por fecha, lengua, tipo de documento, etc.)
    • permitir realizar búsquedas sólo en los resultados.
    • permitir personalizar el número de resultados a mostrar.
    • poder imprimir o enviar por email los resultados
    • poder guardar la búsqueda, para ello es necesario que sea mediante GET para que tenga una URL propia.
    • ofrecer opciones de ordenación (por precio, por relevancia, por cronología, etc.)

Vocabularios o lenguajes documentales

La indización es la operación en la que se asigna a cada contenido una serie de términos (palabras clave) que representan el tema o temas sobre los que versa. Es una operación de análisis. La clasificación es la operación por la cual se asigna a cada contenido un único término que representa el tema principal sobre el que versa ese documento. Es una operación de síntesis.

La información resultante de la indización y la clasificación suele incorporarse al contenido mediante metadatos asociados para que funcione con los sistemas de organización, etiquetado, navegación y búsqueda.

Un lenguaje documental se constituye a partir de un subconjunto de términos del lenguaje natural (acompañados a veces de números como en el caso de las clasificaciones) para facilitar la búsqueda y recuperación de la información contenida en los documentos.

Aunque el uso de un lenguaje documental reduce el ruido y el silencio en las búsquedas, su construcción y mantenimiento lleva asociado un coste de personal y de tiempo importante, además de que hay que asegurar que se hace correctamente. Por ello hay que evaluar con criterio la necesidad de ese esfuerzo y su viabilidad.

Un lenguaje documental está formado por:

  • El vocabulario del lenguaje documental: subconjunto del lenguaje natural. Se distingue:
    • el término de indización principal (descriptor): es unívoco. Identifica la representación estándar de ese concepto. Por ejemplo, “sacerdote”.
    • término de indización secundario: es sinónimo del principal y una buena representación del concepto que el primero también representa, pero se decide no identificarlo como la representación estándar. Por ejemplo: “cura”, “clérigo”
  • Relaciones semánticas entre los términos de indización, que pueden ser de:
    • Equivalencia: sinónimos, acrónimos, abreviaciones, variantes léxicas, posibles errores ortográficos, cuasisinónimos.
    • Jerarquía, que puede ser:
      • Genérica: soltero-hombre
      • Relación parte-todo: rueda-coche
      • Relaciones de instanciación: Mediterráneo-mar
    • Asociativa: por afinidad semántica o evocación. Por ejemplo, veneno-toxicidad.

Tipos de lenguajes documentales

  • Libres, por ejemplo extraer automáticamente de un texto las palabras que no pertenecen al fichero de palabras vacías.
  • Controlados:
    • Anillos de sinónimos, entre los términos se establecen relaciones de equivalencia pero no de jerarquía ni de asociación. Al hacer una búsqueda se recuperan también los indexados por sus sinónimos. Reduce el silencio en las búsquedas pero aumenta el ruido.
    • Fichero de autoridades, listado de términos principales(con sus respectivos sinónimos) para describir y normalizar un conjunto de entidades (personas, organizaciones, lugares geográficos) ante la variedad de homónimos, sinónimos o nombres con los que puede ser denominada una persona, entidad, obra, tema o concepto. Se utiliza especialmente en la catalogación de los fondos de las bibliotecas.
    • Lista de encabezamientos de materia (LEM), en el cual el encabezado condensa el tema del documento con uno o varios términos. Presentan relaciones asociativas, jerárquicas y de equivalencia. Se usan preferentemente en las bibliotecas y en los centros de documentación cuyos fondos son esencialmente enciclopédicos.
    • Taxonomías, sus términos presentan relaciones de equivalencia y jerarquía pero no asociativas.
    • Clasificación, representa entre sus términos relaciones asociativas, jerárquicas y de equivalencia y algunas veces asocia un código identificativo a cada uno de sus términos.La más utilizada en web es la clasificación facetada para poder clasificar simultáneamente desde distintos puntos de vista, o a partir de diferentes criterios, un mismo conjunto de objetos.Cada una de las clasificaciones o facetas es paralela a las demás en un mismo nivel semántico. Cada faceta sería una etiqueta del sistema de navegación global, o un campo de la base de datos; y las categorías de esa faceta serían las de uno de los sistemas de navegación local, o las de los posibles valores de un campo de la base de datos. Por ejemplo, cada faceta seria (corriente literaria, género literario, etc.) y las categoría (realismo, modernismo,…; novela, poesía,…).
    • Tesauro, se encuentran integrados en los sistemas de navegación y búsqueda. Sus términos presentan relaciones asociativas (términos relacionados, TR), jerárquicas (términos genéricos, TG y términos específicos, TE) y de equivalencia.

 

Usabilidad web: Pioneros y hacedores

Introducción

En esta entrada os voy a hablar del libro “Pioneros y hacedores”.

Pioneros y hacedores

El libro está compuesto por 19 capítulos de distintos autores, expertos en Arquitectura de Información, Diseño Centrado en el Usuario, Usabilidad y Accesibilidad, Ergonomía, Psicología, Diseño participativo y Co-desarrollo, oriundos de Centroamérica, Sudamérica, Norteamérica, Australia y Europa.

Los capítulos, tratan temas 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; de hacer páginas web accesibles y usables.

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

Nos cuenta el caso real de un e-commerce donde estudió la interacción de sus usuarios con los formularios de registro e ingreso. Finalmente, la modificación de un botón supuso un 45% más de usuarios que terminaban las compras y una ganancia adicional de 15 millones de dólares el primer mes tras el cambio, y 300 millones de dólares después del primer año.

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

Steve Krug nos habla sobre las diferencias entre cómo creemos que la gente usa los sitios web y lo que sucede, y es que las páginas no se leen, se hojean; no tomamos óptimas decisiones, nos conformamos con lo suficiente; y no nos interesa averiguar el funcionamiento de las cosas, nos las arreglamos.

Si queréis más información sobre él, os dejo aquí las entradas en referencia a sus libros: “No me hagas pensar” y “Haz fácil lo imposible”

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

Defiende la necesidad de que los sitios web dispongan de una versión móvil. Nos habla de las buenas pautas a seguir en dicha versión y los desafíos que supone.

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

Parte de una anécdota personal con un mando a distancia, que tenía solo dos botones y sin embargo los usuarios interpretaban de diferente manera, para reflexionar sobre la elección de las metáforas en un diseño adecuado de la interacción.

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

Presenta qué es el Diseño de Interacción y la naturaleza de la investigación actual en este campo, para desarrollar lo que podría (y quizás debería ser) el Diseño de Interacción.

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

Ofrecen un panorama general del desarrollo histórico del proyecto llevado a cabo en la Universidad Tecnológica de Sydney (UTS) para aumentar la participación de los estudiantes aborígenes australianos en los cursos IT, y el modo en el que, gracias a su éxito, fue evolucionando hasta llegar a ser un programa permanente en la Facultad de Ingeniería y Tecnología Informática: el Programa de Participación Indígena en IT (IPIT).

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

Introducen y describen los conceptos y aspectos más relevantes de la disciplina Interacción Persona-Computadora, que estudia cómo las personas diseñan, implementan y usan sistemas informáticos interactivos, y cómo las computadoras influyen en las personas, las organizaciones y la sociedad. Aportan también una bibliografía para ampliar y profundizar en el conocimiento de la disciplina.

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

Nos ofrece una introducción a la disciplina Arquitectura de Información, el área de práctica profesional que busca traer orden y coherencia a los medios digitales para lograr que la información sea más fácil de encontrar, navegar y entender a través de múltiples canales y dispositivos.

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

Nos ofrece una introducción a la disciplina Arquitectura de Información, el área de práctica profesional que busca traer orden y coherencia a los medios digitales para lograr que la información sea más fácil de encontrar, navegar y entender a través de múltiples canales y dispositivos.

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

Ya hice una entrada referente a este capítulo. Accesibilidad web: Cómo influye en el SEO

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

Nos habla de las claves y las dificultades para desarrollar un videojuego accesible, para lo cual será muy importante tener presente la accesibilidad desde el inicio del diseño hasta su publicación e implicar a todas las personas que forman parten del proyecto.

Los autores nos presentan un caso práctico, el desarrollo del videojuego Slalom (que se puede descargar gratis para Windows) Es un simulador del deporte “Slalom en Silla de Ruedas” practicado por personas con parálisis cerebral.

También nos ofrecen una bibliogafía muy interesante sobre recomendaciones publicadas por distintas entidades que pueden servir como guías para crear videojuegos más accesibles.

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

En este capítulo trata de acercar la accesibilidad a todo el mundo, mostrándola como algo más cercano al sentido común que a complicadas directrices que haya que seguir.

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. Todos ellos tienen en realidad un conocimiento de accesibilidad y usabilidad que no sabían que tenían.

La autora nos muestra que 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.

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

Nos ofrece y explica una serie de criterios de conformidad para la evaluación ergonómica de las interfaces humano-computadora, que permiten reducir la carga del esfuerzo mental, visual y físico, y de este modo adaptarse mejor a las capacidades humanas.

Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking. El caso de la TV conectada, por Mari Carmen Marcos y Verónica Mansilla

La tecnología Eye Tracking (ET) es una herramienta que complementa al test con usuarios para estudiar la usabilidad y la experiencia de usuario. La utilizaremos cuando nos interese conocer cómo miran los usuarios una interfaz cuando realizan determinada tarea.

Nos hablan de los modelos que existen, de los requisitos de los participantes y de la sala, de las métricas que obtendremos, de la calibración del ET o de los contratiempos que podemos encontrarnos. Otra parte importante del capítulo está dedicada al análisis de los datos obtenidos, que dependerá de si se ha hecho un análisis cuantitativo o cualitativo.

Nos presentan un caso de estudio concreto, aplicando la ET a la televisión conectada, que usa dos canales para recibir información, uno para los contenidos televisivos, y otro para los datos de Internet. Se estudió la interfaz de los menús, puesto que cada fabricante y cadena tienen su propia propuesta. Primero se hizo un test con usuarios en el que se detectaron muchos problemas de usabilidad. Uno de ellos era que los usuarios no lograban acceder con facilidad a un servicio concreto. Para profundizar en el motivo se llevó a cabo un test con ET. Nos cuentan los resultados y las dificultades del mismo.

Capítulo 14: Accesibilidad de un recurso educativo: El caso de la Mapoteca, por Manuel Razzari

Presenta 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. La aplicación sería distribuida en los 3.5 millones de netbooks de los alumnos de escuelas secundarias públicas.

Nos habla de los desafíos del proyecto, del marco de trabajo y de la importancia de elegir los componentes adecuados tanto en el back-end como en front-end, así como del testeo de la aplicación, tanto con usuarios reales como con herramientas de evaluación.

También nos describe los problemas detectados: los que habría sido necesario prever con suficiente antelación (como el uso del color); los que se podrían haber evitado formando adecuadamente a las personas que harán la carga de contenidos; los que son difíciles de imaginar hasta que se hace un test con usuarios; o los que simplemente no tienen una solución al alcance de todos, por ejemplo la solución de la aplicación de mapas de Apple 6, que no usa mosaicos de imágenes sino datos vectoriales, así VoiceOver te leerá las calles mientras desplazas el dedo, leyendo por tanto el contenido de cada zona del mapa.

Capítulo 15: Elaboración de una Normativa de Usabilidad y Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires, Verónica Traynor

La autora nos introduce en el Diseño Centrado en el Usuario, en una forma de trabajo evolutiva y en espiral que 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. El eje pasa a ser el ser humano con sus necesidades de percepción, comprensión, operabilidad y aprendizaje. Todo gira en torno a la observación empírica y metodológica de personas aprendiendo e interactuando.

Nos habla de la observación como metodología: “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ó” y de los colores como parte del diálogo: “dejamos de hablar de pintar un cuadro y pasamos a construir un semáforo. Bello, pero fundamentalmente claro”.

Por último incluye la normativa de Usabilidad y Accesibilidad Web, publicada en 2010, que deben cumplir los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

Capítulo 16: Internacionalización Web, por Claudio Segovia

Nos introduce en la internacionalización de un sitio web (que no se refiere simplemente a crear sitios multilingües) y por qué deberíamos tenerla en cuenta. Detalla diferentes aspectos a los que deberemos prestar atención.

Capítulo 17: Prácticas participativas en el Diseño de Interacción: El caso del Design Museum, por Mariana Salgado

Nos cuenta el proyecto “La vida secreta de los objetos” llevado a cabo en el Design Museum de Helsinki.

El eje de este proyecto fue que el contenido generado por los visitantes (in situ, online o en los talleres organizados) como comentarios, relatos, opiniones, poemas, recuerdos o sentimientos basados en los objetos expuestos (y que podían estar en forma de texto, sonidos, música, imágenes, vídeos, etc.) estuvieran también en la galería, a disposición de los visitantes y promoviendo su participación. Un nuevo concepto de museo abierto y participativo, donde el diálogo continúe después de la visita.

De esta manera se enriquecería la experiencia de la visita al museo por medio de la inclusión. Esta información subjetiva permitiría disfrutar de las obras expuestas de muchas maneras, dando lugar a un museo abierto, y por tanto más accesible e inclusivo de las diferentes voces de nuestra sociedad.

Capítulo 18: Diseño y desarrollo de un editor de texto accesible bajo modalidad open-source, por Nahuel González

El objetivo del proyecto fue desarrollar un editor de texto accesible open-source. Partiendo de una lista de necesidades que debería atender el software, el artículo describe todas las características de la aplicación final, que a la publicación del libro estaba en la versión 2.0 y que es utilizado por usuarios con diferentes tipos de discapacidad.

Capítulo 19: Las métricas de accesibilidad desde una perspectiva práctica: eXaminator, por Carlos Benavidez

Carlos Benavidez, el creador de la conocida herramienta de evaluación automática de accesibilidad eXaminator explica por qué eXaminator se planteó como una herramienta que ofreciera una puntación numérica de la accesibilidad de la página. Explica además cómo se calcula la puntuación que otorga así como las ventajas y las limitaciones de la herramienta.

Usabilidad web: Problemas con el editor Gutenberg

Introducción

Una de las partes más importantes de WordPress, aparte de todas las personas que trabajamos en ello, es el editor, ya que es donde escribes tus contenidos y puedes aportar y ayudar ofreciendo todo el conocimiento que tienes, con la idea de hacer un WordPress mejor para todos.

Pero desde que está la posibilidad de utilizar este editor, veo que aún le queda mucho por mejorar y, que usarlo así de primeras, el cambio impresiona bastante. Pero bueno, aún así intentaré mostrar los principales problemas que nos podemos encontrar.

Principalmente, si pensamos en personas con dificultades físicas y/o con dificultades visuales que usen el editor, el esquema mental que tenido en su mente durante tanto tiempo, en un segundo se desbarata. Con lo cual tiene que volver a empezar y adaptarse a un cambio tan brusco cuesta, como a todos, pero a ellos más aún, y claro, teniendo tantas cosas para mejorar, la frustración es aún mayor.

Problemas de usabilidad con Gutenberg

La primera impresión al usar Gutenberg hace ya unos cuantos meses, y reconozco lo que he usado poco, era que al existir la posibilidad de mover bloques, cualquier persona que use el teclado y le dé por error se puede llegar a confundir, sobre todo si es una persona con visión nula. Y para una persona con problemas físicos, lo que ocurre es que se aumenta la carga motora innecesariamente, al tener que volver a colocar el bloque en el lugar que le corresponde. Bueno, en este caso, no tanto.

Pero cuando tienes que modificar estilos, sí. Porque tienes que pasar los estilos en cada uno de los bloques para seguir, a menos que uses las flechas de dirección o usar los comandos de teclado asignados para ello. Que a fin de cuentas es lo que se hace con el editor actual, y no nos encontramos con el problema de que al usar el TAB hay que pasar por los bloques y cada una de las opciones que tiene, lo cual es bastante cansado.

Me falla la barra de herramientas fija en la parte superior

Sí, así, tal y como lo lees. ¿Por qué? Porque si nos fijamos bien en las diferentes opciones del bloque, en la primera de ellas que es “Cambiar tipo de bloque”. Según lo que quieras poner ya sea una lista, un encabezado o una cita, la mejor solución es usar el comando correspondiente, porque es un pérdida de tiempo usar la tecla TAB si el usuario se equivoca al elegir qué quiere.

Yo pregunto: ¿Es necesario pasar con el teclado todas las opciones que se ven al desplegar esa opción? NO. Esto puede ser muy cansado para el usuario. Es cierto que beneficia a las personas que usan el ratón y es bastante rápido, pero nos olvidamos de los usuarios que no pueden usar un ratón y el problema principal es que se aumenta la carga motora sin necesidad. No sólo con eso, sino con todo. Porque se tiene que usar constantemente para estar editando y modificando las cosas. Y, también, todo esto puede marear a un usuario ciego.

Pero investigando por estos lares, me he dado cuenta de que existe la opción de “Fijar la barra de herramientas”. En el menú de puntos de la esquina superior derecha, en Ajustes. 
Opción Fijar barra de herramientas

Inserción de imágenes

He creado esta imagen para hacer ver uno de los problemas principales de usabilidad, al menos para mí y para muchos usuarios.

Problema de usabilidad de Gutenberg

Y aquí me encuentro con otro problema: que una vez que insertas una imagen, le das a Intro, y te obliga a poner otra y no hay forma de salir de ahí, hasta que no pasas varias veces con el TAB. Te vuelves loca. ¿Y si yo quiero poner un párrafo o un encabezado inmediatamente después? Con lo cual esto es un problema grave de usabilidad. Te interrumpe cada vez que quieres hacer algo.

En las imágenes es importante añadir el texto alternativo para que las personas ciegas puedan hacerse una idea de cual es la información de la imagen. Una leyenda es añadir algo más de información cuando se trata de una información adicional de la propia imagen, como explicar un gráfico o una imagen compleja, por ejemplo.

Atajos de teclado

Cuando se va a buscar el menú de los atajos de teclado y quieres desplazarte hacia abajo para seguir viendo el resto de comandos, no se puede, es dependiente de ratón.

Y tampoco se sabe cuáles son los atajos para poner los encabezados, algo muy importante para llevar a cabo el orden necesario en cuanto a accesibilidad web, y por lo tanto para ayudar a las personas ciegas a navegar y a entender el contenido.

Inserción de Enlaces

A la hora de insertar un enlace también da problemas. Cuando insertamos un enlace, se inserta bien, pero no te deja abrirlo en una ventana nueva. Una vez lo pones, no puedes comprobar que funciona porque no te deja. Para comprobar que funciona nos tenemos que ir a la opción “Ver entrada” y ya sale, cuando debería dejar hacerlo desde el propio enlace.

Inserción de  vídeos y Opción Incrustados

Hay un problema de usabilidad bastante grande con la inserción de vídeos. Directamente, es que no se puede. Esto, desde un primer momento crea bastante confusión a los usuarios, porque por ejemplo, al insertar un vídeo usando la opción de Vídeo se espera eso, poder insertar un vídeo sin problemas.

En la pestaña Incrustados, que aparece en el menú de bloques de la esquina superior izquierda, en cuanto a los vídeos, me parece un error poner todo lo que corresponde a las redes sociales, vídeos, así como las diferentes plataformas de música y fotos. Hay que intentar ser coherentes con lo que estamos haciendo. Si ya tenemos la opción de Vídeo, que en un primer momento sirve para eso, no podemos confundir al usuario con la palabra Incrustados.

Es más, como sugerencia, diría que hasta podría clasificar las opciones en función de su finalidad: Fotos, audio, vídeos y Redes Sociales. Sería mucho más cómodo a la hora de hacer las búsquedas de lo que se necesite en el momento.

Además de esto, es muy posible que algunas de las opciones no sean accesibles y seguramente tendrán que mejorar muchísimo en cuestión de accesibilidad. Con lo cual, ese menú puede suponer una pérdida de tiempo para los usuarios.

Menú de bloques

En cuanto al menú de bloques, que está dividido en diferentes pestañas que su vez despliegan un menú con diferentes opciones, me quedaba con: Más utilizados, Bloques comunes, Formatos y Elementos de diseño. Incluso, me plantearía redistribuir los Elementos y eliminaría alguno que otro porque lo único que hace es entorpecer y complicar las cosas. De los Formatos en las tablas no se puede tabular y es dependiente de ratón, con lo cual es un problema grave de usabilidad.

Los Widgets están siempre y cuando se pueda añadir una barra lateral y al no poderse hacer, o al menos yo no lo he descubierto, no tiene mucho sentido.

Y la opción de Reutilizable no entiendo para qué sirve. No le encuentro ningún sentido.

Conclusiones

Para mi gusto y por facilidad a la hora de trabajar con Gutenberg, es mucho más cómodo trabajar como lo he explicado anteriormente, con la barra de herramientas fija en la parte de arriba.

Y yo pregunto: ¿Por qué no se añade directamente la barra de herramientas fija a la parte superior? Una funcionalidad tan importante como esta no debe pasar desapercibida para nadie y mucho menos estar escondida en un menú. Se debería incluir esta opción siempre y así no frustra tanto a los usuarios.

Por cierto, lo último que he visto ha sido dentro del menú de cada uno de los bloques, las opciones “Insertar antes” e “Insertar después”, lo cual está bastante bien y mejora algo las cosas cuando estamos editando.

Y para finalizar, comento lo que toda la comunidad de WordPress lleva diciendo desde hace ya algunos meses:

Gutenber no está preparado para implementarse, necesita mejorar mucho en accesibilidad y en usabilidad para que se asiente como editor de textos en WordPress.

Accesibilidad web: ¿Cómo hacer tablas accesibles?

Introducción

Las tablas son un elemento más que forman parte de los sitios web.

Para las personas videntes pueden resultar cómodas y fáciles de interpretar, pero para las personas que usen lectores de pantallas puede ser un problema de accesibilidad.

¿Para qué sirven las tablas?

Las tablas sirven para mostrar información tabular. La información tabular permite consultar y analizar datos. Las tablas no se deben utilizar para la presentación de los contenidos en la web y, por tanto, no se debe usar para la maquetación de nuestro sitio web.

¿Cómo hacemos nuestras tablas accesibles?

En las WCAG 2.0 en el Criterio de Conformidad 1.3.1 Información y relaciones, hay una serie de técnicas que tenemos que tener en cuenta cuando tengamos que insertar en nuestros contenidos una tabla de datos:

Es importante describir la tabla

Debemos proporcionar información adicional sobre la tabla. Así describiremos el propósito de la misma y también se recomienda informar de su estructura. Disponemos de dos métodos complementarios:

  • el atributo summary dentro de la etiqueta <table>
  • la etiqueta <caption> dentro de la tabla.

 

Así se informará a los usuarios de productos de apoyo, como los lectores de pantalla. Por ejemplo, si es un listado de notas, lo debemos indicar. Si en la misma página hay múltiples listados de notas, deberemos incluir en la descripción, la asignatura para permitir al que navega saltar todas las tablas que no le interesen.

Es como poner un título y una leyenda a la tabla para que los usuarios sepan cuál es la información de la tabla, algo que me recuerda al tema de los formularios con el uso de fieldset y la etiqueta <legend>

<table summary"Notas del curso 2015-2016">
<caption>Notas finales del curso de accesibilidad</caption>
</table>
  • En las tablas de maquetación no debemos incluir el atributo summary.
  • El elemento caption y el atributo summary se pueden usar conjuntamente y no deben tener el mismo contenido.

Las tablas deben ser uniformes

Las tablas deben ser uniformes, evitando dividir, combinar o vincular celdas, y por lo tanto tienen que tener el mismo número de filas por columna y el mismo número de columnas por fila.

Para mayor facilidad de de uso y compresión de las tablas se recomienda hacer tablas simples en vez de tablas complejas.

Uso de encabezados

Las tablas deben tener definidos correctamente los encabezados con la etiqueta <th>, ya sea horizontalmente como verticalmente.

Cuando la tabla tiene una disposición de agrupación de columnas o filas, hace mucho más complicado su consulta. Disponemos del atributo scope para poder indicar que el campo actual es la cabecera de la columna o fila que hay a continuación.

En esta primera tabla la cabecera superior se corresponde con la ordenación posterior de los datos. Por tanto en cada <th> incluiremos el atributo scope=”col”.

tabla1

<thead>
<tr>
<th scope="col">Alumno</th>
<th scope="col">Nota</th>
</tr>
</thead>
<tbody>...</tbody>

Ahora vamos a trabajar con una segunda tabla, en la que tenemos una doble agrupación. En la fila superior dispondremos de <th> con el atributo scope=”col” como anteriormente, pero en la primera celda de cada fila tenemos un nuevo th en vez de td e indicaremos el atributo scope=”row”.

Hemos utilizado la técnica H63.

<thead>
<tr>
<th scope="col">Alumno</th>
<th scope="col">Sesión 1</th>
...
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Marta</th>
<td>8</td>
<td>9</td>
<td>9</td> ...
</tr>
</tbody>

tabla2

Tablas de datos complejas

Para explicar cómo hacer hacer accesible una tabla compleja nada mejor que explicarlo con un ejemplo. Imaginemos que tenemos una tabla en la que se muestra un horario escolar.

Tabla compleja: horario escolar

Es una tabla de datos compleja porque para una celda de datos tiene asociados dos encabezados.  “Matemáticas” tiene dos encabezados: uno de columna “lunes” y uno de fila de las “8:00 a las 9:00.”

Mediante los atributos id y headers los lectores de pantalla serán capaces de informar a los usuarios sobre cuáles son los encabezados correspondientes a la celda actual, independientemente de la complejidad de la tabla:

  • id, se utiliza en las celdas de encabezado <th> para proporcionar un identificador que ha de ser único.
  • headers, se usa en las celdas de datos <td>, con el valor de los id correspondientes.

 

<table>
<caption>Horario de Primero A</caption>
</<tr>
<td>
</<th id=“l”>Lunes</th>
<th id=“m”>Martes</th>
<th id=“x”>Miércoles</th>
</tr>
<tr>
<th id=“h_1”>8:00-9:00h</th>
<td headers=“h_1 l”>Matemáticas</td>
<td headers=“h_1 m”>Inglés</td>
<td headers=“h_1 x”>Música</td>
</tr>
<tr>
<th id=“h_2”>9:00-10:00h</th>
<td headers=“h_2 l”>Lengua</td>
<td headers=“h_2 m”>E.Física</td>
<td headers=“h_2 x”>Lengua</td>
</tr>
</table>

Si examinamos el ejemplo anterior:

  • Para el encabezado lunes se ha definido un id con el valor l.
  • Para el encabezado martes se ha definido un id con el valor m.
  • Para el encabezado miércoles se ha definido un id con el valor x.
  • Para el encabezado de 8:00 a 9:00, un id con el valor h_1.
  • Para el encabezado de 9:00 a 10:00, id con el valor h_2.

Una vez determinados los identificadores a los encabezados vamos a relacionarlos con las celdas de datos, de la siguiente manera:

  • En la celda de datos matemáticas, el valor de headers será el id del encabezado de fila de la franja horaria de 8:00 a 9:00, h_1 y el del id del encabezado columna lunes, l.

De esta forma, se ha definido el valor de todos los headers para todas las celdas de datos de la tabla.

Resumen

  • Una tabla de datos simple es aquella en la que, una celda de datos sólo se relaciona con un encabezado o de fila o de columna, es suficiente el uso de th para identificarlos. Por lo tanto es suficiente con implementar la técnica anteriormente vista H51.
  • Una tabla de datos compleja, es aquella en la que una celda de datos se relaciona con más de un encabezado de fila y/o columna, y por tanto hemos de establecer la asociación entre las celdas de datos con sus celdas de encabezado, utilizando la técnica H63 o la técnica H43.

Usabilidad web: “Pensar primero” – Daniel Mordecki

En esta entrada os voy a hablar del libro “Pensar primero” de Daniel Mordecki.

pensar primero

No es un libro que le vaya a enseñar nada nuevo a un profesional de la usabilidad, pero sí que debería ser leído por todas las personas involucradas en el desarrollo de software como una excelente y amena introducción al Diseño de Interacción.

Resumo a continuación el contenido del libro, que como digo gira en torno al Diseño de Interacción. Quizás algún programador se sienta ofendido, por ello comentaré primero que el autor afirma que:

Los programadores son gente inteligente, desarrollan una tarea extremadamente exigente, que les requiere muchas veces jornadas muy largas de trabajo bajo la presión de cronogramas y fechas límites. No se empecinan en mantener interfaces pobres porque sí, sino porque en el acierto o en el error están absolutamente convencidos que son las más adecuadas. Las pruebas de usabilidad son uno de los pocos caminos para revertir estas opiniones cuando están equivocadas y probablemente sean la de mejor relación costo/beneficio.

El autor, lo que realmente defiende, es que el programador debe poder dedicar el 100% de su tiempo a programar, que no deben recaer sobre él tareas que habitualmente realiza y para las cuales no está formado.

Los objetivos de la programación y del diseño de interacción van por caminos separados, por lo que no es viable que quién esté programando sea capaz de diseñar (no hablamos de diseño gráfico). No sólo se trata de tareas disjuntas en el tiempo, dado que el diseño antecede a la programación, sino que las metodologías, objetivos y requisitos son completamente distintos.

Describe situaciones habituales en las que los programadores suelen poner el foco en la tarea misma, seguros de que cuántas más tareas sea capaz de realizar una aplicación más feliz va a ser el usuario, incapaces de entender a los que están al otro lado de la pantalla. Achacan los problemas de una aplicación a que los usuarios no leen los manuales, a que los usuarios deberían formarse más, ser más cuidadosos o prestar más atención.

El objetivo del libro es mostrar que los problemas no residen en los usuarios sino en el propio software.

El diseño de la interacción está focalizado en las necesidades de los seres humanos, la programación está centrada en las necesidades de las computadoras. Unas y otras son bien distintas. Mientras que los humanos somos imprecisos, nos equivocamos, somos ambiguos y cambiamos de opinión y gusto, las computadoras son exactas, precisas, inequívocas, lógicas y repetitivas.

El diseñador de la interacción se preocupará de que el software hable el lenguaje de quien lo va a usar y no el lenguaje de la computadora.

El autor hace hincapié en que demasiado a menudo se empieza a programar antes de diseñar la aplicación, insistiendo en que el Diseño de la Interacción debe realizarse obligatoriamente antes de programar: “diseñar primero, programar después”, es la máxima del libro.

Si pensáramos en sentido inverso y aplicáramos los usos y costumbres informáticos a la ingeniería civil, entonces después de una reunión de dos o tres horas, donde le indican al gerente de proyecto que se va a construir un edificio con 30 apartamentos de dos dormitorios, cocina, living comedor y otras facilidades, de 75m2 cada uno, con 15 cocheras y de categoría media, éste se dirige al terreno y sentencia: “muchachos, vayan haciendo un pozo acá de más o menos 5 metros como la vez pasada, creo que con eso va a alcanzar, así adelantamos mientras yo hago los planos. Si después hay alguna diferencia vemos”.

Diseñar antes de programar es menos costoso, genera software de mejor calidad y usuarios más satisfechos, todo lo cual se traduce en una relación costo/beneficio excelente comparada con las metodologías que no lo hacen así:

    • diseñar reduce la cantidad de cambios a realizar sobre la marcha
    • los programadores podrán concentrarse exclusivamente en su tarea: programar
    • el software tendrá menos parches, con un modelo de datos más refinado, con menos opciones ocultas, desarrollado por programadores focalizados 100% en la tarea, sin duda será más compacto y eficiente, y por lo tanto tendrá menores requerimientos de equipamiento

El código es como el hormigón: una vez que está escrito, la estructura endurece y los cambios se volverán inviables […] Los cambios se plasmarán en parches al código que, a pesar de que desarrollan la función solicitada por el cliente, aumentarán la probabilidad de introducir errores y dificultarán enormemente en el futuro el mantenimiento de la aplicación […]

El proceso de Diseño de la Interacción aplicado antes de la programación genera pues usuarios más satisfechos, entendiendo que la satisfacción de un cliente no es el resultado abstracto de un producto “bueno”, sino la relación entre su percepción del producto que recibe y las expectativas que tenía antes de recibirlo.

Cinco son objetivos del Diseño de la Interacción:

    • Definir el producto final: sin esta definición es imposible saber cuándo está el producto acabado.
    • Acotar y minimizar los costos: el costo no se dispara porque fue mal estimado, sino porque se estimó el costo de una solución muy distinta a la que se terminará implementado.
    • Poner el foco en el usuario.
    • Sacar la presión que el diseño implica para el equipo de programación.
    • Hacer creíbles y “cumplibles” los cronogramas.

Las tres herramientas del Diseño de Interacción son:

    • Los personajes
    • Los objetivos
    • Los escenarios

Personajes

Daniel menciona las típicas reuniones que todos hemos vivido en que gerente, programador, diseñador, etc. defiende con vehemencia que el usuario preferirá tal o cual solución. En realidad todos ven a un usuario completamente distinto… extremadamente parecido a sí mismo, a un amigo o a un conocido, y discute encarnizadamente para imponer su visión de lo que es mejor.

La solución son los personajes, que tendrán nombre propio, y dicho nombre sustituirá al término “usuario” que hay que desterrar. Los personajes son personas ficticias (nunca reales) pero con una descripción lo suficientemente detallada para que pueda contestar a las preguntas de qué necesita el usuario, para lo cual deberán ser representativos de las personas que usan el programa.

Tendremos tantos personajes como roles distintos. Además de los personajes principales podrá haber personajes secundarios, que no son destinatarios finales pero también tienen su relevancia.

Hay que tener en cuenta que cuantos menos personajes mejor, puesto que cada personaje agrega una enorme cantidad de complejidad adicional: si tiene más de 5 o 6 personajes, entre principales y secundarios, lo más probable es que esté haciendo las cosas mal.

Objetivos

Realizamos tareas, anhelamos objetivos. Es necesario reposicionar el foco y pasar del software que hace cosas al software que ayuda a quien lo usa a conseguir objetivos.

Diseñar es encontrar dentro del espectro de objetivos de nuestros personajes el nivel justo de detalle que los comprenda y describa de forma útil para el desarrollo de la aplicación. […] Los objetivos de los usuarios potenciales deben jugar el rol de equilibrar y amalgamar las funcionalidades del software en un todo único.

Escenarios

La función de los escenarios es vincular los objetivos de los usuarios con las acciones concretas que desarrollan al utilizar la aplicación. Cada uno de los objetivos debe ser analizado minuciosamente para encontrar la lista completa de las tareas que hay que realizar para alcanzarlo.

Cada tarea debe ser puntuada del 1 al 5 en tres atributos para más adelante ordenarlas y ubicarlas:

    • Nivel de importancia: cuán importante es la tarea para alcanzar el objetivo.
    • Nivel de dificultad de implementación: en combinación con el nivel de importancia, el nivel de dificultad nos va ayudar a ponderar el esfuerzo de diseño y programación que hay que poner en una tarea determinada.
    • Frecuencia: la frecuencia con que repetimos una tarea tiene una importancia vital para el diseño.

Existen distintos tipos de escenarios:

    • Los de uso diario: son la quintaesencia del diseño de aplicaciones porque es allí donde los usuarios serán infinitamente felices o rabiosamente desdichados.
    • Los de uso periódico: son aquellos que responden a algún objetivo de algún personaje, pero no son utilizados a diario sino de forma esporádica.
    • Los de uso necesario: no existen para satisfacer necesidades de los usuarios, sino necesidades de la aplicación, como por ejemplo las pantallas de configuración, que deberían ser eliminadas. Programe para averiguar la información que necesita en vez de preguntarla.
    • Situaciones límite: desde el punto de vista de la programación son vitales, desde el punto de vista del usuario no, siempre y cuando este conserve el trabajo realizado hasta el momento.

Daniel parte de que se debe proponer una metodología práctica que permita enfrentarnos a problemas concretos, con presupuestos concretos y otras restricciones también concretas. Por eso propone dedicar, desde el punto de vista del Diseño de Interacción: el 75% del esfuerzo para los escenarios de uso diario, el 20% para los de uso periódico, 5% para los de uso necesario y nada para los de caso límite.

Si está diseñando un sitio Web, dibuje un recuadro para cada página que tendrá que diseñar, verifique que están todas, y pinte con un color distinto cada página según pertenezca a un escenario de uso diario, periódico, necesario o de caso límite. Verificará con sorpresa que va a dedicar el 70% del tiempo en el diseño del 10% de las páginas.

Una vez completado el proceso de definición de los personajes, descriptos sus objetivos, desglosados estos objetivos en tareas que se agrupan en escenarios, estamos en condiciones de especificar cómo se presentará el sitio ante los ojos de los usuarios.

Especificar la interfaz es dar el paso siguiente y determinar unívocamente, sin ambigüedad alguna, cómo será cada uno de los elementos de la interacción del sitio.

Para ello se propone dos técnicas: o desarrollar un esqueleto estático o un StoryBoard.

En ambos casos deben estar comentados al detalle, puesto que los programadores están acostumbrados a ir añadiendo/modificando/improvisando elementos del interfaz a medida que lo programan, adaptando la interacción a la implementación, y el resultado acaba alejándose del diseño original.

El esqueleto estático es una colección de páginas Web vinculadas entre sí que simulan el funcionamiento que tendrá el sitio una vez que esté terminado, definiendo a la vez, de forma unívoca, la interacción del sitio con sus visitantes. No es un prototipo, puesto que los prototipos no son completos y el esqueleto sí: tiene el 100% de las páginas. Además los prototipos no contemplan todos los detalles pero el Diseño de Interacción debe necesariamente contemplarlos todos.

Siempre es mejor contar con el diseñador gráfico (aunque siempre hay quien decide que si no llama al diseñador tendrá un contendiente menos para discutir) al especificar la interacción, tendríamos así la maqueta completa, que le pasaríamos a los programadores.

El StoryBoard consiste en crear las pantallas del sitio en imágenes, es más rápido de crear y modificar o de hacer distintas versiones, pero también resulta menos preciso, más lineal y es más difícil representar la interacción.

Daniel pasa entonces de la disciplina del Diseño de Interacción al de la Usabilidad:

El diseño de la interacción es la herramienta para construir un sitio o una aplicación desde cero. La usabilidad testeará lo que el diseño construyó primero. Y las distintas soluciones a los problemas son producto del diseño, la usabilidad encuentra los problemas pero no los resuelve, esta es tarea del diseño de la interacción.

El desafío de la Usabilidad es entender cómo ven el software quienes lo utilizan, qué piensan cuando lo usan, qué pistas le otorgan a los usuarios las respuestas que el software les da, entender por qué toman sus decisiones cuando se deciden por una u otra opción. La Usabilidad tiene como objetivo analizar el nivel de coincidencia que el modelo de representación de una aplicación o sitio Web expresa a través de su interfaz, con el modelo mental del usuario que está sentado frente a ella.

Para ello es necesario realizar test de usuarios. Daniel, de forma muy pragmática, indica que siempre es mejor un test improvisado, con cualquier compañero no involucrado en el proyecto, que no realizar ningún test. Aunque afirma que cualquier cosa no puede ser considerada una prueba de usabilidad decente, cree que una prueba mínima, con cualquiera que encontremos en el pasillo, posiblemente nos mostrará errores obvios que tuvimos delante de nuestras narices 18 meses sin verlos.

La usabilidad produce dos entregables:

    • Un análisis de la aplicación que encuentra las debilidades que alejan a los usuarios de sus objetivos cuando interactúan con ella.
    • Una sistematización de lo aprendido en las pruebas de usabilidad para encontrar patrones de problemas, guías de usabilidad basadas en el análisis empírico de las distintas situaciones.

Los test de usabilidad no prueban una tesis a partir de una hipótesis como en un teorema, sino que constituyen un insumo vital, que sumado a la experiencia, conocimientos y sentido común del diseñador, le permitirán perfeccionar el comportamiento interactivo de una aplicación.

Por último, me hace gracia cómo consuela a los diseñadores con una gran verdad:

Cuanto mejor es el diseño, menos se nota, y por lo tanto menos elogios recibirá. El buen diseño de la interacción produce aplicaciones y sitios Web sencillos, directos, de comprensión inmediata: no recibirá ningún elogio por ellos, salvo de algún experto que conozca lo difícil que es alcanzar un resultado de calidad. Eso sí, no intente explicar que el éxito se debe al excelente diseño, todos le contestarán al unísono: “¿esas paginitas con dos o tres gif son un ‘excelente diseño’?”.

Como dice Daniel, eso es posiblemente lo que le pasó al diseñador de Google.

Usabilidad web: Taxonomías y Navegación en WordPress

Introducción

El diseño de la navegación de un sitio, esencial para el éxito del mismo, comprende numerosos componentes, pero los podemos agrupar en dos conjuntos: la navegación estructural y la navegación semántica.

La navegación estructural sirve para representar los contenidos principales del sitio y facilitar su recorrido, mientras que la semántica permite establecer las interrelaciones basadas en la similitud entre las diferentes entradas del sitio.

Estructura del sitio web
Navegación estructural (vertical) y navegación semántica (horizontal)

La cuestión es que, para todos estos tipos de navegación, las taxonomías son de una importancia vital, no solo para mejorar la navegación y la experiencia de usuario, sino para optimizar el SEO y otros aspectos igualmente importantes en los sitios intensivos en contenidos, y muy especialmente, en los sitios web de medios de comunicación (cibermedios).

Las taxonomías en WordPress

En términos generales, una taxonomía es una clasificación. Suelen estar basadas en relaciones jerárquicas de clase y subclase.

El origen del término procede de las clasificaciones propias de la biología, donde un taxón es una de las clases en las que se subdividen los seres vivos.

Las taxonomías como formas de unión de entradas similares

En el caso concreto de WordPress, una taxonomía es una forma de unir las entradas que comparten alguna característica mediante el uso de términos. Dicho de otro modo, en WordPress una taxonomía es una lista de términos en la que cada uno de ellos está asociado a un conjunto de entradas.

Un ejemplo sencillo:

  • Término 1 > Entrada 1, Entrada 3, Entrada 4
  • Término 2 > Entrada 3, Entrada 4, Entrada 5
  • Término 3 > Entrada 2, Entrada 3, Entrada 5

 

El ejemplo anterior muestra esta idea con una taxonomía de tres términos en un sitio con cinco entradas. Vemos que el Término 1 (p.e. Accesibilidad web) une las entradas 1, 3 y 4; mientras que el Término 2 (p.e. Usabilidad) une la 3, 4 y 5, etc.

Pero estos términos hay que engobarlos en taxonomías. Las dos taxonomías que encontramos en una instalación estándar de WordPress son las siguientes:

  • Categorías
  • Etiquetas

Las taxonomías en WordPress pueden (o no) ser jerárquicas y esto todo lo más que se puede decir de su complejidad. Pero, hay que señalar que aquello que las hace valiosas, no es su complejidad, sino los múltiples usos que el sistema permite darle.

Las taxonomías como páginas web

Además, para WordPress, cada categoría y cada etiqueta es una página web. Esto significa, literalmente, que si tenemos 10 categorías del estilo: Accesibilidad web, Usabilidad, Diversidad Funcional, etc., y el sitio tiene el dominio, por ejemplo, accesibilidadyusabilidad.com, entonces tenemos 10 páginas como éstas que WordPress ha creado automáticamente:

  • accesibilidadyusabilidad.com/accesibilidadweb/
  • accesibilidadyusabilidad.com/usabilidad/
  • etc

Exactamente lo mismo nos sucede con las etiquetas. Por esa razón, cuando editamos una categoría o una etiqueta, estamos editando a la vez la página que contendrá todas las entradas o noticias categorizadas con esa categoría o etiqueta.

Por último, es importante señalar que WordPress incluye la posibilidad de desarrollar taxonomías personalizadas. En lo que sigue consideraremos únicamente el uso de las taxonomías tal como las provee WordPress en una instalación estándar.

Categorías

Las categorías pueden tener subcategorías, de modo que éstas permiten una organización (razonablemente) jerárquica de los temas de un sitio intensivo en contenidos.

En cambio, es importante notar que una subcategoría no puede formar parte de más de una categoría superior. Las polijerarquías, por tanto, no están permitidas.

La cuestión es que las categorías pueden utilizarse, si seguimos en el caso de un medio de comunicación, para representar las principales secciones temáticas del mismo (en un magazine de Cine y Televisión como Fotogramas, por ejemplo, serían Cartelera, Estrenos, Críticas, etc.)

Las categorías no deberían multiplicarse de forma descontrolada. Un número entre 5 y 10 de tales categorías y, si se considera necesario, un número de entre 2 y 5 subcategorías para cada una, podría formar una estructura bastante manejable y al mismo tiempo suficiente para acoger hasta 50 ítems temáticos distintos, cantidad más que suficiente.

A partir de aquí, el uso lógico de la taxonomía nos indica que cada entrada o cada noticia debe quedar asignada al menos a una categoría e, idealmente, solo a una categoría. Esto permitiría una estructura muy clara y enormemente fácil de manejar.

Pero otras consideraciones, en particular, tanto el SEO (queremos que la entrada sea muy visible) como la Experiencia de Usuario (queremos multiplicar los puntos de acceso), nos empujan en cambio en la dirección contraria: asignar tantas como sea posible.

Pero esto, a su vez, nos llevaría a una taxonomía que se volvería inútil a la larga, porque casi todas las entradas estaría asignada a casi todas las categorías. Así que la taxonomía no serviría para crear conjuntos (razonablemente) disjuntos, sino que, por el contrario, habría un solapamiento total.

Por lo tanto, el equilibrio entre la lógica intrínseca de las taxonomías y las exigencias del SEO nos lleva a proponer la norma de uso de este modo para el caso de un cibermedio que tuviera, por ejemplo, un total de 10 categorías principales:

Cada entrada o cada noticia debe quedar asignada al menos a una categoría y, en casos justificados, a una o dos categorías adicionales.

Esta asignación de categorías a las entradas o las noticias en WordPress constituye el primer paso obligado para lo que hemos llamado la polifuncionalidad de las taxonomías.

De hecho, es gracias a este primer paso que se puede considerar que las taxonomías son, en realidad, el corazón de un sitio bien diseñado con WordPress.

Etiquetas

Las etiquetas no son jerárquicas. Por tanto, no pueden tener subetiquetas. En cambio, pueden usarse mucho más liberalmente, ya que corresponden a la idea de las palabras clave con las que representar de modo sintético los temas de cada entrada o noticia individual.

La norma de uso de las etiquetas, interpretadas como palabras clave que describen de forma sintética todos y cada uno de los temas y entidades (personas, lugares, empresas, etc.) mencionados en una noticia se puede expresar así:

Cada entrada o cada noticia puede quedar representada por un mínimo de 2 y un máximo de 20 etiquetas

Las cifras anteriores marcan extremos. En el caso de las noticias, cualquier número más cerca de la franja entre las 4 y las 8 etiquetas, seguramente será una pauta más reconocible.

Cabe destacar que en el caso de las etiquetas los nombres propios (entidades), ya sea de personas, lugares, empresas, organismos, etc. se pueden considerar ejemplos válidos de etiquetas.

Como es fácil que el número de etiquetas (a diferencia de las categorías) se multiplique, es conveniente llevar algún tipo de control terminológico. En todo caso, conviene revisar regularmente el apartado de las etiquetas.De lo contrario, acabaremos usando diversas palabras para etiquetar los mismos conceptos, con lo que cual perderemos las ventajas de usar una taxonomía.

 El rol polifuncional de las taxonomías

Hemos hecho referencia anteriormente al hecho de que las taxonomías son en realidad el corazón de un sitio intensivo en contenidos bien diseñado.

Una de las mejores funciones, tanto de las categorías como de las etiquetas en el caso de WordPress (suponemos que otros CMS también permiten usos similares) es la de generar páginas bajos las cuales se reúnen las noticias asignadas a las mismas categorías (o etiquetas) y en las cuales, el nombre de la categoría forma parte de la URL.

Es decir, óbservese el múltiple papel de las taxonomías:

  • Caracterizar las entradas individuales, a modo de palabras clave destacadas para señalar de forma sintética sus contenidos principales.
  • Agrupar las mismas entradas o noticias bajo una misma etiqueta o categoría, lo que corresponde a una página que contiene un listado de las entradas asignadas a cada categoría.
  • Fundamentar la navegación semántica, ya que las etiquetas y categorías en una entrada son enlaces a la página que contiene la lista de todas las entradas asociadas a la misma.
  • Fundamentar el diseño de la navegación estructural, puesto que pueden aparecer en cualquier de los diferentes tipos de menús (principal, secundario, complementario, etc.) de esta clase de navegación.

 

Una vez más, la relativa sencillez de las taxonomías de WordPress no debe confundirnos. En un medio de comunicación o en general en un sitio intensivo en contenidos lo más lógico sería aplicar alguna clase de control terminológico, tanto de categorías como de etiquetas, pero sobre todo de estas últimas, a fin de usar siempre los mismos términos para representar los mismos conceptos.

Este control puede consistir en mantener una lista de los términos utilizados como etiquetas. En esta lista se debería poder distinguir entre términos sinónimos y términos preferentes; siendo éstos últimos los que se debería utilizar (en lugar de los demás sinónimos que deben quedar descartados).

En resumen:

  • Las categorías deberían reflejar las secciones principales (esto es la clase de contenidos principales) del sitio, y con más motivo si es un medio de comunicación. Deben ser pocas, por este mismo motivo, y mantenerse alrededor de la decena (siguiendo la norma del 7 más menos 2). Cada categoría puede tener subcategorías, en cuyo caso tampoco deberían ser muy numerosas (entre 2 y 5 por decir algo).
  • Las etiquetas deben reflejar el contenido concreto de cada entrada, por tanto, no hay un número óptimo máximo. Un sitio de comunicación puede necesitar centenares de etiquetas distintas. Por este motivo, necesitan a la vez mayor supervisión (control terminológico) para evitar que los mismos conceptos se representen con etiquetas distintas.

En este punto, es el momento de pasar a considerar la navegación estructural y sus diversos componentes.

Navegación estructural

Esta navegación tiene una triple misión: por un lado debe representar lo mejor posible la variedad de temas y subtemas que contiene un sitio web. En segundo lugar, es la navegación responsable de dar la máxima coherencia a todo el sitio.

Finalmente, debe asegurar un desplazamiento fácil por toda su estructura. Los tipos de menús componentes de la navegación estructural son, al menos (que nosotros sepamos, no hay una lista cerrada) los siguientes:

  • Principal
  • Secundario(s)
  • Al pie
  • Complementario(s)

Menú principal

El menú principal forma la parte principal de la llamada navegación constante, porque es la parte de la navegación que no cambia (con unas pocas excepciones) a lo largo de todo el sitio.

De manera óptima contiene un número limitado de componentes, siendo habitual referirse a este número con la expresión “7 más menos 2”, lo que implica que el menú principal puede tener entre 5 y 9 componentes.

En la mayor parte de los sitios, el menú principal estará ubicado en la parte superior de la página web. También en la parte superior si estamos pensando en el escritorio, o disponible para ser desplegado en el famoso “hamburguer menu”, si pensamos en la web móvil.

En el caso de un CMS como WordPress, aunque se pueden utilizar páginas en el mismo, la mejor opción consiste en utilizar las categorías de la taxonomía para construir este menú. En concreto, consiste en utilizar, típicamente, alrededor de 10 Categorías, que en un cibermedio se supone que deben coincidir con las principales secciones temáticas del mismo.

Eventualmente. en el menú principal podemos añadir una o dos páginas corporativas, por ejemplo, la página de contacto o la página de créditos, aunque estas últimas, en muchos cibermedios, se suelen incorporar en el menú al pie.

Menús secundarios

El término de menú secundario es polivalente e incluye, al menos estas posibilidades:

  • Menú local, es decir una parte de la navegación que es exclusiva de cada sección, por lo tanto,solamente se despliega en la sección determinada. Por ejemplo, una vez en la sección de Cultura de un medio de comunicación, se despliegan las opciones Cine, Literatura, Arte, etc.
  • Subelementos de un elemento principal de menú, situación generalmente identificada como una flecha o una convención similar. Para seguir con el mismo ejemplo, haciendo clic en el elemento Cultura del menú principal se desplegarían las opciones Cine, Literatura, Arte, etc.
  • Una línea secundaria de menú, como parte del menú constante (principal + secundario). La función aquí es añadir más opciones siempre disponibles, pero sin cargar el menú principal.

Las subcategorías pueden formar parte de cualquier nivel de menú: pueden estar en el menú principal o en cualquiera de las opciones que hemos señalado del menú secundario, así como en las que veremos despues en los menús complementarios.

Por último, en el caso de WordPress la idea de menús secundario puede corresponder al menú dedicado a las redes sociales. En algunos temas de WordPress entonces este menú queda visualmente asociado a cualquiera de los otros: el principal o el que situamos al pie, etc.

Menú al pie

Suele dedicarse a replicar toda o parte de la navegación principal, pero sobre todo suele utilizarse para añadir enlaces para acceder a información corporativa y legal.

Los temas de WordPress pueden permitir muchas opciones en este aspecto: añadir cualquir clase de enlaces relacionados, plugins, como el de búsqueda, acceso a las redes sociales del medio, un buscador, etc.

Menús complementarios

Solamente la imaginación (atemperada por un sentido elemental de la prudencia) limita las posibilidades de los menús complementarios. La razón es que los pluguins y los widgets que acompañan a los temas de WordPress proporcionan bastantes opciones donde elegir.

La idea esencial es que, proponer a los usuarios diversas formas de hacer lo mismo, o en el caso, de los sitios web, diversas formas de llegar al mismo contenido, siempre ha sido un consejo en el ámbito de la Usabilidad. Es por tanto, una buena práctica en el diseño de la navegación web.

Trasladar lo anterior al caso de un medio de comunicación (aka cibermedio) significa que podemos añadir formas de navegación como las siguientes:

  • Menús laterales (o al pie) basados en:
    • Categorías
    • Etiquetas
    • Páginas
    • Noticias más populares (más vistas)
    • Nubes de etiquetas
    • Últimas publicaciones
  • Archivo u orden cronológico basado en calendario
  • Sumarios en el interior de las entradas
  • Paginación al pie de entradas extensas
  • Ir a las entradas anteriores y posteriores a la que está en pantalla, etc.