El documento analiza el desarrollo de interfaces de usuario (IU) desde enfoques tradicionales hasta el diseño basado en modelos, destacando la importancia de la adaptación y reusabilidad en la creación de IU. Se discuten las propiedades esenciales a preservar en las IU, así como diferentes enfoques y técnicas para abordar la complejidad del dominio del problema. Además, se enfatiza la necesidad de un diseño estructurado que soporte la calidad y la usabilidad de las IU, presentando un marco de referencia para su evolución.

1. Frameworks
HCI
Model Driven Engineering

2. Complexity
• What profession is the oldest?
• Doctor, Civil Engineer, Computer Science
• Doctor: Eva extracted from a rib of Adam
• Civil Engineer: Order all the chaos to create heaven and earth
• Computer Science: Who created the chaos?

3. Complejidad
Explicamos la
naturaleza por
medio de
simplificaciones

4. Complejidad
del dominio
del problema

5. 10 propiedades a preservar en las IU
International Federation for Information Processing (IFIP)
• Categoría 1: presentación de la información
• Multiplicidad de dispositivos: teclado, mouse, tablet,…
• Multiplicidad de representaciones: representaciones alternativas de Entrada y Salida,
• Reusabilidad de Entrada/Salida (usar la Salida producida por una acción de Entrada por otra)
• Categoría 2: ordenamiento de la planeación de tareas
• Multiplicidad de roles de usuario
• Multiplicidad de rutas de ejecución: los usuarios deben tener la posibilidad de participar en la ejecución de
tareas diferentes de forma simultanea
• No-anticipación: grado de libertad al usuario para decidir lo que sigue
• Alcance: posibilidad de moverse en el sistema (undo, redo)
• Observabilidad vs Navegabilidad
• Categoría 3: adaptación del dialogo
• Reconfigurabilidad: habilidad del sistema para soportar la personalización del usuario
• Adaptativo: la habilidad del sistema de soportar la adaptación automática
• Migrabilidad: habilidad del sistema de transferir la responsabilidad de un usuario a otro, entre usuarios,
entre el usuario y el sistema
• Plasticidad: habilidad del sistema para adaptarse al contexto de uso preservando propiedades de
usabilidad
[Gram & Cockton,1986]

6. Mayor reto hoy en día
• Proliferación de desarrollos
UI #12UI #11UI #10UI #9Application 3
UI #8UI #7UI #6UI #5Application 2
UI #4UI #3UI #2UI #1Application 1
Platform #4Platform #3Platform #2Platform #1
Application 1
Application 2
Application 3
UI model #1
UI model #2
UI model #3
Platform #1
Platform #2
Platform #3
Platform #4
Platform model #1
Platform model #2
Platform model #3
Platform model #4
[Abrams et al.,2001]

7. Enfoque clásico de desarrollo de
IUs con un ambiente gráfico (IDE)
• Ciclo
Descríbelo has prototipo codifícalo a prueba y error
[Vanderdonckt,2010]

8. Los entornos de desarrollo ofrecen una
solución parcial
Interfaz deseada Solución alcanzable
 Ventana
 Barra de menú
 Paleta (iconos)
 Scrollbars
 Otros widgets: drop-down list, etc.
 Tabla con datos dinámicos
 Diagrama de Gantt
 Manipulación directa de losDirect
manipulation of widgets
[Vanderdonckt,2010]

9. Enfoque clásico
• Ventajas
• La IU es gráfica por naturaleza
• Una IU puede ser
• Rápidamente prototípica
• Fácilmente modificable
• Visualmente mostrada
• Restricciones
• No hay un método estructurado para el manejo de la distribución
• La selección de widgets podría ser inapropiada
• Distribuir los widgets puede ser tedioso, repetitivo
• Problema de espagueti
• Cada cambio en la IU puede orillar a un diseño no estructurado
[Vanderdonckt,2010]

10. DISEÑO
BASADO EN
MODELOS
COMO
SOLUCIÓN

11. Qué es el diseño basado en
modelos?
• El diseño basado en modelos consiste en
• Describir la IU en un modelo de IU
• Basarse en este modelo para guiar el ciclo de vida de desarrollo
de IU
• Mientras se siguen las siguientes metas:
• Generar ambientes de desarrollo de IU compresibles
• Soporte robusto al ciclo de vida de desarrollo de IU
• Mejorar la portabilidad
• Integrar la usabilidad en el desarrollo
• de IU
• Una estructura de 3 dimensiones
Modelos
Lenguaje UsiXML
Metodo en pasos
HerramientasSoftware
suporte
involucra
Descritos en
Metodologia de desarrollo
[Vanderdonckt,2010]

12. Qué es el diseño basado en
modelos?
• Qué es un modelo?
• Definiciones del diccionario Webster:
• « Aquel que se usa para mostrar ropa y otras mercancias (lenceria por citar un ejemplo)»
• « Un conjunto de planos de un edificio » (buena analogía)
• « Un sistema de postulados, datos, e inferencias presentadas como una descripción matemática de una entidad »
• Nuestra definición
• Un conjunto de planos estructurado de planos para desarrollar una IU
• Un sistema de postulados, datos, e inferencias presentadas como una descripción de IU (o especificación) que guía
el ciclo de vida de desarrollo de IU
[Vanderdonckt,2010]

13. Qué es el
diseño basado
en modelos?
• Qué es un modelo?
• Un ejemplo simple para propósito de
comprensión. Sistema de login
• Encontrar la abstracción correcta para el
modelo no es
• Replicar el código de otra forma
• Capturar todas las propiedades físicas
System loginSystem login
User name:
Password:
Enter Text
*******
Log in Cancel
Use this link to recover your password
I have lost my password
Help
[Vanderdonckt,2010]

14. Qué es un
modelo?
• Encontrar el modelo correcto para el SI
• Convertir los aspectos importantes de la IU en
opciones de diseño
• E.g. alineación de la etiqueta en vez de
coordenadas
• Derivar propiedades finales de estas opciones
• E.g., computar las coordenadas de la
alineación = {left, right, aligned, centred,
justified}
System loginSystem login
User name:
Password:
Enter Text
*******
Log in Cancel
Use this link to recover your password
I have lost my password
Help
LabelAlignement = left
ButtonPlacement = TotalEquil
[Vanderdonckt,2010]

15. Qué es un
modelo?
• Encontrar la abstracción del modelo SI
• Describir los widgets de IU
independientemente de la tecnología
• ¿Por qué?
System loginSystem login
User name:
Password:
Enter Text
*******
Log in Cancel
Use this link to recover your password
I have lost my password
Help
Identification label
Input text
Push button
[Vanderdonckt,2010]

16. Por qué describir los widgets
independientes de la tecnología ?
• Porqué hay muchos lenguajes o representaciones para ejecutar una tarea
• Por que el mismo widget aparece en diferentes tecnologías
• Por que hay muchas formas de alcanzar un objetivo (e.g., selector)
Check Box
(Windows)
BoxArray
(Garnet)
XmToggleButton
(OSF-Motif)
[Vanderdonckt,2010]

17. Permiten crear IU
sistemáticamente
GrafiXML

18. Qué se necesita para tener un modelo de IU de calidad?
• No introducir en
exceso,
ya que se vuelve
muy complejo
(<> simple)
• No introducir
muy pocas,
ya que se vuelve
simplista (<>
simple)
Las
abstracciones
son limitadas
pero
extensibles
• Completo
• Consistencia
• Corregible
• Expresivo
• …
C1: Necesita
asegurar la
calidad en las
propiedades
del modelo
[Vanderdonckt,2010]

19. De Código a
Modelos
• En un primer de abstracción,
se pasa de la interfaz final
(FUI) a la interfaz concreta
(CUI)
• Consecuentemente, una CUI
es independiente de
• Cualquier lenguaje:
(X)HTML, Java, Visual
Basic, C++
• Cualquier plataforma de
computo: Windows, Linux,
MacOS
[Vanderdonckt,2010]

20. De Modelos Concretos a Abstractos
• IUs no sólo son gráficas, si no que pueden ser vocales, táctiles, 3D, hápticas,
multimodales
• Entonces, hay necesidad de hacer mayores abstracciones, no solo hay GUIs
System loginSystem login
User name:
Password:
Enter Text
*******
Log in Cancel
Use this link to recover your password
I have lost my password
Help
Abstract Container
Abstract Individual Component with Output
Abs. Ind. Comp. with Input
Abs. Ind. Comp. with Control [Vanderdonckt,2010]

21. De Modelos Concretos
a Abstractos
• Con este segundo nivel de
abstracción, se va de CUI a IU
Abstracta (AUI)
• Consecuentemente, una AUI
es independiente de
• Cualquier modalidad de
interacción
[Vanderdonckt,2010]

22. De Modelos
Abstractos a
Modelos de
Tareas &
Conceptos Entonces, hay necesidad de modelar los problemas
independientemente de la plataforma de computo
Modelos de Tarea y datos (UML
Class Diagram)
IUs, incluso si son abstractas, estan estructuradas
acorde al sistema objetivo lo que va en contra del
paradigma centrado en el usuario
[Vanderdonckt,2010]

23. De Modelos
Abstractos a
Modelos de
Tareas &
Conceptos
[Vanderdonckt,2010]

24. ¿Qué tenemos
hasta ahora?
CON ESTE TERCER CONJUNTO DE
ABSTRACCIONES, PASAMOS DEL
MODELO AUI AL DE TAREAS Y
DATOS (T+D)
CONSECUENTEMENTE, EL T+D ES
INDEPENDIENTE DE CUALQUIER
IMPLEMENTACIÓN DE COMPUTO
[Vanderdonckt,2010]

25. ¿Necesitamos más modelos?
[Vanderdonckt,2010]

26. Soportar el Diseño de
Propiedades de
Plasticidad
• Adaptación al contexto de uso
mientras satisface propiedades
de usabilidad
[Grolaux et al.,2002]

27. Demo
FlexClock
[Grolaux et al.,2002]

28. EJEMPLO
PRACTICO
Sala de emergencias

29. Escenario-Multi-plataforma para
Emergencias
• Tres plataformas
• Pocket PC
• Desktop PC
• Wall Screens
[Vanderdonckt,2010]

30. ¿Como
resolver este
problema ?
• Múltiples usuarios
• Paciente
• Doctor
• Recepcionista
• Enfermero
• Radiólogo
• …..
• Múltiples ambientes
• Sala de espera
• Quirófano
• Consultorio
[Vanderdonckt,2010]

31. Solución
Propuesta
[Vanderdonckt,2010]
Énfasis también fue puesto
sobre los iconos usados
Modelo y método
Diseñar primero la pantalla de
referencia
Refinar las otras pantallas después
• Aplicando degradación gradual (se vera a
detalle mas adelante)
• Aplicando técnicas de transformación

32. Usando técnicas de degradación gradual de la IU se lograron las diferentes versiones de
pantallas, menús grandes fueron modificados por menús más pequeños, con
herramientas y reglas de degradación agradable
[Florins & Vanderdonckt,2004]

33. Algunas reglas de transformación para degradar un control de listas para agregar o quitar contenido de
una lista a otra
Add all >>
Add >
<< Remove all
< Remove
>>
>
<<
<
>
<
Group box
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
Item 8
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
Item 1
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7

34. Poly Medis
• Sala de Urgencias Digitalizada
• Automatización recepción
• Workflow del proceso de atención
• ToDo list
[Vanderdonckt,2010]

35. Marco de Referencia Camaleon
[Calvary et al.,2003]

36. 1-36
Aplicación de reglas de Transformación
Sistema de calculo de profesores por curso

37. Paso 1.
Consolidación
de Modelo de
Tareas

38. 1-38

39. 1-39
Mapeos del modelo de tareas
con el de Dominio
Rule: A task manipulates a domain class
Regla: Una tarea manipula una clase del
Dominio

40. 1-40
Consolidación de Modelo de
Tareas
NAC LHS RHS
::=
NAC LHS RHS
::=
Regla: Para cada tarea que manipula una clase de Dominio, una nueva
subtarea es creada por cada atributo
Cada una de las nuevas sub-tareas será mapeada al atributo de la clase
correspondiente
Rule: For each task that manipulates a domain class, a new subtask is created for
each attribute.
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

41. 1-41
Modelo de Tareas Expandido

42. 1-42
Paso 1. Consolidación de Modelo de Tareas
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
Task Task Type Task Item User category
Select NoTrainers Select Element Interactive
Select Trainer
Salary
Select Element Interactive
Select TrainerWD Select Element Interactive
Select
NoStudents
Select Element Interactive
Select Student
Salary
Select Element Interactive
Select annualWD Select Element Interactive
Calculate Salary Start Element System
Communicate
Result
Convey Element System
Exit Terminate Collection Interactive

43. 1-43
Paso 2. De modelado de Tareas a Interfaz Abstracta

44. 1-44
Paso 2. De modelado de Tareas a
Interfaz Abstracta
NAC LHS RHS
::=
NAC LHS RHS
::=
Cada tarea es ejecutada en un contenedor Abstracto si la
tarea es descompuesta en subtareas
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

45. 1-45
Paso 2. De modelado de Tareas a Interfaz Abstracta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

46. 1-46
Paso 2. De modelado de Tareas a Interfaz Abstracta
NAC LHS RHS
::=
NAC LHS RHS
::=
Cada hoja en el árbol de tareas es
ejecutada por un componente individual
asbtracto
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

47. 1-47
Paso 2. De modelado de Tareas a Interfaz Abstracta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

48. 1-48
Paso 2. De modelado de Tareas a Interfaz Abstracta -
Resultado
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

49. 1-49
Paso 2. De modelado de Tareas a Interfaz Abstracta
Task Task Type Task Item User category Facet
Select NoTrainers Select Element Interactive Input
Select Trainer
Salary
Select Element Interactive Input
Select TrainerWD Select Element Interactive Input
Select NoStudents Select Element Interactive Input
Select Student
Salary
Select Element Interactive Input
Select annualWD Select Element Interactive Input
Calculate Salary Start Element System Control
Communicate
Result
Convey Element System Output
Exit Terminate Collection Interactive Control
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

50. 1-50
Paso 3. De modelado de Interfaz Abstracta a Interfaz
Concreta

51. 1-51
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

52. 1-52
Concrete
User
Interface
Para cada
Abstract
Container
Paso 2. De modelado de Tareas a Interfaz Abstracta
Que
contenga un
abstract
individual
component
(AIC)
Y este AIC
tenga una
faceta de
input
Y tenga de
tarea select
Task &
Concepts
Abstract
User
Interface
Final User
Interface

53. 1-53
Paso 2. De modelado de Tareas a Interfaz Abstracta
Y tenga
como
dominio de
datos
unrango
continuo
El AIC se
concretiza
en un Slider
contino en
una caja
(Box)
Se aplica la
regla
Concrete
User
Interface
Task &
Concepts
Abstract
User
Interface
Final User
Interface

54. 1-54
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

55. 1-55
Paso 3. De modelado de Interfaz Abstracta a Interfaz
Concreta
– Selección de Widgets pensando que
estamos en la modalidad 3D.
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

56. 1-56
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
– Questions and answers method [MacLean
1991]
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

57. 1-57
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface

58. 1-58
Paso 4. Interfaz Final

59. 1-59
Video del Resultado Final
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface