Diseño del modelo de diálogo en HCI

Begoña Losada Pereda

Facultad de Informática-Universidad del País Vasco UPV/EHU

En el desarrollo de software interactivo con objetivos de usabilidad, un paso necesario es el diseño de la interacción mediante la formalización del modelo de diálogo. Este modelo representa el nivel sintáctico de la interacción Hombre-Máquina (H-M). Esto es, describe la estructura de las sentencias del diálogo H-M, cuyos elementos son las acciones del Usuario y las respuestas del Sistema.

Este modelo es útil para:

• Diferenciar los elementos de la interfaz y de la lógica de negocio. En un programa informático el diálogo con el usuario está mezclado con el resto de la actividad del programa: cálculos, opciones del Sistema, estructuras variables y complejas… Es importante diferenciar ambos aspectos, de esta forma podrán efectuarse cambios en la interfaz sin alterar la lógica de negocio y viceversa.
• Pensar el diálogo H-M antes de que el programa sea escrito. De esta forma, el analista podrá estudiar varias estructuras. Un buen modelo de diálogo guiará el diseño de la interfaz y posteriormente, la escritura del programa y su verificación.
• Generar prototipos tempranos. A partir del modelo del diálogo, pueden generarse prototipos tempranos para evaluar la usabilidad y robustez del software en una etapa muy temprana.
• Favorecer la comunicación entre los miembros del equipo de desarrollo. Si la notación es sencilla, directamente los modelos pueden servir de herramienta de muestra. En otros casos, su traslado a prototipos facilitará esta comunicación.

El proceso de la formalización del modelo de diálogo tiene como partida el proceso de Análisis de Tareas, que identifica las acciones del usuario y los procesos cognitivos necesarios para que un usuario complete una tarea o logre alcanzar un objetivo particular como, por ejemplo, imprimir un documento o reservar un vuelo.

Desde el área de la ingeniería del software y de la ingeniería de la interfaz se han propuesto varias técnicas y notaciones para formalizar el modelo de diálogo.

En este capítulo se presentan dos propuestas para la notación del diálogo, ampliamente utilizadas en HCI: los diagramas HTA+JSD y los diagramas STD+Harel. Se explican sus requisitos, beneficios e inconvenientes.

1. Introducción. Análisis del diálogo vs. Análisis de tareas.

Habitualmente el modelo de diálogo concierne al orden y estructura de las acciones del usuario junto con las respuestas del sistema, y suele agruparse con los modelos que configuran la interfaz de usuario. Además de incluir los aspectos indicados, debe contemplar también la semántica de la aplicación interactiva (los efectos que produce). Por ello, el modelo de diálogo es la conexión necesaria entre los modelos de desarrollo de la interfaz y los modelos de desarrollo de la implementación.

El modelo de diálogo se alimenta del análisis de los requisitos. Sin embargo, no sólo debe recoger los requisitos funcionales de la aplicación, sino que debe favorecer el desarrollo de otros modelos en etapas tempranas. El proceso de la formalización del modelo de diálogo tiene como partida el proceso de Análisis de Tareas.

Una premisa importante antes de abordar un diseño es conocer al usuario, establecer el modelo o modelos de usuario, y a partir de ahí:

• Identificar los objetivos que la aplicación debe soportar.
• Saber cómo realiza el usuario sus tareas y cómo diseñar futuras tareas acordes a ese usuario.

El Análisis de Tareas estudia al usuario e identifica en cada contexto cuáles son las acciones del usuario y su orden para conseguir un objetivo particular.

Una Tarea de usuario es una unidad significativa de trabajo, y puede ser de diferentes tamaños, desde objetivos abstractos como comprar un billete de avión, hasta interacciones mínimas como pulsar un clic.

Hay diferentes aproximaciones para la formalización del Análisis de Tareas. Entre ellas:

• Expresarlo mediante la descomposición de una tarea superior en otras más simples, como lo hace el modelo HTA (Hierarchical Task Analysis),
• Realizar un análisis basado en conocimiento (Cognitive Task Analysis). Comienza por listar todos los objetos y acciones relacionados con una Tarea, y construir taxonomías con ello.
• Realizar un análisis de relaciones entre entidades. Sigue la aproximación orientada a objetos que se focaliza en los actores y objetos, las relaciones entre ellos y las acciones que pueden realizar.

2. Modelo del Diálogo en HCI

Desde la ingeniería de software, y sobre todo desde el área de la interacción persona computador, se han propuesto varios tipos de modelos para la descripción del diálogo hombre-máquina (H-M).

En contraste con la mayoría de las conversaciones humanas, el diálogo H-M es más exigente, con una estructura más rígida y restringida que hace necesario la utilización de una notación formal para su modelado.

Los modelos de diálogo deben cumplir estas necesidades:

• Utilizar para su formalización notaciones flexibles y expresivas, que sean capaces de describir con claridad la interactividad y los comportamientos dinámicos.
• Deben ser comprensibles por personas con distinto nivel de conocimiento.
• Es conveniente que formen parte de los métodos de desarrollo, como un proceso sistemático para el diseño de la interfaz de usuario y su evaluación.
• Es interesante que soporten la reutilización de soluciones de diseño “buenas”.
• Es importante la disponibilidad de herramientas para desarrollar y explotar este modelo.

2.1           Notaciones para el modelado del diálogo

Hay varios tipos de notaciones formales usadas para la descripción del diálogo hombre-máquina. Una visión general permite agruparlas en dos grandes tipos:

• Notaciones esquemáticas: El modelo se representa mediante diagramas que permiten al diseñador observar de un vistazo la estructura del diálogo. Las más conocidas son los diagramas en forma de árbol, las redes de transiciones de estados, las redes de Petri, los diagramas de flujo tradicionales y algunos diagramas UML como los de estados y de actividad.
• Notaciones textuales: Utiliza descripciones textuales que intercalan los eventos sistema-usuario en la consecución de un objetivo. Se utilizan notaciones formales como las gramáticas, las reglas de producción o las álgebras de proceso, para las que existen herramientas de análisis léxico, sintáctico y semántico que facilitan su estudio. En otros casos, como los casos de uso de UML o los escenarios, se utilizan descripciones textuales informales, más ágiles y legibles, pero que pueden dar lugar a ambigüedades.

En este capítulo, nos centraremos en dos notaciones esquemáticas habituales en HCI para la formalización del modelo de diálogo de aplicaciones interactivas: los diagramas HTA+JSD y las redes STN+Harel.

2.1.1    Diagramas HTA + JSD

El modelo HTA (Hierarchical task analysis) permite expresar cómo realiza un usuario una tarea mediante una jerarquía de tareas y subtareas, acompañado de planes que describen en qué orden y bajo qué condiciones se realizan las subtareas. Cada caja representa la tarea de usuario a realizar mediante sus subtareas.

fig001. Esquema de un modelo HTA

JSD (Jackson structured design) incluye notación para la secuenciación (sin símbolo), la selección (círculo para describir un menú, por ejemplo) y la iteración de tareas (estrella).

El interrogante como indicación de tarea opcional es también una buena solución en el diseño de interfaces gráficas interactivas.

fig002. Notación JSD

Requisitos del Modelo HTA-JSD

• Las cajas representan únicamente acciones de usuario.
• Todas las cajas llevan su numeración relativa a su posición en el árbol.
• En cada caja se indica gráficamente el número de veces que se realiza esa tarea:

fig003. Tipos de tareas HTA-JSD

• Las ramas verticales que parten de cada tarea vienen acompañadas de su plan de actuación, que incluye:
  • Las respuestas del Sistema en la interfaz.
  • El orden de ejecución de las subtareas inmediatamente inferiores.
  • Si la tarea es repetitiva, el número de veces mínimo y máximo que se ejecutará. Por defecto, se considerará mínimo=0.
• Representa un diseño lo más “esencial” posible. Esto es, independiente de la plataforma y de los elementos concretos de la interfaz. Este modelo se centra en las tareas a realizar y no en su presentación concreta. Esto permite realizar varias presentaciones sobre el mismo modelo.

Beneficios

Es muy adecuado para analizar la organización de nuestro diseño, como en este ejemplo en el que se observan tres módulos para la realización de la tarea “Inscripción en un congreso”.

Fig004. Ejemplo de un modelo HTA-JSD para la tarea “Inscripción en un congreso”

Para estar completo, este modelo debe acompañarse de los planes de actuación para cada rama vertical:

Plan 0: Si hay plazas libres, se realizará 1, 2, 3 en orden secuencial.

Si no hay plazas, el Sistema avisa (Aviso 1) y va al home.

Plan 1: El usuario elige entre 1.1 y 1.2, y el Sistema muestra el importe correspondiente.

Plan 2: Realizar 2.1, 2.2, 2.3, y después 2.4.

Si faltan datos, el Sistema señala los campos y avisa (Aviso 2). Vuelve a 2 sin borrar datos. Si no va a la siguiente tarea.

Plan 3: Realizar 3.1, 3.2 y después .3.3 para confirmar pago.

Si núm. Tarjeta no válido, avisa (Aviso 3) y va a 3 sin borrar datos.

Si válido, guarda la inscripción y avisa de ello (Aviso 4).

Basado en este modelo podemos organizar la interfaz, en este caso se presenta en forma de “Pasos”.

I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

fig005. Ejemplo de interfaz basada en el modelo “Inscripción en un congreso”

Podríamos pensar en otro modelo HTA-JSD para este mismo propósito, que proporcione una agrupación diferente:

fig006. Ejemplo 2 de un modelo HTA-JSD para la tarea “Inscripción en un congreso”

En este caso, el diseño sería muy diferente, como por ejemplo el que muestra la siguiente figura:

fig007. Ejemplo 2 de interfaz basada en el modelo “Inscripción en un congreso”

Otro beneficio del modelo HTA-JSD es su sencillez, que permite debatir sobre los problemas de un diseño o sus posibles mejoras. Por ejemplo: ¿Cómo indicar que pueden inscribirse muchos estudiantes, con un mismo código, validar conjuntamente, y después pagar?

Adaptaríamos el modelo para hacerlo posible, como muestra el esquema siguiente:

I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

fig008. Ejemplo 3 de un modelo HTA-JSD para la tarea “Inscripción en un congreso”

Inconvenientes

Este modelo describe las acciones de usuario para realizar un objetivo. Sin embargo, para llegar a ser un modelo de diálogo completo, las acciones intercaladas del Sistema deben expresarse en un plan de actuación escrito de manera textual e informal, lo que puede ser ambiguo o difícil de interpretar.

2.1.2    Las redes de transiciones de estados (STN) + Harel

En las redes de transiciones de estados cada nodo denota un “estado” en el que el sistema puede estar y los estados están conectados mediante flechas que expresan las transiciones. En los STN (State Transition Networks) utilizados para la descripción del diálogo, las transiciones están etiquetadas con las acciones del usuario que provocan esa transición (U:) y las respuestas que da el sistema (S:).

En fig009 se muestra el modelo STN de una herramienta de dibujo. Describe el diálogo necesario para dibujar un círculo, una línea o un polígono. En este caso, las transiciones se realizan únicamente mediante acciones de usuario.

fig009. Modelo STN para una herramienta de dibujo

En un modelo STN, es posible agrupar subsistemas en cuadrados para expresar que serán desarrollados de forma modular y de esta manera simplificar el modelo. Esto es conveniente en modelos muy largos o cuando se quiera reutilizar un submodelo en otro.

En fig010 vemos un modelo de diálogo con un diagrama de transición de estados para una aplicación de Creación-Modificación-Borrado de registros.

fig010. Modelo STN para una herramienta de gestión de registros

Los diagramas STN son buenos para representar partes del diálogo secuencial, elección e iterativo, sin embargo, fallan en la descripción de las partes concurrentes.

Veamos un ejemplo de diálogo concurrente. En fig011 observamos las diferentes opciones de un programa de escritura de texto. En concreto, las opciones sobre el estilo del texto (negrita, itálica o cursiva, subrayado, etc) no son excluyentes; pueden ser activadas en cualquier momento y simultáneamente. Este diálogo no puede expresarse fácilmente en un modelo STN básico.

fig011. Muestra parcial de un procesador de textos

¿Cómo describiríamos este diálogo con un modelo STN? Con tres posibilidades Negrita-Itálica-Subrayado, tenemos 8 estados, 24 transiciones y 3 eventos, como observamos en fig012.

fig012. Modelo STN con 3 eventos concurrentes

Cuantas más combinaciones concurrentes más difícil de representar. Su lectura también sería cada vez más compleja.

Los diagramas STN también fallan en la descripción a los accesos persistentes que pueden activarse desde cualquier sitio. Por ejemplo: ESC, HELP son accesos globales, persistentes en toda la interfaz, con diferentes significados.

• ESC: Activo en cualquier punto, cancela lo que está en curso y vuelve al inicio. Lo vemos en la figura siguiente, que representa el modelo de diálogo STN de una herramienta múltiple, con accesos ESC o anulación desde cualquier punto. Habría que indicar esa posibilidad en cualquier estado (o subsistema) como en el caso mostrado en fig013.

fig013. Modelo STN con transición ESC

• HELP: Desde cualquier estado, se dirige al subsistema Help, y después vuelve al mismo punto desde el que fue invocado. En fig014, añadimos esta posibilidad a la herramienta de dibujo mostrada en fig09.

fig014. Modelo STN con transición HELP

Diagramas de estados de Harel

Son una ampliación de los STN que solucionan de una forma sencilla los problemas de diseño de concurrencia y los accesos a eventos persistentes con transiciones AND. Las transiciones AND son arcos que salen de un estado y llegan a 2 o más estados efectuando una única transición. Un gran círculo engloba los estados que pueden actuar de modo concurrente.

Por ejemplo, la realización de una reserva en un hotel con la persistencia de un evento Help, puede representarse como vemos en fig015. En cualquier momento de la reserva o del pago, se puede acceder a Help

fig015. Modelo STN con transición HELP

Del mismo modo, es posible expresar la lógica ESC. En fig016, el modelo describe una reserva de hotel con la posibilidad de cancelación desde cualquier punto. Si se confirma la cancelación, interrumpe el proceso de reserva y vuelve al estado inicial.

Fig016. Modelo STN con transición Cancelar

Además, con el objetivo de facilitar la descripción de la lógica del diseño de interfaces gráfica interactivas vemos en fig017 tres variantes de Harel:

Fig017. Tres variantes de Harel

• AND: Cuando se efectúan todos los eventos en cualquier orden. Es el típico ejemplo de un formulario que exige rellenar todos sus datos en cualquier orden.

Fig018. Eventos AND para el pago con tarjeta

• OR: Cuando se efectúan varios eventos en cualquier orden (al menos 1). Un ejemplo típico es cuando hay que completar un formulario al que le faltan uno o más datos por rellenar.

fig019. Eventos OR para efectuar uno o más eventos

• NADA: Cuando se efectúan todos, varios o ningún evento en cualquier orden. Por ejemplo, cuando tenemos diferentes campos opcionales. En fig020 se observa como representaríamos un formato con las posibilidades múltiples: Negrita / Itálica / Subrayado.

fig020. Modelo STN-Nada para el ejemplo “Formato de letra”

Requisitos del modelo STN-Harel

• Cada estado representa un cambio de estado en la interfaz de usuario provocado por un evento del Sistema, del Usuario o de ambos.
• En algunos casos, para simplificar el modelo, si no hay cambio de estado el arco no estará etiquetado. En fig021, observamos el estado “Introducidos Datos persona” al que se llega sin ningún evento y que es el mismo estado que “Introducido Dir. Correo” y que se utiliza para representar el estado tras la introducción de todos los datos.
• El texto de los círculos se indica con un sustantivo como “Pago” o “Reserva apartamento” especialmente en el estado inicial que refleja el punto de inicio del objetivo de usuario a realizar. También, como ayuda para su localización, es muy acertada en español la utilización del verbo en participio, por ej. “Introducido apellido”, que indica el evento que ha llevado a ese estado.

• El flujo puede ser:

• Secuencial: Un camino determinado por eventos obligatorios.

fig021. Modelo STN secuencial

• Elección única: El flujo sigue obligatoriamente una alternativa. Por ejemplo, en un menú, o respuestas diferentes del Sistema.

fig022. Modelo STN de elección única”

• Elección en cualquier orden: Se puede ir por uno de los caminos, pero también hacer varios, todos o ninguno, en función de una lógica AND, OR o nada.

fig023. Tipos de modelo STN de elección múltiple”

Beneficios

• Los diagramas STN-Harel permiten representar de una manera intuitiva partes del diálogo secuencial, elección, iterativo y concurrente. Esto los hace adecuados para el diseño de aplicaciones iterativas.
• El esquema de estados-eventos de usuario/Sistema permite trasladar fácilmente la propuesta a un prototipo gráfico para ser evaluado.

Inconvenientes

• El modelo puede ser largo y hacerse menos legible, por lo que es conveniente modularizarlo en subsistemas como en la figura fig010.

3. Referencias

Dix, A., Janet E. Finlay, J.E., Abowd, G.D. y Beale, R. (2003). Human-Computer Interaction (3rd Edition). Inc., Upper Saddle River, NJ, USA: Prentice-Hall.

Thimbleby, H. (2007). Press On: Principles of interaction programming. Cambridge: MIT Press.

Harel, D. (1987).  Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274. doi: 10.1016/0167-6423(87)90035-9

Task analysis. (s.f.). Recuperado de https://www.usability.gov/how-to-and-tools/methods/task-analysis.html

Usability Body of Knowledge, Task Analysis. (s.f.). Recuperado de http://www.usabilitybok.org/task-analysis

Hornsby, P. Hierarchical Task Analysis. Innovating UX Practice. (2010) Recuperado de:

https://www.uxmatters.com/mt/archives/2010/02/hierarchical-task-analysis.php