formalización del modelo de diálogo en...

UN AÑO DE WEBINARS SOBRE HCI EN ESPAÑOL

Formalización del modelo de diálogo en HCI

Begoña Losada [email protected] de investigación ADIAN

Facultad de Informática de San SebastiánUniversidad del País Vasco UPV/EHU

30 de mayo de 2019

mailto:[email protected]

Modelo de DIÁLOGO

• El modelo de diálogo es el nivel sintáctico de la interacción hombre-máquina.

• El modelo de diálogo concierne a la estructura de las acciones del Usuario junto con las respuestas del Sistema.

• El modelo de diálogo sirve para:– Diferenciar los elementos de la interfaz y de la lógica de negocio

– Formalizar el diálogo H-M antes de que el programa sea escrito.

– Generar prototipos tempranos

– Favorecer la comunicación entre los miembros de un equipo

Formalización del modelo de diálogo en HCI, por Begoña Losada 2

Modelo de DIÁLOGOAnálisis de tareas

• El Modelo de diálogo comienza por un proceso previo de Análisis de Tareas.

• El análisis de Tareas identifica las acciones y los procesos cognitivos necesarios para que un usuario complete una tarea o logre un objetivo particular.

• Tarea: Unidad significativa de trabajo en la actividad de una personasobre una aplicación. Las tareas más pequeña son acciones que implican la interacción mínima.

• Una de las premisas de cualquier aproximación con la que abordemos un diseño es la de conocer al usuario y a partir de ahí:

– Identificar los objetivos que tu web o app debe soportar.

– Saber cómo realiza sus tareas y cómo diseñar futuras tareas.



• Propósitos del análisis de tareas:– Identificar las tareas que los usuarios hacen o harían para lograr un

objetivo.

– Identificar los factores de entorno, culturales, personales o sociales que influyen en el modo de realizar las tareas.

• Beneficios del análisis de tareas:– Proporciona un diseño de la aplicación consistente con el modelo

conceptual del usuario.

– Facilita el análisis y evaluación de usabilidad, de forma temprana.



Diferentes aproximaciones para su formalización:

• Descomposición de tareas– Ver el modo en el cual una tarea se puede descomponer en otras más

simples.

• Análisis basado en conocimiento (Cognitive Task analysis)– Dirigido a comprender las tareas que requieren mucha actividad

cognitiva del usuario, como la toma de decisiones, la resolución de problemas, la memoria, la atención y el juicio.

• Análisis de relaciones entre entidades– Aproximación orientada a objetos que enfatiza los actores y objetos, las

relaciones entre los mismos y las acciones que pueden realizar


Modelo de DIÁLOGO

• Desde el punto de vista de ingeniería, estos modelos deben cumplir lo siguiente:

– Notaciones flexibles y expresivas, capaces de describir con claridad la interactividad y los comportamientos dinámicos.

– Comprensibles por personas con distintos conocimientos.

– Incluídos en los métodos de desarrollo como un proceso sistemático para el diseño de la interfaz de usuario y su evaluación.

– Soporte para la reutilización de soluciones de diseño “buenas”.

– Disponibilidad de herramientas.


Notaciones para el diálogo

• Dos tipos de notaciones:

– Esquemática: Mediante diagramas que describen la estructura del diálogo.

– Textual: Mediante descripciones textuales que detallan los eventos sistema-usuario




Notación esquemática (diagramas):• Permiten visualizar de un vistazo la estructura del diálogo.

– Redes de transición de estados (STN)

Inicio

Sel.Círculo

Sel.Línea

MenúDibujo

U:Sel. Menú dibujo

Situado

CírculoHecho

Situado

LíneaHecha

U:Click posición U:Mantener y arrastrar

U:Click posición

Sel.Polígono Situado

LíneaHecha

U:Click posición

U:Click posición

PolígonoHecho

U:Doble Click

U:Mantener y arrastrar

U:Mantener y arrastrar

Notaciones para el diálogoDiagramas de transición


Registro

Password

Menú Principal

Mensaje Error

HOME

CrearRegistro

CambiarRegistro

BorrarRegistro

U: Password

U: Aceptar

S: Password correcta

S: Password incorrecta

U: Crear

U: Cambiar

U: Borrar

U: SalirU: Volver

Notaciones para el diálogoDiagramas de transición de estados


• Los diagramas STN pueden ser muy buenos para representar partes del diálogo secuencial, elección e iterativo.

• Fallan en la descripción de las partes concurrentes.



• STN fallan en la descripción de las partes concurrentes.• Transición individual Negrita – No negrita

• Transición combinada Negrita e Itálica

NegritaNo

negrita

Clic Negrita

Nada Negrita

ItálicaNegrita + Itálica

Clic Negrita

Clic Itálica

Clic Negrita

Clic Itálica



• Transición combinada Negrita-Itálica-Subrayado

• ¿Más combinaciones?

Nada Negrita

ItálicaNegrita + Itálica

Subra-yado

Negrita + Sub-rayado

Subra-yado + Itálica

Negrita + Itálica +

Subrayado

Clic Itálica

Clic Negrita

Clic NegritaClic Itálica

Clic Negrita

Clic Negrita

Clic Itálica

Clic Itálica

Notaciones para el diálogoDiagramas de transición de estados• También fallan en la descripción a los accesos persistentes:

• Pueden activarse desde cualquier sitio.

• Por ejemplo: ESC, HELP con diferentes significados• ESC: En cualquier punto, cancela lo que está en curso y vuelve al inicio.

Menú Principal

Submenú dibujo

Submenú texto

Submenú imagen

Seleccionar ‘dibujo’

Seleccionar ‘texto’

Seleccionar ‘imagen’

ESC

ESC

ESC

Terminar normal

Terminar normal

Terminar normal

Formalización del modelo de diálogo en HCI, por Begoña Losada



• También fallan en la descripción a los accesos persistentes: • Pueden activarse desde cualquier sitio.

• Por ejemplo: ESC, HELP con diferentes significados

• HELP: En cualquier punto, se dirige al subsistema Help, y después vuelve al mismo punto desde el que fue invocado

Sel.Círculo

CírculoHecho

SituadoClic posición Mantener y arrastrar

Subsistema HELP Subsistema HELP

Notaciones para el diálogoDiagramas de Harel


• Los diagramas de Harel pueden ser vistos como un tipo de STN.• Son una solución a los problemas de concurrencia y eventos persistentes.

AND OR

Se efectúan todos los eventos en cualquier orden

Se efectúan todos, varios o ningún evento en cualquier orden.

Se efectúan varioseventos en cualquier orden (al menos 1)



• Los diagramas de Harel pueden ser vistos como un tipo de STN.• Son una solución a los problemas de concurrencia.

Formato

Negrita Itálica Subrayado

U: Negrita U: Itálica U: Subrayado



• Son una solución a los problemas de eventos persistentes.

ElegidoHotel

U: Reserva U: Help

Datos

Pago

U: Pago

HELP



• Son una solución a los problemas de eventos persistentes.

ElegidoHotel

Marcado Cancelar

U: Reserva U: Cancelar

Datos

PagoAviso de

Seguridad

S: ConfirmaciónU: Pago

U: Confirma Cancelación


Notaciones para el diálogo: STN + Harelinscripción

IntroducidoEstudiante

S: Hay plazasU: Estudiante

U: cód.descuento

IntroducidoProfesor

IntroducidoCód.Descuento

S: No hay plazasAVISO: No hay plazas

U: AceptarHOME

S: Hay plazasU: Profesor

ElegidoTipo

IntroducidoNombre

IntroducidoApellido

IntroducidoDir. Correo

U: nombre

U: apellido

U: Dir.Correo

IntroducidoValidar

U: Validar

S:Faltan datos por rellenarS:No faltan datos por rellenar

Efectuar PagoS: Pago correcto

AVISO: Faltan datos

IntroducidoNombre

IntroducidoApellido

IntroducidoDir. Correo

U: nombre

U: apellido

U: Dir.Correo

OR

IntroducidosDatos persona

AVISO: Fin correctoU: Aceptar

HOME

Notaciones para el diálogoRedes de Petri


Negrita On

Negrita Off

Itálica On

Itálica Off

Usuario pulsa

Negrita

Usuario pulsa

Negrita

Usuario pulsa

itálica

Usuario pulsa

itálica

T1 T2 T3 T4

• Son una solución a los problemas de concurrencia.

Notaciones para el diálogoHTA + Jackson structured design (JSD)


• Se utiliza en técnicas de Análisis de Tareas.

• Se basa en un análisis jerárquico de tareas (HTA)

• La notación HTA - Hierarchical Task Model es una representación en forma de árbol.

• Cada caja representa la tarea de usuario a realizar mediante sus subtareas.

• Representa un diseño lo más “esencial” posible.



Secuencia de Tareas Selección de Tareas

*

Iteración de TareasTarea Unitaria

• JSD incluye notación para la secuenciación, selección e iteración de tareas.



• El árbol jerárquico expresa la organización del sitio:

Inscripción2

Elección tipo2.1

Insertar datos de una persona

2.2

Estudiante2.1.1

Profesor

2.1.2

Efectuar pago2.3

Núm.tarjeta

2.3.1

Código cvc

2.3.2

nombre

2.2.1apellido

2.2.2

Dir.correo

2.2.3

validar

2.2.4

Insertar cód descuento

validar

2.3.3

2,1,1,1 ?

Plan 2: Si hay plazas libres, se realizará 2.1, 2.2, 2.3 en orden secuencialsino el Sistema avisa y va al home.

Plan 2.1: El usuario elige entre 2.1.1 y 2.2.2, y el Sistema muestra el importe correspondientePlan 2.2: Realizar 2.2.1, 2.2.2, 2.2.3 en cualquier orden, y después 2.2.4

Si faltan datos, el Sistema señala los campos y avisa sin borrar datos, después hace 2.2.4Sino va a la siguiente tarea.

Plan 2.3: Realizar 2.3.1, 2.3.2 y después 2.3.3 para confirmar pagoSi núm.tarjeta no válido, avisa y va a 2.3 sin borrar datos.

sino recoge la inscripción y avisa de ello.



• Describe la organización de nuestro diseño:



• Sirve para discutir sobre el mejor diseño (general o para diferentes tipos de usuarios):

¿Es posible indicar que pueden inscribirse muchos estudiantes, validar conjuntamente, y después pagar?

Notaciones para el diálogoCTT: ConcurTaskTrees


• Estructura jerárquica• Incluye notación para la concurrencia• Se focaliza en las actividades que el usuario quiere realizar.• Posee un conjunto numeroso de operadores para describir relaciones

temporales entre tareas (Activación, Desactivación, Concurrencia, Interrupción, opcionalidad).

• Las tareas tienen categorías: De usuario, de aplicación, de interacción, abstracta.

• Los objetos que deben ser manipulados también tienen representación: objetos de la interfaz de usuario y objetos del dominio.

Notaciones para el diálogoCTT: ConcurTaskTrees


Modelo de DIÁLOGOResumen Notaciones esquemáticas

Notaciones esquemáticas, según los siguientes criterios:

1. La posibilidad de describir diálogos concurrentes

2. La descripción de accesos persistentes

3. La legibilidad de la notación

4. Las posibilidades de agrupación semántica de

los subdiálogos

5. La descripción del orden y semántica de los eventos

6. La independencia de la notación de una filosofía de programación

7. Las posibilidades de utilización directa de la

notación como comunicación entre todos los

implicados en el desarrollo del producto


1 2 3 4 5 6 7

STN X X X

STN de Harel X P X P X X

Grafos X X X X X

Petri Nets X X X X

Flujos

tradicionalesX X

Árboles X X X X

Diagramas

UMLP P X X


Notaciones textuales: Dos grupos:

– Estructura formal: Gramáticas, reglas de producción, álgebras de proceso.

Menor legibilidad, no son una buena herramienta para la comunicación.

– Estructura informal: casos de uso y escenarios.

Son buenas herramientas de comunicación. Pueden contener descripciones ambiguas.


Notaciones para el diálogoNotaciones textuales

Notaciones textuales:

Gramáticas:

• Expresiones regulares– Limitado a descripciones de bajo nivel.

– No permiten expresar diálogos concurrentes ni comandos persistentes.

– Ej. Dibujar polígono: • Sel_Polígono Clic_posición (Mantener_ y_Arrastrar Clic_posición)* Doble_Clic

• Tipo BNF (Backus-Naur Form)– Las definiciones recursivas permiten expresar iteración en el diálogo.

– BNF no permite expresar diálogos concurrentes ni comandos persistentes.

– Ej.

Polígono ::= Sel_Polígono Clic_posición Resto_Polígono Doble_Clic

Resto_Polígono ::= Mantener_y_Arrastrar Clic_Posición Resto_Polígono

|vacío




• Reglas de Producción: – Los elementos (tokens) son: los eventos del usuario y las respuestas

del Sistema.

– Las Reglas tienen la forma condición acción

Sel_línea comienza_línea <resalta línea>

Simple_clic comienza_linea resto < marca borrar on>

Simple_clic resto resto <dibuja línea>

Doble_clic resto <dibuja línea> <marca borrar off>




• Algebras de eventos: – Permiten describir diálogos concurrentes

– CSP (Communicating Sequential Processes) incluye símbolos de operadores:• secuencial ‘;’

• elección [ ]

• operador|| para expresar composición paralela:

Menú_Dibujo = (sel-círculo? Hacer_círculo

[] sel-línea? Hacer_línea )

Hacer_círculo = clic? posición clic?

dibujar-círculo skip

…


Otras notaciones para el diálogo

• UIDE (User Interface Design Environment): Los modelos se describen en términos de objetos asociados con pre-condiciones y post-condiciones.

• GOMS (Goals, Operators, Methods, Selection Rules): Se describen las secuencias de acciones necesarias para alcanzar un goal. Estas acciones se agrupan en diferentes methods que pueden tener una selection rule para indicar cuando es adecuada su ejecución.

• UAN (User Action Notation): Notación textual en la que es posible describir relaciones temporales entre tareas asíncronas y, finalmente, se describen las tareas básicas mediante tablas indicando: Acciones de Usuario, feedback del Sistema, y modificaciones en el estado de la interfaz.

• GTA (GroupwareTask Analysis): Se centra en la recogida de requisitos necesarios para el diseño de la interfaz de usuario, utilizando métodos etnográficos.

• Otras: OAET, CADET, LINK Analysis, Timeline analysis, Tabular Task Analysis.


Otras notaciones para el diálogo

• UML (Unified Modeling Language): Es la aproximación al modelado más exitosa en ingeniería de software.

• UML propone como modelo de diálogo los diagramas de actividades e incluso los casos de uso.

Inconvenientes:• Los aspectos de usabilidad no son únicamente importantes al final del

desarrollo, también lo son durante el diseño. UML no lo contempla.

• Extraer modelos de tareas de los modelos para O.O, suele ser problemático porque las aproximaciones orientadas a objetos son efectivas para modelar aspectos internos del sistema pero es menos adecuado para capturar las actividades del usuario y sus interacciones con el sistema.

• Los casos de uso podrían ser útiles para identificar tareas de usuario, pero su notación es textual y ambigua.


Bibliografía• https://www.usability.gov/how-to-and-tools/methods/task-analysis.html• http://www.usabilitybok.org/task-analysis• https://www.uxmatters.com/mt/archives/2010/02/hierarchical-task-analysis.php• Alan Dix, Janet E. Finlay, Gregory D. Abowd, and Russell Beale. 2003. Human-Computer Interaction (3rd Edition).

Prentice-Hall, Inc., Upper Saddle River, NJ, USA. • David Harel, Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–

274, June 1987.• Esparza, Javier & Nielsen, Mogens. (1994). Decidability Issues for Petri Nets - a survey. Elektronische

Informationsverarbeitung und Kybernetik. 30. 143-160. • G. Mori, F. Paterno and C. Santoro, "CTTE: support for developing and analyzing task models for interactive system

design," in IEEE Transactions on Software Engineering, vol. 28, no. 8, pp. 797-813, Aug. 2002.doi: 10.1109/TSE.2002.1027801 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1027801&isnumber=22077

• J. Foley and N. Sukaviriya, “History, Results, and Bibliography of the User Interface Design Environment (UIDE), an Early Model-Based System for User Interface Design and Development”, Interactive Systems: Design, Specification, Verification,F. Paterno ed., pp. 3-14, 1994.

• L. Baumeister, B. John, and M. Byrne, “A Comparison of Tools forBuilding GOMS Models”,Proc. Computer-Human Interaction Conf.(CHI '00),pp. 502-509, 2000.

• R. Hartson and P. Gray, “Temporal Aspects of Tasks in the UserAction Notation”,Human Computer Interaction,vol. 7, pp. 1-45, 1992.

• G. van der Veer, B. Lenting, and B. Bergevoet, “GTA: GroupwareTask Analysis–Modeling Complexity”,Acta Psychologica,vol. 91,pp. 297-322, 1996.

• G. Booch, J. Rumbaugh, and I. Jacobson, Unified Modeling Language Reference Manual. Addison-Wesley, 1999


https://www.usability.gov/how-to-and-tools/methods/task-analysis.html

http://www.usabilitybok.org/task-analysis

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

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1027801&isnumber=22077

formalización del modelo de diálogo en...

Documents